[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [higgins-dev] Conversion to new IdASRegistry
|
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
>
