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