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.si...@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.f...@gmail.com <mailto:freeman.f...@gmail.com>> > Sent: Mittwoch, 12. September 2018 09:08 > To: user@karaf.apache.org <mailto: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.l...@ringler.ch > <mailto:l.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
