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