Hi,
let's address this in the issue itself. Usual scenario is to add
jaxb1-impl to classpath. Is that a solution for you? We seem to be
missing osgi-fied version of jaxb1-impl from the build which was
separated out to decrease default footprint so we need to make that
available as an optional dependency,
MartiNG
On 11/5/12 4:30 PM, Bernhard Thalmayr wrote:
> Hmm so I do have now JAXB 2.2.6 but the fix for
> http://java.net/jira/browse/GLASSFISH-19287 seems to be somewhat
> unsatisfying ... instead of the old exception
>
> now
> java.lang.ClassNotFoundException: com.sun.xml.bind.ContextFactory_1_0_1
>
> is thrown...
>
> how can I run a JAXB 1.0.x app within GF 3.1.2.2?
>
>
> I would say
>
> 'http://jaxb.java.net/guide/Running_JAXB_1_0_and_2_x_side_by_side.html'
>
> should still be valid ...
>
> thanks,
> Bernhard
>
>
>
> Am 11/5/12 4:11 PM, schrieb Martin Grebac:
>> Hi,
>> if you look at the pom:
>> https://maven.java.net/content/groups/public/com/sun/xml/bind/jaxb-osgi/2.2.6/jaxb-osgi-2.2.6.pom
>>
>>
>> 2.2.6 impl depends on 2.2.7 api jar - the artifact versions are
>> updated independently so they don't need to necessarily match,
>> MartiNG
>>
>> On 11/5/12 4:04 PM, Bernhard Thalmayr wrote:
>>> Thanks for the pointer Martin, however I've used ....
>>>
>>> https://maven.java.net/content/groups/public/javax/xml/bind/jaxb-api-osgi/2.2.6/jaxb-api-osgi-2.2.6.jar
>>>
>>>
>>>
>>> and put it into 'modules/endorsed' directory as 'jaxb-api-osgi.jar'
>>>
>>> https://maven.java.net/content/groups/public/com/sun/xml/bind/jaxb-osgi/2.2.6/jaxb-osgi-2.2.6.jar
>>>
>>>
>>>
>>> and put it into 'modules' directory as 'jaxb-osgi.jar'
>>>
>>> removed osgi-cache directory
>>>
>>> and restarted domain.
>>>
>>> I would say if there's an incompatibility it's in the maven artifacts
>>> themselves ...
>>>
>>> Regards,
>>> Bernhard
>>>
>>>
>>> Am 11/5/12 3:57 PM, schrieb Martin Grebac:
>>>> Hi,
>>>> seems like you may be mixing incompatible versions of jaxbapi and
>>>> impl
>>>> (api and impl have separate versioning scheme).
>>>> Usually safest approach is to update full metro release which
>>>> includes
>>>> jaxb as well, is tested together and compatible. Such as Metro 2.2.1-1
>>>> from [1]. There's an ant script and instructions how to install
>>>> metro on
>>>> top of GF,
>>>> MartiNG
>>>>
>>>> [1] http://metro.java.net/2.2.1-1/
>>>>
>>>>
>>>> On 11/5/12 3:46 PM, Bernhard Thalmayr wrote:
>>>>> Also updateing relating jaxb-api-osgi.jar doest not work.
>>>>>
>>>>> Yes I've removed the osgi-cache directory before starting the DAS ...
>>>>>
>>>>>
>>>>> This exception seems to be the root cause ...
>>>>>
>>>>> [#|2012-11-05T15:42:55.400+0100|SEVERE|glassfish3.1.2|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=15;_ThreadName=Thread-3;|service
>>>>>
>>>>>
>>>>> exception
>>>>> com.sun.enterprise.module.ResolveError: Failed to start Bundle Id
>>>>> [173] State [INSTALLED]
>>>>> [org.glassfish.main.webservices.jsr109-impl(JSR-109 implementation to
>>>>> deploy Metro):3.1.2.1-SNAPSHOT]
>>>>> at
>>>>> org.jvnet.hk2.osgiadapter.OSGiModuleImpl.start(OSGiModuleImpl.java:177)
>>>>>
>>>>> at
>>>>> org.jvnet.hk2.osgiadapter.OSGiModuleImpl$2$1$1.loadClass(OSGiModuleImpl.java:344)
>>>>>
>>>>>
>>>>>
>>>>> at
>>>>> com.sun.hk2.component.LazyInhabitant.loadClass(LazyInhabitant.java:124)
>>>>>
>>>>> at
>>>>> com.sun.hk2.component.LazyInhabitant.fetch(LazyInhabitant.java:111)
>>>>> at
>>>>> com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:135)
>>>>>
>>>>>
>>>>>
>>>>> at
>>>>> com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:78)
>>>>>
>>>>>
>>>>>
>>>>> at org.jvnet.hk2.component.Habitat.getComponent(Habitat.java:798)
>>>>> at
>>>>> com.sun.enterprise.v3.admin.CommandRunnerImpl.getModel(CommandRunnerImpl.java:140)
>>>>>
>>>>>
>>>>>
>>>>> at
>>>>> org.glassfish.admin.rest.generator.ResourcesGeneratorBase.commandIsPresent(ResourcesGeneratorBase.java:315)
>>>>>
>>>>>
>>>>>
>>>>> at
>>>>> org.glassfish.admin.rest.generator.ResourcesGeneratorBase.generateCommandResources(ResourcesGeneratorBase.java:296)
>>>>>
>>>>>
>>>>>
>>>>> at
>>>>> org.glassfish.admin.rest.generator.ResourcesGeneratorBase.generateList(ResourcesGeneratorBase.java:163)
>>>>>
>>>>>
>>>>>
>>>>> at
>>>>> org.glassfish.admin.rest.generator.ResourcesGeneratorBase.processNonLeafChildConfigModel(ResourcesGeneratorBase.java:256)
>>>>>
>>>>>
>>>>>
>>>>> at
>>>>> org.glassfish.admin.rest.generator.ResourcesGeneratorBase.generateSingle(ResourcesGeneratorBase.java:119)
>>>>>
>>>>>
>>>>>
>>>>> at
>>>>> org.glassfish.admin.rest.generator.ResourcesGeneratorBase.processNonLeafChildElement(ResourcesGeneratorBase.java:240)
>>>>>
>>>>>
>>>>>
>>>>> at
>>>>> org.glassfish.admin.rest.generator.ResourcesGeneratorBase.generateSingle(ResourcesGeneratorBase.java:142)
>>>>>
>>>>>
>>>>>
>>>>> at
>>>>> org.glassfish.admin.rest.LazyJerseyInit.generateASM(LazyJerseyInit.java:313)
>>>>>
>>>>>
>>>>>
>>>>> at
>>>>> org.glassfish.admin.rest.LazyJerseyInit.getResourcesConfigForManagement(LazyJerseyInit.java:257)
>>>>>
>>>>>
>>>>>
>>>>> at
>>>>> org.glassfish.admin.rest.adapter.RestManagementAdapter.getResourcesConfig(RestManagementAdapter.java:62)
>>>>>
>>>>>
>>>>>
>>>>> at
>>>>> org.glassfish.admin.rest.adapter.RestAdapter.exposeContext(RestAdapter.java:335)
>>>>>
>>>>>
>>>>>
>>>>> at
>>>>> org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:146)
>>>>>
>>>>>
>>>>>
>>>>> at
>>>>> com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:179)
>>>>>
>>>>>
>>>>>
>>>>> at
>>>>> com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
>>>>>
>>>>>
>>>>>
>>>>> at
>>>>> com.sun.enterprise.v3.services.impl.ContainerMapper$Hk2DispatcherCallable.call(ContainerMapper.java:354)
>>>>>
>>>>>
>>>>>
>>>>> at
>>>>> com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
>>>>>
>>>>>
>>>>>
>>>>> at
>>>>> com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:860)
>>>>>
>>>>>
>>>>> at
>>>>> com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:757)
>>>>> at
>>>>> com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1056)
>>>>> at
>>>>> com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:229)
>>>>>
>>>>>
>>>>>
>>>>> at
>>>>> com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
>>>>>
>>>>>
>>>>>
>>>>> at
>>>>> com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
>>>>>
>>>>>
>>>>>
>>>>> at
>>>>> com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
>>>>>
>>>>>
>>>>>
>>>>> at
>>>>> com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
>>>>>
>>>>>
>>>>> at
>>>>> com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
>>>>>
>>>>>
>>>>>
>>>>> at
>>>>> com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
>>>>>
>>>>>
>>>>>
>>>>> at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
>>>>> at
>>>>> com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
>>>>>
>>>>>
>>>>>
>>>>> at
>>>>> com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
>>>>>
>>>>>
>>>>>
>>>>> at java.lang.Thread.run(Thread.java:680)
>>>>> Caused by: org.osgi.framework.BundleException: Unresolved constraint
>>>>> in bundle org.glassfish.main.webservices.jsr109-impl [173]: Unable to
>>>>> resolve 173.0: missing requirement [173.0] osgi.wiring.package;
>>>>> (&(osgi.wiring.package=com.sun.tools.ws.spi)(version>=2.2.0)) [caused
>>>>> by: Unable to resolve 238.0: missing requirement [238.0]
>>>>> osgi.wiring.package;
>>>>> (&(osgi.wiring.package=com.sun.codemodel)(version>=2.2.0)(!(version>=3.0.0)))
>>>>>
>>>>>
>>>>> [caused by: Unable to resolve 150.0: missing requirement [150.0]
>>>>> osgi.wiring.package;
>>>>> (&(osgi.wiring.package=javax.xml.bind)(version>=2.2.7))]]
>>>>> at
>>>>> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3826)
>>>>>
>>>>> at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
>>>>> at
>>>>> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
>>>>> at
>>>>> org.jvnet.hk2.osgiadapter.OSGiModuleImpl.start(OSGiModuleImpl.java:169)
>>>>>
>>>>> ... 37 more
>>>>> |#]
>>>>>
>>>>> Thanks,
>>>>> Bernhard
>>>>>
>>>>>
>>>>> Am 11/5/12 3:42 PM, schrieb Kevin Schmidt:
>>>>>> I tried to update JAX-B in GlassFish once and it didn't work for me
>>>>>> either, but I didn't do any endorsing or clearing the OSGi
>>>>>> cache. How
>>>>>> does one go about doing both of these?
>>>>>>
>>>>>> On Mon, Nov 5, 2012 at 6:39 AM, Martin Grebac
>>>>>> <martin.grebac_at_oracle.com
>>>>>> <mailto:martin.grebac_at_oracle.com>> wrote:
>>>>>>
>>>>>> Hi,
>>>>>> we'll try to address this in the upcoming GF patch. What do
>>>>>> you
>>>>>> mean by this does not seem to work? You need to make sure you
>>>>>> delete
>>>>>> osgi cache as well otherwise older jar may get loaded still,
>>>>>> MartiNG
>>>>>>
>>>>>> On 11/5/12 2:46 PM, Bernhard Thalmayr wrote:
>>>>>>
>>>>>> Hi experts, due to a serious bug
>>>>>> (http://java.net/jira/browse/__GLASSFISH-19287
>>>>>> <http://java.net/jira/browse/GLASSFISH-19287>) I need JAXB
>>>>>> 2.2.6.
>>>>>>
>>>>>> Is it possible to update just jaxb-osgi.jar?
>>>>>>
>>>>>> I've tried to replace the existing jar with
>>>>>> 'jaxb-osgi-2.2.6.jar' (renaming it to jaxb-osgi.jar) but
>>>>>> this
>>>>>> does not seem to work.
>>>>>>
>>>>>> TIA,
>>>>>> Bernhard
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Martin Grebac, SW Engineering Manager (Metro/JAXWS/JAXB RI)
>>>>>> Oracle Czech, Prague
>>>>>> http://blogs.oracle.com/__mgrebac
>>>>>> <http://blogs.oracle.com/mgrebac>
>>>>>> ICQ: 93478885
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
--
Martin Grebac, SW Engineering Manager (Metro/JAXWS/JAXB RI)
Oracle Czech, Prague
http://blogs.oracle.com/mgrebac
ICQ: 93478885