|
Markus,
> 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");
1. I think we should have common way
to get an instance of IContext . So, I propose to hide the methods like
ContextIdFactory.fromFile(...) ontextIdFactory.fromUrl(string) etc. and use ContextIdFactory.fromString()
only.
2. I am not sure it is good to
use the real file name (or URL) to indentify
the configuration file of a context (like in registry.createContext("testcontext2.xrds")).
Thanks,
Sergey Lyakhov
----- Original Message -----
Sent: Saturday, August 25, 2007 3:23
AM
Subject: Re: [higgins-dev] Conversion to
new IdASRegistry
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
|
