Kevin Lohmann wrote:
Thanks Pierre and Guillaume for your replies.
I will give these ideas a try!
@Pierre:
Well, maybe the better way to understand what is going on is
looking at
the source code of the XMLInputFactory.newInstance().
I guess this method do something like the following:
1. If the Thread Context ClassLoader is set, then use that class
loader in order to lookup the
META-INF/services/javax.xml.stream.XMLInputFactory file.
2. If no Thread Context ClassLoader is set (null), then
use the class
loader which loaded the XmlInputFactory class (that is:
the class
loader of your bundle B)
3. Else fall back on the system class loader and lookup the
META-INF/services/javax.xml.stream.XMLInputFactory from
the classpath.
In your working case, I think that the step 2 applies here,
because you
have embedded both API + Impl in bundle A.
So maybe i haven't understood the ThreadContextClassLoader mechanism
yet, but how can have bundle B the XMLInputFactory-file in its
classpath, even when B has only an import on one package from bundle A?
Oups, your are right: in the step 2, I made a mistake, and typed "B"
instead of "A":
here is the fixed step 2:
2. If no Thread Context ClassLoader is set (null), then use the class
loader which loaded the XmlInputFactory class (that is: the class
loader of your bundle A)
Here, the newInstance method probably uses the class loader of the bundle A, which has visibility over the impl jar file
(and the impl jar file contains the META-INF/services/javax.xml.stream.XMLInputFactory).
/pierre
Thanks again && cheers,
Kevin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
