Re: [higgins-dev] Conversion to new IdASRegistry

["Tom Doman" <TDoman@xxxxxxxxxx>]

OKay, I'd be good with a meaningful toString() for now and we'll see what
comes up from there.

Tom

>>> "Markus Sabadello" <msabadello@xxxxxxxxxxxxx> 08/25/07 6:47 PM >>>
I don't know.. I think I am against something like getDetails() just for
debugging purposes, because people might start to think that they actually
need that for something and get confused.

But I totally agree that it makes sense to implement a meaningful toString()
method.

Markus

On 8/25/07, Tom Doman <tdoman@xxxxxxxxxx> wrote:
>
> Actually, I think we'd want both.  The first (the original identifier)
> could
> be stored as a persistent reference to a context and later read and used
> to access the same context.  It could also be stored and used in
> conjunction
> with subject IDs from that context as persistent references to a given
> subject.
>
> The second is the one that could be used for audit and debug purposes.
>
> Maybe the first should be the toString() implementation and the second
> a getDetails() or something like that.  Both would be java.lang.String I
> would think.
>
> Both would be good for audit and debug though.  Thoughts?
>
> Tom
>
> >>> "Markus Sabadello" <msabadello@xxxxxxxxxxxxx> 08/24/07 9:12 PM >>>
> Hmm do you mean the toString() would return the original identifier (i.e.
> the filename, URI or XRI), or would it put together a string containing
> the
> context types and URIs?
>
> Either way, I guess that would be no problem..
>
> Markus
>
> On 8/25/07, Tom Doman <tdoman@xxxxxxxxxx> wrote:
> >
> > All right, got it, that all makes sense now, thanks.  Yeah, I'll go
> ahead
> > and
> > use the ultra- short version.
> >
> > Hey, how would you feel about making a special toString for your
> > IContextId
> > implementations?  For auditing and debug purposes, it'd be nice to get a
> > nice string that represents the context ID.  I realize it could be long
> if
> > we
> > include all the URIs, types, etc. but that's part of what we'd want to
> > see.
> >
> > Thanks,
> > Tom
> >
> > >>> "Markus Sabadello" <msabadello@xxxxxxxxxxxxx> 08/24/07 6:23 PM >>>
> > Ahh.. You mean the "types" member variable when looking at it in the
> > debugger? Yes you are right, this only gets populated when it is
> actually
> > needed (i.e. when you call getTypes or getUris or getConfiguration). The
> > reason you see it after the call to getContextFactory is that this
> > (obviously) needs to call getTypes.
> >
> > The idea behind this is that if your context ID is an XRI as opposed to
> a
> > local file, then the point in time at which you resolve it can make a
> > difference (the XRDS may change..).
> >
> > Of course, the ultra-  short version to get a Context without even
> caring
> > about types, would be this:
> >
> >     IdASRegistry registry = IdASRegistry.getInstance();
> >     IContext context = registry.createContext("testcontext2.xrds");
> >
> > Markus
> >
> > On 8/24/07, Tom Doman <TDoman@xxxxxxxxxx> wrote:
> > >
> > > Okay, I see ... I think.  :)
> > >
> > > I DO see the types but only AFTER the call to getContextFactory.  I
> was
> > > saying that I don't see them after the IContextId contextID =
> > > ContextIdFactory.getInstance().fromFile("testcontext2.xrds");
> > > call.  If I'm understanding correctly, the type doesn't need to be
> > > populated
> > > in preparation for the call to getContextFactory because it isn't used
> > to
> > > select the service endpoint for a local file.
> > >
> > > If ContextIdFactory.getInstance().fromXXX was used, perhaps it WOULD
> > > be populated after that call?
> > >
> > > Tom
> > >
> > > >>> "Markus Sabadello" <msabadello@xxxxxxxxxxxxx> 8/24/2007 5:38 PM
> >>>
> > > In our case, the <Type> elements are only used by IdASRegistry to
> > > establish
> > > the association to the context factory.. We don't use them for service
> > > endpoint selection.
> > >
> > > Reading an XRDS from a local file and selecting service endpoints from
> > > there
> > > is basically just a hack as compared to "real" XRI resolution, in
> which
> > > the
> > > three input parameters make much more sense. The most important
> > > application
> > > out there where the <Type> element is really used for SEP selection is
> > > OpenID. If you use your i-  name to log in at some OpenID relying
> party,
> > > then
> > > that site basically tells the XRI resolver "resolve the i-  name and
> give
> > me
> > > the service endpoint that has service type
> http://openid.net/signon/1.0 
> > ".
> > > That SEP would then contain an <URI> element with the OpenID endpoint
> in
> > > it.
> > >
> > > If you call contextID.getTypes(), you should get the contents of the
> > > <Type>
> > > elements (not the default one, just the ones with real content). Are
> you
> > > sure you get nothing there?
> > >
> > > Markus
> > >
> > > On 8/24/07, Tom Doman <TDoman@xxxxxxxxxx> wrote:
> > > >
> > > > Okay, cool, so tell me where the previously existing <Type ... >
> > > statement
> > > > would come into play.  Only if it wasn't in a local file?
> > > >
> > > > I'm also still wondering about the IContextId contextID =
> > > > ContextIdFactory.getInstance().fromFile("testcontext2.xrds");
> > > > call.  Why does contextID not end up with the types filled out since
> > the
> > > > XRDS document specifies ... well, now two types, ldap and "default".
> > > >
> > > > I would assume that the getContextFactory call would use those types
> > > > to filter on regardless of whether the other two resolution elements
> > > were
> > > > specified.
> > > >
> > > > Tom
> > > >
> > > > >>> "Markus Sabadello" <msabadello@xxxxxxxxxxxxx> 8/24/2007 4:52 PM
> > >>>
> > > > Hello Tom (and others),
> > > >
> > > > This can be solved by adding the following to the service endpoint
> in
> > > the
> > > > context descriptors (XRDSes), in your case testcontext1.xrds and
> > > > testcontext2.xrds:
> > > >
> > > >             <Type match="default" />
> > > >
> > > > (This would be in addition to the existing Type element(s), not as a
> > > > replacement). This was a bug in my example, and I just updated
> > > > http://wiki.eclipse.org/ContextDiscoveryComponents accordingly. The
> > XRDS
> > > > files in the org.eclipse.higgins.idas.registry.test project can also
> > be
> > > > used
> > > > a reference.
> > > >
> > > > For the interested, here's a detailled explanation:
> > > > The need for this element has to do with XRI resolution, which uses
> > > three
> > > > input parameters in order to select a service endpoint from an
> XRDS...
> > > > These
> > > > are path (<Path>), service type (<Type>) and service media type
> > > > (<MediaType>). What we want to do in our case is select the
> "default"
> > > > service endpoint from a static XRDS file (i.e. we set all three
> input
> > > > parameters to null). Now in order for a service endpoint to be
> > selected,
> > > > all
> > > > three input parameters (path, service type, service media type) must
> > > > either
> > > > match the content of a corresponding element in the service
> endpoint,
> > OR
> > > > the
> > > > corresponding element must allow a "default" match. If no element of
> > one
> > > > of
> > > > these three types is present (for instance, we have no <MediaType>
> > > > element),
> > > > then it automatically allows a "default" match. So our problem was
> > that
> > > we
> > > > had one <Type> element, which did not match our input parameter
> > (null),
> > > > therefore the service endpoint did not get selected. Adding the
> above
> > > > <Type
> > > > match="default" /> element makes sure the service endpoint also
> allows
> > a
> > > > "default" match.
> > > >
> > > > Markus
> > > >
> > > > On 8/24/07, Tom Doman <TDoman@xxxxxxxxxx > wrote:
> > > > >
> > > > > Markus,
> > > > >
> > > > > I think I need your assistance.  Having coded this all up, I've
> run
> > > into
> > > > > some issues getting the JNDI CP to run using this code.  I'm sure
> I
> > > > don't
> > > > > have something setup correctly but I'm not sure what.  As I've
> > > debugged
> > > > into
> > > > > this code, I've come up with a few questions about how it works
> that
> > > may
> > > > get
> > > > > to me what I'm doing wrong.
> > > > >
> > > > > 1. The first thing I do is get a copy of the registry impl for my
> > test
> > > > > class:
> > > > >
> > > > >         private IdASRegistry _reg = IdASRegistry.getInstance();
> > > > >
> > > > > I expected that this would actually parse the default XRDS
> document
> > (
> > > > > contextfactories.xrds) containing my context factories but it only
> > > > appears
> > > > > to setup to do so later.  That seemed all right to me but I don't
> > see
> > > > where
> > > > > it happens later either.  Anyway, assuming the registry is
> properly
> > > > > populated after getInstance() is called, I use it throughout my
> > tests.
> > > > >
> > > > > 2. Other than that, all I'm doing to get a context throughout my
> > tests
> > > > is
> > > > > this:
> > > > >
> > > > >         IContextId contextID = ContextIdFactory.getInstance
> > > ().fromFile("
> > > > > testcontext2.xrds");
> > > > >         IContextFactory factory =
> _reg.getContextFactory(contextID);
> > > > >         context = factory.createContext(contextID);
> > > > >
> > > > > The context ID is successfully constructed but this object too,
> > seems
> > > > not
> > > > > to have parsed the XRDS document describing the context (
> > > > testcontext2.xrds).  Again,
> > > > > perhaps it does it later but I'm not sure where because I assume
> the
> > > > call to
> > > > > get the factory has to have all the required members of the
> context
> > ID
> > > > > filled out, such as "types" so that the getContextFactory() call
> > knows
> > > > what
> > > > > to get.  Anyway, the call to get the context factory produces an
> > > > > IdASException saying "No service endpoint found" which makes sense
> > to
> > > me
> > > > > because I don't know how it COULD find a service endpoint based on
> > the
> > > > data
> > > > > I'm currently passing it.
> > > > >
> > > > > I'm sure I've missed a step somewhere but I've also included the
> > XRDS
> > > > > documents I'm using for your perusal to see if I've done something
> > > > stupid in
> > > > > them.
> > > > >
> > > > > Thanks,
> > > > > Tom
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > higgins-  dev mailing list
> > > > > higgins-  dev@xxxxxxxxxxx 
> > > > > https://dev.eclipse.org/mailman/listinfo/higgins-  dev
> > > > >
> > > > >
> > > > >
> > > > _______________________________________________
> > > > higgins-  dev mailing list
> > > > higgins-  dev@xxxxxxxxxxx 
> > > > https://dev.eclipse.org/mailman/listinfo/higgins-  dev
> > > >
> > > _______________________________________________
> > > higgins-  dev mailing list
> > > higgins-  dev@xxxxxxxxxxx 
> > > https://dev.eclipse.org/mailman/listinfo/higgins-  dev
> > >
> >
> > _______________________________________________
> > higgins- dev mailing list
> > higgins- dev@xxxxxxxxxxx 
> > https://dev.eclipse.org/mailman/listinfo/higgins- dev
> >
>
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx 
> https://dev.eclipse.org/mailman/listinfo/higgins-dev 
>