geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick McGuire <rick...@gmail.com>
Subject Fwd: Re: can't start framework assembly
Date Thu, 25 Mar 2010 13:29:33 GMT
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$AppClassLoader@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
>>
>


Mime
View raw message