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
>>>
>>>
>>
>>
>
--
Painstaking Minds
IT-Consulting Bernhard Thalmayr
Herxheimer Str. 5, 83620 Vagen (Munich area), Germany
Tel: +49 (0)8062 7769174
Mobile: +49 (0)176 55060699
bernhard.thalmayr_at_painstakingminds.com - Solution Architect
This e-mail may contain confidential and/or privileged information.If
you are not the intended recipient (or have received this email in
error) please notify the sender immediately and delete this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.