Re: [higgins-dev] Conversion to new IdASRegistry

["Tom Doman" <TDoman@xxxxxxxxxx>]

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 
>
>
>