Thanks, that helps. One thing I noticed is that GF still uses the old
woodstox version - the one to be used is 4.1.2. Since 4.x woodstox
version artifacts are already OSGified and setup their import/export
differently to the current version in GF which was OSGified by us. The
issue may be resolved by the upgrade itself because msv is actually an
optional woodstox component. Lukas is going to verify the msv use and if
it's really required we'll update the jaxb-osgi-extra artifact to export
the proper msv packages.
MartiNG
On 8/6/12 3:09 AM, Sahoo wrote:
> I am seeing the following failure when I try to start GlassFish to
> load bundles in ondemand mode. To start server in ondemand mode, just
> set glassfish.osgi.ondemand=true. It's set to false by default. I am
> also seeing some issues on Equinox platform, but they seem to be
> caused by this jaxb issue and recent jersey upgrade.
>
> 6 Aug, 2012 6:34:20 AM ObrHandler findResource
> INFO: Using the first one from the list of 1 discovered bundles shown
> below: [com.ctc.wstx/0.0.0]
> 6 Aug, 2012 6:34:20 AM ObrHandler resolve
> INFO: At the end of first pass, resolver outcome is
> : Added resources: [
> com.ctc.wstx, 0.0.0,
> file:/space/ss141213/WS/gf/trunk-svn/all/main/appserver/distributions/glassfish/target/stage/glassfish3/glassfish/modules/woodstox-osgi.jar]
> Required Resources: []
> Optional resources (deployed): []
> Unsatisfied requirements: [
> package:(&(package=com.sun.msv.grammar.trex))
> package:(&(package=com.sun.msv.util))
> package:(&(package=com.sun.msv.verifier.regexp))
> package:(&(package=com.sun.msv.reader.trex.ng))
> package:(&(package=com.sun.msv.verifier))
> package:(&(package=com.sun.msv.reader.util))
> package:(&(package=com.sun.msv.grammar))
> package:(&(package=com.sun.msv.reader))]
> 6 Aug, 2012 6:34:20 AM ObrHandler deploy
> WARNING: Unable to satisfy the requirements:
> [org.apache.felix.bundlerepository.impl.ReasonImpl_at_2cb491,
> org.apache.felix.bundlerepository.impl.ReasonImpl_at_199ffdd,
> org.apache.felix.bundlerepository.impl.ReasonImpl_at_1868b72,
> org.apache.felix.bundlerepository.impl.ReasonImpl_at_17cdd50,
> org.apache.felix.bundlerepository.impl.ReasonImpl_at_16d383a,
> org.apache.felix.bundlerepository.impl.ReasonImpl_at_a5b721,
> org.apache.felix.bundlerepository.impl.ReasonImpl_at_f96845,
> org.apache.felix.bundlerepository.impl.ReasonImpl_at_102d72d]
> Exception in thread "main" java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
> at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)
> Caused by: org.jvnet.hk2.component.ComponentException: Failed to
> create a habitat
> at
> com.sun.enterprise.module.common_impl.AbstractModulesRegistryImpl.populateServiceLocator(AbstractModulesRegistryImpl.java:182)
> at
> com.sun.enterprise.module.bootstrap.Main.createServiceLocator(Main.java:284)
> at
> org.jvnet.hk2.osgiadapter.HK2Main.createServiceLocator(HK2Main.java:119)
> at
> com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishRuntime.newGlassFish(EmbeddedOSGiGlassFishRuntime.java:98)
> at
> com.sun.enterprise.glassfish.bootstrap.GlassFishRuntimeDecorator.newGlassFish(GlassFishRuntimeDecorator.java:68)
> at
> com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishRuntime.newGlassFish(OSGiGlassFishRuntime.java:93)
> at
> com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:113)
> ... 6 more
> Caused by: java.lang.RuntimeException: Unable to install module [
> OSGiObrModuleImpl::Name: [com.ctc.wstx], State: [NEW]] due to
> unsatisfied dependencies. See previous log messages.
> at
> org.jvnet.hk2.osgiadapter.OSGiObrModuleImpl.init(OSGiObrModuleImpl.java:86)
> at
> org.jvnet.hk2.osgiadapter.OSGiObrModuleImpl.parseInhabitants(OSGiObrModuleImpl.java:171)
> at
> org.jvnet.hk2.osgiadapter.AbstractOSGiModulesRegistryImpl.parseInhabitants(AbstractOSGiModulesRegistryImpl.java:102)
> at
> com.sun.enterprise.module.common_impl.AbstractModulesRegistryImpl.populateServiceLocator(AbstractModulesRegistryImpl.java:178)
> ... 12 more
>
> I have updated the bug.
>
>
> Thanks,
> Sahoo
> On Sunday 05 August 2012 10:21 PM, Martin Grebac wrote:
>> We'll look into it. Btw, you mentioned this caused some regression.
>> Would you please be more specific on this?
>> Thanks,
>> MartiNG
>>
>> On 8/5/12 3:56 PM, Sahoo wrote:
>>> On Sunday 05 August 2012 07:20 PM, Lukas Jungmann wrote:
>>>> Hi Sahoo,
>>>>
>>>> On 08/05/2012 03:43 PM, Sahoo wrote:
>>>>> Lukas,
>>>>>
>>>>> I don't think new JAXB artifacts export everything the older ones
>>>>> used
>>>>> to export. This has caused some regression. So, please make sure
>>>>> there
>>>>> are no missing packages. I have filed
>>>>> http://java.net/jira/browse/GLASSFISH-18976 to track this. Pl. get
>>>>> this
>>>>> fixed ASAP. I would recommend adding some tests at your end to avoid
>>>>> such issues.
>>>>
>>>> I'm not sure but I think that removal of some supposed to be
>>>> obsolete packages was kind of 'intended' but I'll pass this to JAXB
>>>> guys to evaluate and fix what's necessarry.
>>> Tell them that some of the missing packages are actually needed by
>>> some bundles. They can find out more about how bundles depend on
>>> various packages by following instructions in [1].
>>>
>>> Thanks,
>>> Sahoo
>>>
>>> [1] https://wikis.oracle.com/display/GlassFish/OsgiPkgDepAnalyser
>>
>
--
Martin Grebac, SW Engineering Manager (Metro/JAXWS/JAXB RI)
Oracle Czech, Prague
http://blogs.oracle.com/mgrebac
ICQ: 93478885