Re: [higgins-dev] Conversion to new IdASRegistry

["Tom Doman" <TDoman@xxxxxxxxxx>]

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 
>