You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by Lukasz Lech <l....@ringler.ch> on 2018/09/10 14:26:59 UTC
Karaf 4.2.1: cannot be cast to
com.sun.xml.internal.bind.v2.runtime.reflect.Accessor
Hello,
After finding out that Karaf 4.2.1 includes Eclipselink version with PostgreSQL Bug Fix (https://bugs.eclipse.org/bugs/show_bug.cgi?id=522408) I've tested it with my code.
But another library has backfired, and I feel helpless about finding out what is going on.
I'm using JAXB to deserialize XML. I have 2 bundles, which have effectively the same code for deserializing XML from the same schema (some configuration data). In one of the bundles, everything works fine, in another one I get the exception:
JAXBContext.newInstance(targetClass):
Caused by: java.lang.ClassCastException: com.example.MyType$JaxbAccessorF_value cannot be cast to com.sun.xml.internal.bind.v2.runtime.reflect.Accessor
at com.sun.xml.internal.bind.v2.runtime.reflect.opt.OptimizedAccessorFactory.instanciate(OptimizedAccessorFactory.java:190) ~[?:?]
at com.sun.xml.internal.bind.v2.runtime.reflect.opt.OptimizedAccessorFactory.get(OptimizedAccessorFactory.java:179) ~[?:?]
at com.sun.xml.internal.bind.v2.runtime.reflect.Accessor$FieldReflection.optimize(Accessor.java:271) ~[?:?]
at com.sun.xml.internal.bind.v2.runtime.reflect.TransducedAccessor$CompositeTransducedAccessorImpl.<init>(TransducedAccessor.java:220) ~[?:?]
at com.sun.xml.internal.bind.v2.runtime.reflect.TransducedAccessor.get(TransducedAccessor.java:160) ~[?:?]
at com.sun.xml.internal.bind.v2.model.impl.RuntimeClassInfoImpl.calcTransducer(RuntimeClassInfoImpl.java:230) ~[?:?]
at com.sun.xml.internal.bind.v2.model.impl.RuntimeClassInfoImpl.getTransducer(RuntimeClassInfoImpl.java:204) ~[?:?]
at com.sun.xml.internal.bind.v2.model.impl.RuntimeClassInfoImpl.link(RuntimeClassInfoImpl.java:181) ~[?:?]
at com.sun.xml.internal.bind.v2.model.impl.ModelBuilder.link(ModelBuilder.java:439) ~[?:?]
at com.sun.xml.internal.bind.v2.model.impl.RuntimeModelBuilder.link(RuntimeModelBuilder.java:118) ~[?:?]
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:443) ~[?:?]
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:277) ~[?:?]
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:124) ~[?:?]
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl$JAXBContextBuilder.build(JAXBContextImpl.java:1123) ~[?:?]
at com.sun.xml.internal.bind.v2.ContextFactory.createContext(ContextFactory.java:147) ~[?:?]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:247) ~[?:?]
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:234) ~[?:?]
at javax.xml.bind.ContextFinder.find(ContextFinder.java:462) ~[?:?]
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:641) ~[?:?]
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:584) ~[?:?]
I don't see any substantial difference between those 2 bundles. They have other config files, but the same code parsing them. They use similar package imports etc.
However, one of them always starts, the other one not.
How to start debugging that issue? Have you experienced similar behavior or have hints, what can cause them?
The previous version, in that everything was working stable, was Karaf 4.1.3
Best regards,
Lukasz Lech
Re: Karaf 4.2.1: cannot be cast to
com.sun.xml.internal.bind.v2.runtime.reflect.Accessor
Posted by lechlukasz <l....@ringler.ch>.
I think I miss some background to understand what you mean by blacklisting...
We have the code, that is working in desktop version, is working in Karaf
4.1.3, but has problems with Karaf 4.2.1. So something must have changed
between those versions.
Status update: removing CXF changes nothing, so it's not a problem with CXF
(I've experienced no problems in Karaf 4.1.3 with CXF installed).
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
Re: Karaf 4.2.1: cannot be cast to
com.sun.xml.internal.bind.v2.runtime.reflect.Accessor
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi,
did you try to blacklist ?
Or another way around is to remove jaxb package from etc/jre.properties
to take the ones provided by the bundle.
Regards
JB
On 11/09/2018 17:57, DUTERTRY Nicolas wrote:
> Hi,
>
> I have run into the same issue with Karaf 4.2.1. It seems to me that the issue comes from cxf feature which contains 2 JAXB bundles :
> - mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.jaxb-impl/2.2.11_1
> - mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.jaxb-xjc/2.2.11_1
>
> When I remove those JAXB bundles everything works fine. This is annoying because I need both cxf and jaxb.
>
> --
> Nicolas Dutertry
>
> -----Message d'origine-----
> De : lechlukasz [mailto:l.lech@ringler.ch]
> Envoyé : lundi 10 septembre 2018 17:06
> À : user@karaf.apache.org
> Objet : Re: Karaf 4.2.1: cannot be cast to com.sun.xml.internal.bind.v2.runtime.reflect.Accessor
>
> I'm using Oracle JDK 8 (Windows).
>
> Those the imports that I make in one bundle which has this issue:
>
> org.apache.commons.csv,version=1.5.0 from org.apache.commons.csv (197)
> org.apache.commons.io,version=1.4.9999 from org.apache.commons.io (201)
> org.apache.commons.io,version=2.4.0 from org.apache.commons.io (201)
> org.apache.commons.lang,version=2.6.0 from org.apache.commons.lang (202)
> org.apache.commons.lang.time,version=2.6.0 from org.apache.commons.lang
> (202)
> org.apache.http,version=4.4.6 from org.apache.httpcomponents.httpcore (38)
> org.apache.http.auth,version=4.5.3 from org.apache.httpcomponents.httpclient
> (37)
> org.apache.http.client,version=4.5.3 from
> org.apache.httpcomponents.httpclient (37)
> org.apache.http.client.methods,version=4.5.3 from
> org.apache.httpcomponents.httpclient (37)
> org.apache.http.entity,version=4.4.6 from org.apache.httpcomponents.httpcore
> (38)
> org.apache.http.impl.client,version=4.5.3 from
> org.apache.httpcomponents.httpclient (37)
> org.osgi.service.blueprint,version=1.0.0 from
> org.apache.aries.blueprint.core (21)
> org.slf4j,version=1.7.25 from org.ops4j.pax.logging.pax-logging-api (6)
> org.slf4j,version=1.6.6 from org.ops4j.pax.logging.pax-logging-api (6)
> org.slf4j,version=1.5.11 from org.ops4j.pax.logging.pax-logging-api (6)
> org.slf4j,version=1.4.3 from org.ops4j.pax.logging.pax-logging-api (6)
>
> There's nothing explicitely about jaxb there...
>
>
>
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
>
RE: Karaf 4.2.1: cannot be cast to
com.sun.xml.internal.bind.v2.runtime.reflect.Accessor
Posted by DUTERTRY Nicolas <Ni...@soprahr.com>.
Hi,
I have run into the same issue with Karaf 4.2.1. It seems to me that the issue comes from cxf feature which contains 2 JAXB bundles :
- mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.jaxb-impl/2.2.11_1
- mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.jaxb-xjc/2.2.11_1
When I remove those JAXB bundles everything works fine. This is annoying because I need both cxf and jaxb.
--
Nicolas Dutertry
-----Message d'origine-----
De : lechlukasz [mailto:l.lech@ringler.ch]
Envoyé : lundi 10 septembre 2018 17:06
À : user@karaf.apache.org
Objet : Re: Karaf 4.2.1: cannot be cast to com.sun.xml.internal.bind.v2.runtime.reflect.Accessor
I'm using Oracle JDK 8 (Windows).
Those the imports that I make in one bundle which has this issue:
org.apache.commons.csv,version=1.5.0 from org.apache.commons.csv (197)
org.apache.commons.io,version=1.4.9999 from org.apache.commons.io (201)
org.apache.commons.io,version=2.4.0 from org.apache.commons.io (201)
org.apache.commons.lang,version=2.6.0 from org.apache.commons.lang (202)
org.apache.commons.lang.time,version=2.6.0 from org.apache.commons.lang
(202)
org.apache.http,version=4.4.6 from org.apache.httpcomponents.httpcore (38)
org.apache.http.auth,version=4.5.3 from org.apache.httpcomponents.httpclient
(37)
org.apache.http.client,version=4.5.3 from
org.apache.httpcomponents.httpclient (37)
org.apache.http.client.methods,version=4.5.3 from
org.apache.httpcomponents.httpclient (37)
org.apache.http.entity,version=4.4.6 from org.apache.httpcomponents.httpcore
(38)
org.apache.http.impl.client,version=4.5.3 from
org.apache.httpcomponents.httpclient (37)
org.osgi.service.blueprint,version=1.0.0 from
org.apache.aries.blueprint.core (21)
org.slf4j,version=1.7.25 from org.ops4j.pax.logging.pax-logging-api (6)
org.slf4j,version=1.6.6 from org.ops4j.pax.logging.pax-logging-api (6)
org.slf4j,version=1.5.11 from org.ops4j.pax.logging.pax-logging-api (6)
org.slf4j,version=1.4.3 from org.ops4j.pax.logging.pax-logging-api (6)
There's nothing explicitely about jaxb there...
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
Re: Karaf 4.2.1: cannot be cast to
com.sun.xml.internal.bind.v2.runtime.reflect.Accessor
Posted by lechlukasz <l....@ringler.ch>.
I'm using Oracle JDK 8 (Windows).
Those the imports that I make in one bundle which has this issue:
org.apache.commons.csv,version=1.5.0 from org.apache.commons.csv (197)
org.apache.commons.io,version=1.4.9999 from org.apache.commons.io (201)
org.apache.commons.io,version=2.4.0 from org.apache.commons.io (201)
org.apache.commons.lang,version=2.6.0 from org.apache.commons.lang (202)
org.apache.commons.lang.time,version=2.6.0 from org.apache.commons.lang
(202)
org.apache.http,version=4.4.6 from org.apache.httpcomponents.httpcore (38)
org.apache.http.auth,version=4.5.3 from org.apache.httpcomponents.httpclient
(37)
org.apache.http.client,version=4.5.3 from
org.apache.httpcomponents.httpclient (37)
org.apache.http.client.methods,version=4.5.3 from
org.apache.httpcomponents.httpclient (37)
org.apache.http.entity,version=4.4.6 from org.apache.httpcomponents.httpcore
(38)
org.apache.http.impl.client,version=4.5.3 from
org.apache.httpcomponents.httpclient (37)
org.osgi.service.blueprint,version=1.0.0 from
org.apache.aries.blueprint.core (21)
org.slf4j,version=1.7.25 from org.ops4j.pax.logging.pax-logging-api (6)
org.slf4j,version=1.6.6 from org.ops4j.pax.logging.pax-logging-api (6)
org.slf4j,version=1.5.11 from org.ops4j.pax.logging.pax-logging-api (6)
org.slf4j,version=1.4.3 from org.ops4j.pax.logging.pax-logging-api (6)
There's nothing explicitely about jaxb there...
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
Re: Karaf 4.2.1: cannot be cast to
com.sun.xml.internal.bind.v2.runtime.reflect.Accessor
Posted by Francois Papon <fr...@openobject.fr>.
Hi,
Which version of JDK are you using ?
regards,
François Papon
fpapon@apache.org
Le 10/09/2018 à 18:26, Lukasz Lech a écrit :
>
> Hello,
>
>
>
> After finding out that Karaf 4.2.1 includes Eclipselink version with
> PostgreSQL Bug Fix
> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=522408) I’ve tested it
> with my code.
>
>
>
> But another library has backfired, and I feel helpless about finding
> out what is going on.
>
>
>
> I’m using JAXB to deserialize XML. I have 2 bundles, which have
> effectively the same code for deserializing XML from the same schema
> (some configuration data). In one of the bundles, everything works
> fine, in another one I get the exception:
>
>
>
> JAXBContext.newInstance(targetClass):
>
>
>
> Caused by: java.lang.ClassCastException:
> com.example.MyType$JaxbAccessorF_value cannot be cast to
> com.sun.xml.internal.bind.v2.runtime.reflect.Accessor
>
> at
> com.sun.xml.internal.bind.v2.runtime.reflect.opt.OptimizedAccessorFactory.instanciate(OptimizedAccessorFactory.java:190)
> ~[?:?]
>
> at
> com.sun.xml.internal.bind.v2.runtime.reflect.opt.OptimizedAccessorFactory.get(OptimizedAccessorFactory.java:179)
> ~[?:?]
>
> at
> com.sun.xml.internal.bind.v2.runtime.reflect.Accessor$FieldReflection.optimize(Accessor.java:271)
> ~[?:?]
>
> at
> com.sun.xml.internal.bind.v2.runtime.reflect.TransducedAccessor$CompositeTransducedAccessorImpl.<init>(TransducedAccessor.java:220)
> ~[?:?]
>
> at
> com.sun.xml.internal.bind.v2.runtime.reflect.TransducedAccessor.get(TransducedAccessor.java:160)
> ~[?:?]
>
> at
> com.sun.xml.internal.bind.v2.model.impl.RuntimeClassInfoImpl.calcTransducer(RuntimeClassInfoImpl.java:230)
> ~[?:?]
>
> at
> com.sun.xml.internal.bind.v2.model.impl.RuntimeClassInfoImpl.getTransducer(RuntimeClassInfoImpl.java:204)
> ~[?:?]
>
> at
> com.sun.xml.internal.bind.v2.model.impl.RuntimeClassInfoImpl.link(RuntimeClassInfoImpl.java:181)
> ~[?:?]
>
> at
> com.sun.xml.internal.bind.v2.model.impl.ModelBuilder.link(ModelBuilder.java:439)
> ~[?:?]
>
> at
> com.sun.xml.internal.bind.v2.model.impl.RuntimeModelBuilder.link(RuntimeModelBuilder.java:118)
> ~[?:?]
>
> at
> com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:443)
> ~[?:?]
>
> at
> com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:277)
> ~[?:?]
>
> at
> com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:124)
> ~[?:?]
>
> at
> com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl$JAXBContextBuilder.build(JAXBContextImpl.java:1123)
> ~[?:?]
>
> at
> com.sun.xml.internal.bind.v2.ContextFactory.createContext(ContextFactory.java:147)
> ~[?:?]
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) ~[?:?]
>
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ~[?:?]
>
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[?:?]
>
> at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
>
> at
> javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:247) ~[?:?]
>
> at
> javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:234) ~[?:?]
>
> at
> javax.xml.bind.ContextFinder.find(ContextFinder.java:462) ~[?:?]
>
> at
> javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:641) ~[?:?]
>
> at
> javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:584) ~[?:?]
>
>
>
> I don’t see any substantial difference between those 2 bundles. They
> have other config files, but the same code parsing them. They use
> similar package imports etc.
>
>
>
> However, one of them always starts, the other one not.
>
>
>
> How to start debugging that issue? Have you experienced similar
> behavior or have hints, what can cause them?
>
>
>
> The previous version, in that everything was working stable, was Karaf
> 4.1.3
>
>
>
> Best regards,
>
> Lukasz Lech
>
>
>
Re: Karaf 4.2.1: cannot be cast to
com.sun.xml.internal.bind.v2.runtime.reflect.Accessor
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Do you use JAXB from the JDK on JAXB bundle ?
Regards
JB
On 10/09/2018 16:26, Lukasz Lech wrote:
> Hello,
>
>
>
> After finding out that Karaf 4.2.1 includes Eclipselink version with
> PostgreSQL Bug Fix
> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=522408) I’ve tested it
> with my code.
>
>
>
> But another library has backfired, and I feel helpless about finding out
> what is going on.
>
>
>
> I’m using JAXB to deserialize XML. I have 2 bundles, which have
> effectively the same code for deserializing XML from the same schema
> (some configuration data). In one of the bundles, everything works fine,
> in another one I get the exception:
>
>
>
> JAXBContext.newInstance(targetClass):
>
>
>
> Caused by: java.lang.ClassCastException:
> com.example.MyType$JaxbAccessorF_value cannot be cast to
> com.sun.xml.internal.bind.v2.runtime.reflect.Accessor
>
> at
> com.sun.xml.internal.bind.v2.runtime.reflect.opt.OptimizedAccessorFactory.instanciate(OptimizedAccessorFactory.java:190)
> ~[?:?]
>
> at
> com.sun.xml.internal.bind.v2.runtime.reflect.opt.OptimizedAccessorFactory.get(OptimizedAccessorFactory.java:179)
> ~[?:?]
>
> at
> com.sun.xml.internal.bind.v2.runtime.reflect.Accessor$FieldReflection.optimize(Accessor.java:271)
> ~[?:?]
>
> at
> com.sun.xml.internal.bind.v2.runtime.reflect.TransducedAccessor$CompositeTransducedAccessorImpl.<init>(TransducedAccessor.java:220)
> ~[?:?]
>
> at
> com.sun.xml.internal.bind.v2.runtime.reflect.TransducedAccessor.get(TransducedAccessor.java:160)
> ~[?:?]
>
> at
> com.sun.xml.internal.bind.v2.model.impl.RuntimeClassInfoImpl.calcTransducer(RuntimeClassInfoImpl.java:230)
> ~[?:?]
>
> at
> com.sun.xml.internal.bind.v2.model.impl.RuntimeClassInfoImpl.getTransducer(RuntimeClassInfoImpl.java:204)
> ~[?:?]
>
> at
> com.sun.xml.internal.bind.v2.model.impl.RuntimeClassInfoImpl.link(RuntimeClassInfoImpl.java:181)
> ~[?:?]
>
> at
> com.sun.xml.internal.bind.v2.model.impl.ModelBuilder.link(ModelBuilder.java:439)
> ~[?:?]
>
> at
> com.sun.xml.internal.bind.v2.model.impl.RuntimeModelBuilder.link(RuntimeModelBuilder.java:118)
> ~[?:?]
>
> at
> com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:443)
> ~[?:?]
>
> at
> com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:277)
> ~[?:?]
>
> at
> com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:124)
> ~[?:?]
>
> at
> com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl$JAXBContextBuilder.build(JAXBContextImpl.java:1123)
> ~[?:?]
>
> at
> com.sun.xml.internal.bind.v2.ContextFactory.createContext(ContextFactory.java:147)
> ~[?:?]
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) ~[?:?]
>
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ~[?:?]
>
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[?:?]
>
> at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
>
> at
> javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:247) ~[?:?]
>
> at
> javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:234) ~[?:?]
>
> at
> javax.xml.bind.ContextFinder.find(ContextFinder.java:462) ~[?:?]
>
> at
> javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:641) ~[?:?]
>
> at
> javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:584) ~[?:?]
>
>
>
> I don’t see any substantial difference between those 2 bundles. They
> have other config files, but the same code parsing them. They use
> similar package imports etc.
>
>
>
> However, one of them always starts, the other one not.
>
>
>
> How to start debugging that issue? Have you experienced similar behavior
> or have hints, what can cause them?
>
>
>
> The previous version, in that everything was working stable, was Karaf 4.1.3
>
>
>
> Best regards,
>
> Lukasz Lech
>
>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
RE: Karaf 4.2.1: cannot be cast to
com.sun.xml.internal.bind.v2.runtime.reflect.Accessor
Posted by "Siano, Stephan" <st...@sap.com>.
Hi,
Could you explain why these bundles are required? JAXB is already part of the JVM, so I don’t really understand why this additional implementation is needed. If there is reason to override the existing implementation in the JDK, shouldn’t it be in lib/endorsed then?
Best regards
Stephan
From: Freeman Fang <fr...@gmail.com>
Sent: Mittwoch, 12. September 2018 09:32
To: user@karaf.apache.org
Subject: Re: Karaf 4.2.1: cannot be cast to com.sun.xml.internal.bind.v2.runtime.reflect.Accessor
Hi Stephan,
We need it in lib/boot but I think we can remove jab-impl from etc/startup.properties.
Running more tests...
－－－－－－－－－－－－－
Freeman(Yue) Fang
Red Hat, Inc.
FuseSource is now part of Red Hat
On Sep 12, 2018, at 3:13 PM, Siano, Stephan <st...@sap.com>> wrote:
Hi,
I have seen that issue twice (with Java 8). A restart of the VM usually fixed this in my case.
I have browsed through the internet about this issue and it seems that this may happen if two JAXB implementations are in the classpath (there is also one included in the JVM, so removing the third one from CXF might not resolve the issue).
I have tried setting the system property "com.sun.xml.bind.v2.bytecode.ClassTailor.noOptimize" to "true" but I don't know whether this helps because the issue appears in my setup only very sporadically.
IMO it might also be worth a try to remove the JAXB bundles from the lib/boot directory before starting karaf. Having JAXB in the JDK and the boot classpath might also cause issues.
Best regards
Stephan
From: Freeman Fang <fr...@gmail.com>>
Sent: Mittwoch, 12. September 2018 09:08
To: user@karaf.apache.org<ma...@karaf.apache.org>
Subject: Re: Karaf 4.2.1: cannot be cast to com.sun.xml.internal.bind.v2.runtime.reflect.Accessor
Hello,
This ClassCastException normally means you have two jaxb-impl bundles(with different version) installed in the Karaf container.
Could you please double check it?
You can use Karaf command
package:exports |grep com.sun.xml.bind
And paste what the output you get here
Thanks!
－－－－－－－－－－－－－
Freeman(Yue) Fang
Red Hat, Inc.
FuseSource is now part of Red Hat
On Sep 10, 2018, at 10:26 PM, Lukasz Lech <l....@ringler.ch>> wrote:
Hello,
After finding out that Karaf 4.2.1 includes Eclipselink version with PostgreSQL Bug Fix (https://bugs.eclipse.org/bugs/show_bug.cgi?id=522408) I’ve tested it with my code.
But another library has backfired, and I feel helpless about finding out what is going on.
I’m using JAXB to deserialize XML. I have 2 bundles, which have effectively the same code for deserializing XML from the same schema (some configuration data). In one of the bundles, everything works fine, in another one I get the exception:
JAXBContext.newInstance(targetClass):
Caused by: java.lang.ClassCastException: com.example.MyType$JaxbAccessorF_value cannot be cast to com.sun.xml.internal.bind.v2.runtime.reflect.Accessor
at com.sun.xml.internal.bind.v2.runtime.reflect.opt.OptimizedAccessorFactory.instanciate(OptimizedAccessorFactory.java:190) ~[?:?]
at com.sun.xml.internal.bind.v2.runtime.reflect.opt.OptimizedAccessorFactory.get(OptimizedAccessorFactory.java:179) ~[?:?]
at com.sun.xml.internal.bind.v2.runtime.reflect.Accessor$FieldReflection.optimize(Accessor.java:271) ~[?:?]
at com.sun.xml.internal.bind.v2.runtime.reflect.TransducedAccessor$CompositeTransducedAccessorImpl.<init>(TransducedAccessor.java:220) ~[?:?]
at com.sun.xml.internal.bind.v2.runtime.reflect.TransducedAccessor.get(TransducedAccessor.java:160) ~[?:?]
at com.sun.xml.internal.bind.v2.model.impl.RuntimeClassInfoImpl.calcTransducer(RuntimeClassInfoImpl.java:230) ~[?:?]
at com.sun.xml.internal.bind.v2.model.impl.RuntimeClassInfoImpl.getTransducer(RuntimeClassInfoImpl.java:204) ~[?:?]
at com.sun.xml.internal.bind.v2.model.impl.RuntimeClassInfoImpl.link(RuntimeClassInfoImpl.java:181) ~[?:?]
at com.sun.xml.internal.bind.v2.model.impl.ModelBuilder.link(ModelBuilder.java:439) ~[?:?]
at com.sun.xml.internal.bind.v2.model.impl.RuntimeModelBuilder.link(RuntimeModelBuilder.java:118) ~[?:?]
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:443) ~[?:?]
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:277) ~[?:?]
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:124) ~[?:?]
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl$JAXBContextBuilder.build(JAXBContextImpl.java:1123) ~[?:?]
at com.sun.xml.internal.bind.v2.ContextFactory.createContext(ContextFactory.java:147) ~[?:?]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:247) ~[?:?]
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:234) ~[?:?]
at javax.xml.bind.ContextFinder.find(ContextFinder.java:462) ~[?:?]
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:641) ~[?:?]
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:584) ~[?:?]
I don’t see any substantial difference between those 2 bundles. They have other config files, but the same code parsing them. They use similar package imports etc.
However, one of them always starts, the other one not.
How to start debugging that issue? Have you experienced similar behavior or have hints, what can cause them?
The previous version, in that everything was working stable, was Karaf 4.1.3
Best regards,
Lukasz Lech
Re: Karaf 4.2.1: cannot be cast to com.sun.xml.internal.bind.v2.runtime.reflect.Accessor
Posted by Freeman Fang <fr...@gmail.com>.
JDK11 need those jaxb jars since they are removed from JDK11.
Seems I need another folder to put those jars for JDK11 only. Will fix it ...
－－－－－－－－－－－－－
Freeman(Yue) Fang
Red Hat, Inc.
FuseSource is now part of Red Hat
> On Sep 12, 2018, at 4:01 PM, DUTERTRY Nicolas <Ni...@soprahr.com> wrote:
>
> Hi,
>
> I’ve tried to remove jaxb-impl from etc/startup.properties, but the issue is still there.
>
> The command “package:exports |grep com.sun.xml.bind” doesn’t return anything.
>
> At the moment the only solution for me is to remove the jaxb-*.jar from lib/boot. What are the risks of not having them ?
>
> --
> Nicolas Dutertry
>
> De : Freeman Fang [mailto:freeman.fang@gmail.com <ma...@gmail.com>]
> Envoyé : mercredi 12 septembre 2018 09:32
> À : user@karaf.apache.org <ma...@karaf.apache.org>
> Objet : Re: Karaf 4.2.1: cannot be cast to com.sun.xml.internal.bind.v2.runtime.reflect.Accessor
>
> Hi Stephan,
>
> We need it in lib/boot but I think we can remove jab-impl from etc/startup.properties.
>
> Running more tests...
> －－－－－－－－－－－－－
> Freeman(Yue) Fang
>
> Red Hat, Inc.
> FuseSource is now part of Red Hat
>
>
>
> On Sep 12, 2018, at 3:13 PM, Siano, Stephan <stephan.siano@sap.com <ma...@sap.com>> wrote:
>
> Hi,
>
> I have seen that issue twice (with Java 8). A restart of the VM usually fixed this in my case.
>
> I have browsed through the internet about this issue and it seems that this may happen if two JAXB implementations are in the classpath (there is also one included in the JVM, so removing the third one from CXF might not resolve the issue).
>
> I have tried setting the system property "com.sun.xml.bind.v2.bytecode.ClassTailor.noOptimize" to "true" but I don't know whether this helps because the issue appears in my setup only very sporadically.
>
> IMO it might also be worth a try to remove the JAXB bundles from the lib/boot directory before starting karaf. Having JAXB in the JDK and the boot classpath might also cause issues.
>
> Best regards
> Stephan
>
>
> From: Freeman Fang <freeman.fang@gmail.com <ma...@gmail.com>>
> Sent: Mittwoch, 12. September 2018 09:08
> To: user@karaf.apache.org <ma...@karaf.apache.org>
> Subject: Re: Karaf 4.2.1: cannot be cast to com.sun.xml.internal.bind.v2.runtime.reflect.Accessor
>
> Hello,
>
> This ClassCastException normally means you have two jaxb-impl bundles(with different version) installed in the Karaf container.
>
> Could you please double check it?
>
> You can use Karaf command
> package:exports |grep com.sun.xml.bind
>
>
>
> And paste what the output you get here
>
>
>
> Thanks!
> －－－－－－－－－－－－－
> Freeman(Yue) Fang
>
> Red Hat, Inc.
> FuseSource is now part of Red Hat
>
>
>
> On Sep 10, 2018, at 10:26 PM, Lukasz Lech <l.lech@ringler.ch <ma...@ringler.ch>> wrote:
>
> Hello,
>
> After finding out that Karaf 4.2.1 includes Eclipselink version with PostgreSQL Bug Fix (https://bugs.eclipse.org/bugs/show_bug.cgi?id=522408 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=522408>) I’ve tested it with my code.
>
> But another library has backfired, and I feel helpless about finding out what is going on.
>
> I’m using JAXB to deserialize XML. I have 2 bundles, which have effectively the same code for deserializing XML from the same schema (some configuration data). In one of the bundles, everything works fine, in another one I get the exception:
>
> JAXBContext.newInstance(targetClass):
>
> Caused by: java.lang.ClassCastException: com.example.MyType$JaxbAccessorF_value cannot be cast to com.sun.xml.internal.bind.v2.runtime.reflect.Accessor
> at com.sun.xml.internal.bind.v2.runtime.reflect.opt.OptimizedAccessorFactory.instanciate(OptimizedAccessorFactory.java:190) ~[?:?]
> at com.sun.xml.internal.bind.v2.runtime.reflect.opt.OptimizedAccessorFactory.get(OptimizedAccessorFactory.java:179) ~[?:?]
> at com.sun.xml.internal.bind.v2.runtime.reflect.Accessor$FieldReflection.optimize(Accessor.java:271) ~[?:?]
> at com.sun.xml.internal.bind.v2.runtime.reflect.TransducedAccessor$CompositeTransducedAccessorImpl.<init>(TransducedAccessor.java:220) ~[?:?]
> at com.sun.xml.internal.bind.v2.runtime.reflect.TransducedAccessor.get(TransducedAccessor.java:160) ~[?:?]
> at com.sun.xml.internal.bind.v2.model.impl.RuntimeClassInfoImpl.calcTransducer(RuntimeClassInfoImpl.java:230) ~[?:?]
> at com.sun.xml.internal.bind.v2.model.impl.RuntimeClassInfoImpl.getTransducer(RuntimeClassInfoImpl.java:204) ~[?:?]
> at com.sun.xml.internal.bind.v2.model.impl.RuntimeClassInfoImpl.link(RuntimeClassInfoImpl.java:181) ~[?:?]
> at com.sun.xml.internal.bind.v2.model.impl.ModelBuilder.link(ModelBuilder.java:439) ~[?:?]
> at com.sun.xml.internal.bind.v2.model.impl.RuntimeModelBuilder.link(RuntimeModelBuilder.java:118) ~[?:?]
> at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:443) ~[?:?]
> at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:277) ~[?:?]
> at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:124) ~[?:?]
> at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl$JAXBContextBuilder.build(JAXBContextImpl.java:1123) ~[?:?]
> at com.sun.xml.internal.bind.v2.ContextFactory.createContext(ContextFactory.java:147) ~[?:?]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
> at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
> at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:247) ~[?:?]
> at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:234) ~[?:?]
> at javax.xml.bind.ContextFinder.find(ContextFinder.java:462) ~[?:?]
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:641) ~[?:?]
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:584) ~[?:?]
>
> I don’t see any substantial difference between those 2 bundles. They have other config files, but the same code parsing them. They use similar package imports etc.
>
> However, one of them always starts, the other one not.
>
> How to start debugging that issue? Have you experienced similar behavior or have hints, what can cause them?
>
> The previous version, in that everything was working stable, was Karaf 4.1.3
>
> Best regards,
> Lukasz Lech
RE: Karaf 4.2.1: cannot be cast to
com.sun.xml.internal.bind.v2.runtime.reflect.Accessor
Posted by DUTERTRY Nicolas <Ni...@soprahr.com>.
Hi,
I’ve tried to remove jaxb-impl from etc/startup.properties, but the issue is still there.
The command “package:exports |grep com.sun.xml.bind” doesn’t return anything.
At the moment the only solution for me is to remove the jaxb-*.jar from lib/boot. What are the risks of not having them ?
--
Nicolas Dutertry
De : Freeman Fang [mailto:freeman.fang@gmail.com]
Envoyé : mercredi 12 septembre 2018 09:32
À : user@karaf.apache.org
Objet : Re: Karaf 4.2.1: cannot be cast to com.sun.xml.internal.bind.v2.runtime.reflect.Accessor
Hi Stephan,
We need it in lib/boot but I think we can remove jab-impl from etc/startup.properties.
Running more tests...
－－－－－－－－－－－－－
Freeman(Yue) Fang
Red Hat, Inc.
FuseSource is now part of Red Hat
On Sep 12, 2018, at 3:13 PM, Siano, Stephan <st...@sap.com>> wrote:
Hi,
I have seen that issue twice (with Java 8). A restart of the VM usually fixed this in my case.
I have browsed through the internet about this issue and it seems that this may happen if two JAXB implementations are in the classpath (there is also one included in the JVM, so removing the third one from CXF might not resolve the issue).
I have tried setting the system property "com.sun.xml.bind.v2.bytecode.ClassTailor.noOptimize" to "true" but I don't know whether this helps because the issue appears in my setup only very sporadically.
IMO it might also be worth a try to remove the JAXB bundles from the lib/boot directory before starting karaf. Having JAXB in the JDK and the boot classpath might also cause issues.
Best regards
Stephan
From: Freeman Fang <fr...@gmail.com>>
Sent: Mittwoch, 12. September 2018 09:08
To: user@karaf.apache.org<ma...@karaf.apache.org>
Subject: Re: Karaf 4.2.1: cannot be cast to com.sun.xml.internal.bind.v2.runtime.reflect.Accessor
Hello,
This ClassCastException normally means you have two jaxb-impl bundles(with different version) installed in the Karaf container.
Could you please double check it?
You can use Karaf command
package:exports |grep com.sun.xml.bind
And paste what the output you get here
Thanks!
－－－－－－－－－－－－－
Freeman(Yue) Fang
Red Hat, Inc.
FuseSource is now part of Red Hat
On Sep 10, 2018, at 10:26 PM, Lukasz Lech <l....@ringler.ch>> wrote:
Hello,
After finding out that Karaf 4.2.1 includes Eclipselink version with PostgreSQL Bug Fix (https://bugs.eclipse.org/bugs/show_bug.cgi?id=522408) I’ve tested it with my code.
But another library has backfired, and I feel helpless about finding out what is going on.
I’m using JAXB to deserialize XML. I have 2 bundles, which have effectively the same code for deserializing XML from the same schema (some configuration data). In one of the bundles, everything works fine, in another one I get the exception:
JAXBContext.newInstance(targetClass):
Caused by: java.lang.ClassCastException: com.example.MyType$JaxbAccessorF_value cannot be cast to com.sun.xml.internal.bind.v2.runtime.reflect.Accessor
at com.sun.xml.internal.bind.v2.runtime.reflect.opt.OptimizedAccessorFactory.instanciate(OptimizedAccessorFactory.java:190) ~[?:?]
at com.sun.xml.internal.bind.v2.runtime.reflect.opt.OptimizedAccessorFactory.get(OptimizedAccessorFactory.java:179) ~[?:?]
at com.sun.xml.internal.bind.v2.runtime.reflect.Accessor$FieldReflection.optimize(Accessor.java:271) ~[?:?]
at com.sun.xml.internal.bind.v2.runtime.reflect.TransducedAccessor$CompositeTransducedAccessorImpl.<init>(TransducedAccessor.java:220) ~[?:?]
at com.sun.xml.internal.bind.v2.runtime.reflect.TransducedAccessor.get(TransducedAccessor.java:160) ~[?:?]
at com.sun.xml.internal.bind.v2.model.impl.RuntimeClassInfoImpl.calcTransducer(RuntimeClassInfoImpl.java:230) ~[?:?]
at com.sun.xml.internal.bind.v2.model.impl.RuntimeClassInfoImpl.getTransducer(RuntimeClassInfoImpl.java:204) ~[?:?]
at com.sun.xml.internal.bind.v2.model.impl.RuntimeClassInfoImpl.link(RuntimeClassInfoImpl.java:181) ~[?:?]
at com.sun.xml.internal.bind.v2.model.impl.ModelBuilder.link(ModelBuilder.java:439) ~[?:?]
at com.sun.xml.internal.bind.v2.model.impl.RuntimeModelBuilder.link(RuntimeModelBuilder.java:118) ~[?:?]
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:443) ~[?:?]
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:277) ~[?:?]
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:124) ~[?:?]
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl$JAXBContextBuilder.build(JAXBContextImpl.java:1123) ~[?:?]
at com.sun.xml.internal.bind.v2.ContextFactory.createContext(ContextFactory.java:147) ~[?:?]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:247) ~[?:?]
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:234) ~[?:?]
at javax.xml.bind.ContextFinder.find(ContextFinder.java:462) ~[?:?]
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:641) ~[?:?]
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:584) ~[?:?]
I don’t see any substantial difference between those 2 bundles. They have other config files, but the same code parsing them. They use similar package imports etc.
However, one of them always starts, the other one not.
How to start debugging that issue? Have you experienced similar behavior or have hints, what can cause them?
The previous version, in that everything was working stable, was Karaf 4.1.3
Best regards,
Lukasz Lech
Re: Karaf 4.2.1: cannot be cast to com.sun.xml.internal.bind.v2.runtime.reflect.Accessor
Posted by Freeman Fang <fr...@gmail.com>.
Hi Stephan,
We need it in lib/boot but I think we can remove jab-impl from etc/startup.properties.
Running more tests...
－－－－－－－－－－－－－
Freeman(Yue) Fang
Red Hat, Inc.
FuseSource is now part of Red Hat
> On Sep 12, 2018, at 3:13 PM, Siano, Stephan <st...@sap.com> wrote:
>
> Hi,
>
> I have seen that issue twice (with Java 8). A restart of the VM usually fixed this in my case.
>
> I have browsed through the internet about this issue and it seems that this may happen if two JAXB implementations are in the classpath (there is also one included in the JVM, so removing the third one from CXF might not resolve the issue).
>
> I have tried setting the system property "com.sun.xml.bind.v2.bytecode.ClassTailor.noOptimize" to "true" but I don't know whether this helps because the issue appears in my setup only very sporadically.
>
> IMO it might also be worth a try to remove the JAXB bundles from the lib/boot directory before starting karaf. Having JAXB in the JDK and the boot classpath might also cause issues.
>
> Best regards
> Stephan
>
>
> From: Freeman Fang <freeman.fang@gmail.com <ma...@gmail.com>>
> Sent: Mittwoch, 12. September 2018 09:08
> To: user@karaf.apache.org <ma...@karaf.apache.org>
> Subject: Re: Karaf 4.2.1: cannot be cast to com.sun.xml.internal.bind.v2.runtime.reflect.Accessor
>
> Hello,
>
> This ClassCastException normally means you have two jaxb-impl bundles(with different version) installed in the Karaf container.
>
> Could you please double check it?
>
> You can use Karaf command
> package:exports |grep com.sun.xml.bind
>
>
> And paste what the output you get here
>
>
> Thanks!
> －－－－－－－－－－－－－
> Freeman(Yue) Fang
>
> Red Hat, Inc.
> FuseSource is now part of Red Hat
>
>
>
> On Sep 10, 2018, at 10:26 PM, Lukasz Lech <l.lech@ringler.ch <ma...@ringler.ch>> wrote:
>
> Hello,
>
> After finding out that Karaf 4.2.1 includes Eclipselink version with PostgreSQL Bug Fix (https://bugs.eclipse.org/bugs/show_bug.cgi?id=522408 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=522408>) I’ve tested it with my code.
>
> But another library has backfired, and I feel helpless about finding out what is going on.
>
> I’m using JAXB to deserialize XML. I have 2 bundles, which have effectively the same code for deserializing XML from the same schema (some configuration data). In one of the bundles, everything works fine, in another one I get the exception:
>
> JAXBContext.newInstance(targetClass):
>
> Caused by: java.lang.ClassCastException: com.example.MyType$JaxbAccessorF_value cannot be cast to com.sun.xml.internal.bind.v2.runtime.reflect.Accessor
> at com.sun.xml.internal.bind.v2.runtime.reflect.opt.OptimizedAccessorFactory.instanciate(OptimizedAccessorFactory.java:190) ~[?:?]
> at com.sun.xml.internal.bind.v2.runtime.reflect.opt.OptimizedAccessorFactory.get(OptimizedAccessorFactory.java:179) ~[?:?]
> at com.sun.xml.internal.bind.v2.runtime.reflect.Accessor$FieldReflection.optimize(Accessor.java:271) ~[?:?]
> at com.sun.xml.internal.bind.v2.runtime.reflect.TransducedAccessor$CompositeTransducedAccessorImpl.<init>(TransducedAccessor.java:220) ~[?:?]
> at com.sun.xml.internal.bind.v2.runtime.reflect.TransducedAccessor.get(TransducedAccessor.java:160) ~[?:?]
> at com.sun.xml.internal.bind.v2.model.impl.RuntimeClassInfoImpl.calcTransducer(RuntimeClassInfoImpl.java:230) ~[?:?]
> at com.sun.xml.internal.bind.v2.model.impl.RuntimeClassInfoImpl.getTransducer(RuntimeClassInfoImpl.java:204) ~[?:?]
> at com.sun.xml.internal.bind.v2.model.impl.RuntimeClassInfoImpl.link(RuntimeClassInfoImpl.java:181) ~[?:?]
> at com.sun.xml.internal.bind.v2.model.impl.ModelBuilder.link(ModelBuilder.java:439) ~[?:?]
> at com.sun.xml.internal.bind.v2.model.impl.RuntimeModelBuilder.link(RuntimeModelBuilder.java:118) ~[?:?]
> at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:443) ~[?:?]
> at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:277) ~[?:?]
> at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:124) ~[?:?]
> at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl$JAXBContextBuilder.build(JAXBContextImpl.java:1123) ~[?:?]
> at com.sun.xml.internal.bind.v2.ContextFactory.createContext(ContextFactory.java:147) ~[?:?]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
> at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
> at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:247) ~[?:?]
> at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:234) ~[?:?]
> at javax.xml.bind.ContextFinder.find(ContextFinder.java:462) ~[?:?]
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:641) ~[?:?]
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:584) ~[?:?]
>
> I don’t see any substantial difference between those 2 bundles. They have other config files, but the same code parsing them. They use similar package imports etc.
>
> However, one of them always starts, the other one not.
>
> How to start debugging that issue? Have you experienced similar behavior or have hints, what can cause them?
>
> The previous version, in that everything was working stable, was Karaf 4.1.3
>
> Best regards,
> Lukasz Lech
RE: Karaf 4.2.1: cannot be cast to
com.sun.xml.internal.bind.v2.runtime.reflect.Accessor
Posted by "Siano, Stephan" <st...@sap.com>.
Hi,
I have seen that issue twice (with Java 8). A restart of the VM usually fixed this in my case.
I have browsed through the internet about this issue and it seems that this may happen if two JAXB implementations are in the classpath (there is also one included in the JVM, so removing the third one from CXF might not resolve the issue).
I have tried setting the system property "com.sun.xml.bind.v2.bytecode.ClassTailor.noOptimize" to "true" but I don't know whether this helps because the issue appears in my setup only very sporadically.
IMO it might also be worth a try to remove the JAXB bundles from the lib/boot directory before starting karaf. Having JAXB in the JDK and the boot classpath might also cause issues.
Best regards
Stephan
From: Freeman Fang <fr...@gmail.com>
Sent: Mittwoch, 12. September 2018 09:08
To: user@karaf.apache.org
Subject: Re: Karaf 4.2.1: cannot be cast to com.sun.xml.internal.bind.v2.runtime.reflect.Accessor
Hello,
This ClassCastException normally means you have two jaxb-impl bundles(with different version) installed in the Karaf container.
Could you please double check it?
You can use Karaf command
package:exports |grep com.sun.xml.bind
And paste what the output you get here
Thanks!
－－－－－－－－－－－－－
Freeman(Yue) Fang
Red Hat, Inc.
FuseSource is now part of Red Hat
On Sep 10, 2018, at 10:26 PM, Lukasz Lech <l....@ringler.ch>> wrote:
Hello,
After finding out that Karaf 4.2.1 includes Eclipselink version with PostgreSQL Bug Fix (https://bugs.eclipse.org/bugs/show_bug.cgi?id=522408) I’ve tested it with my code.
But another library has backfired, and I feel helpless about finding out what is going on.
I’m using JAXB to deserialize XML. I have 2 bundles, which have effectively the same code for deserializing XML from the same schema (some configuration data). In one of the bundles, everything works fine, in another one I get the exception:
JAXBContext.newInstance(targetClass):
Caused by: java.lang.ClassCastException: com.example.MyType$JaxbAccessorF_value cannot be cast to com.sun.xml.internal.bind.v2.runtime.reflect.Accessor
at com.sun.xml.internal.bind.v2.runtime.reflect.opt.OptimizedAccessorFactory.instanciate(OptimizedAccessorFactory.java:190) ~[?:?]
at com.sun.xml.internal.bind.v2.runtime.reflect.opt.OptimizedAccessorFactory.get(OptimizedAccessorFactory.java:179) ~[?:?]
at com.sun.xml.internal.bind.v2.runtime.reflect.Accessor$FieldReflection.optimize(Accessor.java:271) ~[?:?]
at com.sun.xml.internal.bind.v2.runtime.reflect.TransducedAccessor$CompositeTransducedAccessorImpl.<init>(TransducedAccessor.java:220) ~[?:?]
at com.sun.xml.internal.bind.v2.runtime.reflect.TransducedAccessor.get(TransducedAccessor.java:160) ~[?:?]
at com.sun.xml.internal.bind.v2.model.impl.RuntimeClassInfoImpl.calcTransducer(RuntimeClassInfoImpl.java:230) ~[?:?]
at com.sun.xml.internal.bind.v2.model.impl.RuntimeClassInfoImpl.getTransducer(RuntimeClassInfoImpl.java:204) ~[?:?]
at com.sun.xml.internal.bind.v2.model.impl.RuntimeClassInfoImpl.link(RuntimeClassInfoImpl.java:181) ~[?:?]
at com.sun.xml.internal.bind.v2.model.impl.ModelBuilder.link(ModelBuilder.java:439) ~[?:?]
at com.sun.xml.internal.bind.v2.model.impl.RuntimeModelBuilder.link(RuntimeModelBuilder.java:118) ~[?:?]
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:443) ~[?:?]
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:277) ~[?:?]
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:124) ~[?:?]
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl$JAXBContextBuilder.build(JAXBContextImpl.java:1123) ~[?:?]
at com.sun.xml.internal.bind.v2.ContextFactory.createContext(ContextFactory.java:147) ~[?:?]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:247) ~[?:?]
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:234) ~[?:?]
at javax.xml.bind.ContextFinder.find(ContextFinder.java:462) ~[?:?]
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:641) ~[?:?]
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:584) ~[?:?]
I don’t see any substantial difference between those 2 bundles. They have other config files, but the same code parsing them. They use similar package imports etc.
However, one of them always starts, the other one not.
How to start debugging that issue? Have you experienced similar behavior or have hints, what can cause them?
The previous version, in that everything was working stable, was Karaf 4.1.3
Best regards,
Lukasz Lech
Re: Karaf 4.2.1: cannot be cast to com.sun.xml.internal.bind.v2.runtime.reflect.Accessor
Posted by Freeman Fang <fr...@gmail.com>.
Hi,
This should be fixed by KARAF-5912[1]
[1]https://issues.apache.org/jira/browse/KARAF-5912 <https://issues.apache.org/jira/browse/KARAF-5912>
Cheers
Freeman
－－－－－－－－－－－－－
Freeman(Yue) Fang
Red Hat, Inc.
FuseSource is now part of Red Hat
> On Sep 14, 2018, at 8:58 PM, lechlukasz <l....@ringler.ch> wrote:
>
> karaf@root()> package:exports |grep com.sun.xml.bind
> com.sun.xml.bind.annotation
> | 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
> com.sun.xml.bind.api.impl
> | 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
> com.sun.xml.bind.api
> | 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
> com.sun.xml.bind.marshaller
> | 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
> com.sun.xml.bind.unmarshaller
> | 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
> com.sun.xml.bind.util
> | 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
> com.sun.xml.bind.v2.bytecode
> | 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
> com.sun.xml.bind.v2.doc-files
> | 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
> com.sun.xml.bind.v2.model.annotation
> | 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
> com.sun.xml.bind.v2.model.core
> | 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
> com.sun.xml.bind.v2.model.impl
> | 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
> com.sun.xml.bind.v2.model.nav
> | 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
> com.sun.xml.bind.v2.model.runtime
> | 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
> com.sun.xml.bind.v2.model.util
> | 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
> com.sun.xml.bind.v2.runtime.output
> | 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
> com.sun.xml.bind.v2.runtime.property
> | 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
> com.sun.xml.bind.v2.runtime.reflect.opt
> | 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
> com.sun.xml.bind.v2.runtime.reflect
> | 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
> com.sun.xml.bind.v2.runtime.unmarshaller
> | 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
> com.sun.xml.bind.v2.runtime
> | 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
> com.sun.xml.bind.v2.schemagen.episode
> | 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
> com.sun.xml.bind.v2.schemagen.xmlschema
> | 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
> com.sun.xml.bind.v2.schemagen
> | 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
> com.sun.xml.bind.v2.util
> | 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
> com.sun.xml.bind.v2
> | 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
> com.sun.xml.bind
> | 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
>
> I always get that error under windows (OracleJDK 8), never in dockerized
> container (OpenJDK8).
>
>
>
> Freeman-2 wrote
>> Hello,
>>
>> This ClassCastException normally means you have two jaxb-impl bundles(with
>> different version) installed in the Karaf container.
>>
>> Could you please double check it?
>>
>> You can use Karaf command
>> package:exports |grep com.sun.xml.bind
>>
>> And paste what the output you get here
>
>
>
>
>
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
Re: Karaf 4.2.1: cannot be cast to
com.sun.xml.internal.bind.v2.runtime.reflect.Accessor
Posted by lechlukasz <l....@ringler.ch>.
karaf@root()> package:exports |grep com.sun.xml.bind
com.sun.xml.bind.annotation
| 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
com.sun.xml.bind.api.impl
| 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
com.sun.xml.bind.api
| 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
com.sun.xml.bind.marshaller
| 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
com.sun.xml.bind.unmarshaller
| 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
com.sun.xml.bind.util
| 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
com.sun.xml.bind.v2.bytecode
| 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
com.sun.xml.bind.v2.doc-files
| 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
com.sun.xml.bind.v2.model.annotation
| 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
com.sun.xml.bind.v2.model.core
| 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
com.sun.xml.bind.v2.model.impl
| 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
com.sun.xml.bind.v2.model.nav
| 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
com.sun.xml.bind.v2.model.runtime
| 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
com.sun.xml.bind.v2.model.util
| 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
com.sun.xml.bind.v2.runtime.output
| 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
com.sun.xml.bind.v2.runtime.property
| 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
com.sun.xml.bind.v2.runtime.reflect.opt
| 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
com.sun.xml.bind.v2.runtime.reflect
| 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
com.sun.xml.bind.v2.runtime.unmarshaller
| 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
com.sun.xml.bind.v2.runtime
| 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
com.sun.xml.bind.v2.schemagen.episode
| 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
com.sun.xml.bind.v2.schemagen.xmlschema
| 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
com.sun.xml.bind.v2.schemagen
| 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
com.sun.xml.bind.v2.util
| 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
com.sun.xml.bind.v2
| 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
com.sun.xml.bind
| 2.2.11 | 12 | org.apache.servicemix.bundles.jaxb-impl
I always get that error under windows (OracleJDK 8), never in dockerized
container (OpenJDK8).
Freeman-2 wrote
> Hello,
>
> This ClassCastException normally means you have two jaxb-impl bundles(with
> different version) installed in the Karaf container.
>
> Could you please double check it?
>
> You can use Karaf command
> package:exports |grep com.sun.xml.bind
>
> And paste what the output you get here
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
Re: Karaf 4.2.1: cannot be cast to com.sun.xml.internal.bind.v2.runtime.reflect.Accessor
Posted by Freeman Fang <fr...@gmail.com>.
Hello,
This ClassCastException normally means you have two jaxb-impl bundles(with different version) installed in the Karaf container.
Could you please double check it?
You can use Karaf command
package:exports |grep com.sun.xml.bind
And paste what the output you get here
Thanks!
－－－－－－－－－－－－－
Freeman(Yue) Fang
Red Hat, Inc.
FuseSource is now part of Red Hat
> On Sep 10, 2018, at 10:26 PM, Lukasz Lech <l....@ringler.ch> wrote:
>
> Hello,
>
> After finding out that Karaf 4.2.1 includes Eclipselink version with PostgreSQL Bug Fix (https://bugs.eclipse.org/bugs/show_bug.cgi?id=522408 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=522408>) I’ve tested it with my code.
>
> But another library has backfired, and I feel helpless about finding out what is going on.
>
> I’m using JAXB to deserialize XML. I have 2 bundles, which have effectively the same code for deserializing XML from the same schema (some configuration data). In one of the bundles, everything works fine, in another one I get the exception:
>
> JAXBContext.newInstance(targetClass):
>
> Caused by: java.lang.ClassCastException: com.example.MyType$JaxbAccessorF_value cannot be cast to com.sun.xml.internal.bind.v2.runtime.reflect.Accessor
> at com.sun.xml.internal.bind.v2.runtime.reflect.opt.OptimizedAccessorFactory.instanciate(OptimizedAccessorFactory.java:190) ~[?:?]
> at com.sun.xml.internal.bind.v2.runtime.reflect.opt.OptimizedAccessorFactory.get(OptimizedAccessorFactory.java:179) ~[?:?]
> at com.sun.xml.internal.bind.v2.runtime.reflect.Accessor$FieldReflection.optimize(Accessor.java:271) ~[?:?]
> at com.sun.xml.internal.bind.v2.runtime.reflect.TransducedAccessor$CompositeTransducedAccessorImpl.<init>(TransducedAccessor.java:220) ~[?:?]
> at com.sun.xml.internal.bind.v2.runtime.reflect.TransducedAccessor.get(TransducedAccessor.java:160) ~[?:?]
> at com.sun.xml.internal.bind.v2.model.impl.RuntimeClassInfoImpl.calcTransducer(RuntimeClassInfoImpl.java:230) ~[?:?]
> at com.sun.xml.internal.bind.v2.model.impl.RuntimeClassInfoImpl.getTransducer(RuntimeClassInfoImpl.java:204) ~[?:?]
> at com.sun.xml.internal.bind.v2.model.impl.RuntimeClassInfoImpl.link(RuntimeClassInfoImpl.java:181) ~[?:?]
> at com.sun.xml.internal.bind.v2.model.impl.ModelBuilder.link(ModelBuilder.java:439) ~[?:?]
> at com.sun.xml.internal.bind.v2.model.impl.RuntimeModelBuilder.link(RuntimeModelBuilder.java:118) ~[?:?]
> at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:443) ~[?:?]
> at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:277) ~[?:?]
> at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:124) ~[?:?]
> at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl$JAXBContextBuilder.build(JAXBContextImpl.java:1123) ~[?:?]
> at com.sun.xml.internal.bind.v2.ContextFactory.createContext(ContextFactory.java:147) ~[?:?]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
> at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
> at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:247) ~[?:?]
> at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:234) ~[?:?]
> at javax.xml.bind.ContextFinder.find(ContextFinder.java:462) ~[?:?]
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:641) ~[?:?]
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:584) ~[?:?]
>
> I don’t see any substantial difference between those 2 bundles. They have other config files, but the same code parsing them. They use similar package imports etc.
>
> However, one of them always starts, the other one not.
>
> How to start debugging that issue? Have you experienced similar behavior or have hints, what can cause them?
>
> The previous version, in that everything was working stable, was Karaf 4.1.3
>
> Best regards,
> Lukasz Lech