Email client problems...my replies went to Jarek only instead of the
list. This is useful information for everybody involved, so I'm sending
a copy here too.
Rick
Anyway, it turns out the solution to the javax.xml.namespace problem was
not to remove those classes, but rather to explicitly specify a version
number in the car maven plugin and framework config.properties for the
namespace package. This wires everything to the bootstrap version for
that class. Combined with a couple other tweaks I'd figured out
yesterday, the framework assembly launches now.
Rick
On 3/25/2010 8:54 AM, Rick McGuire wrote:
On 3/25/2010 1:20 AM, Jarek Gawor wrote:
Rick,
With the recent spec updates I'm unable to start a framework assembly.
Maybe I have some old snapshot somewhere but here's what I see when I
start the framework:
Bundle listed in startup.properties configuration not found:
org/apache/geronimo/specs/geronimo-osgi-registry/1.0.0-SNAPSHOT/geronimo-osgi-registry-1.0.0-SNAPSHOT.jar
and then:
javax.xml.stream.FactoryConfigurationError: Requested factory
com.ctc.wstx.stax.WstxInputFactory cannot be located. Classloader
=sun.misc.launcher$appclassloa...@1f12c4e
at
javax.xml.stream.FactoryLocator.newInstance(FactoryLocator.java:115)
at javax.xml.stream.FactoryLocator.locate(FactoryLocator.java:107)
at javax.xml.stream.FactoryLocator.locate(FactoryLocator.java:56)
at
javax.xml.stream.XMLInputFactory.newInstance(XMLInputFactory.java:41)
at
org.apache.geronimo.system.configuration.AttributesXmlUtil.<clinit>(AttributesXmlUtil.java:49)
Do you see the same? Can you take a look at this?
Ok, it looks like we have a real problem here with the bundles that
duplicate function of JRE provided classes. The APIs that are causing
us real problems are stax and jaxb, though I suspect stax is the real
issue. The full stax API defines the the javax.xml.namespace
package. In past releases, the Geronimo version of this package
skipped the definition of javax.xml.namespace.QName. I presume this
was done because classloading search order problems meant we needed to
be picking up the version off of the bootstrap class path because
other classes that used QName also picked this up from the bootstrap
classpath. Of course, when running in an OSGi framework, this creates
a split-package situation because the stax jar did define the
javax.xml.namespace.NamespaceContext class. I encountered build
issues because of this situation, so the solution was to add QName to
the stax API jar and suppress the javax.xml.namespace package from the
system bundle configuration. This seemed to fix the problem, but that
was an illusion at best.
Now I'm seeing issues with the javax.xml.datatype classes which also
use QName. We don't have a bundle version of those, so the classes
are getting picked up from the bootstrap classpath. Unfortunately,
because they are defined by the bootstrap classpath, any references to
those classes have to QName will pick up a different version of the
class, resulting in class loading constraint vioaltions.
So, it's become clear here that the QName class needs always to be
loaded from the bootstrap class path. And since we're talking about
the OSGi classloading model, this also means that the entire
javax.xml.namespace package needs to come from the same place. This
is problematic at best. I see a couple of potential solutions:
1) Remove the javax.xml.namespace classes from the stax api bundle
entirely and always use the versions from the bootstrap classpath.
The servicemix version kept the NamespaceContext class in place, but
removed the export of the classes. I have a suspicion that there may
still be problems with classes loaded from the stax API jar resolving
to the wrong NamespaceContext class when they are used. I suspect the
real solution here is to remove them entirely.
2) Place these classes on the endorsed classpath so we get a proper
override of the classes. The issue Jarek reported is a server launch
issue that could be fixed by this solution, but I've spent the last
couple of days trying to get Geronimo to build using a replacement
jaxb implementation, and I've been running into a NoClassDefFound
issue in the jaxb reference implementation that I now suspect is
caused by a QName conflict. I've not found any good way for endorsed
jars to be used during the build phase.
There's another problem with doing this. The proper functioning of
our spec jars depends on having a bundle Activator initialize access
to the service provider registry that's used to locate provider
implementations. If the stax API is in the endorsed dir, it does not
get processed as a bundle. The Activator does not get run to
initialize the ProviderLocator, so the extended services processing is
disabled. I have some ideas on how that might be fixed, but I'd
prefer not to have to do this.
For now, I think I'll just try removing the namespace classes from the
stax jar and see if this gets us a little farther.
Rick
Thanks,
Jarek
