Re: [higgins-dev] Conversion to new IdASRegistry

["Tom Doman" <tdoman@xxxxxxxxxx>]

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
>