I want to create a simple web service in Eclipse (Helios J2EE), using Apache CXF 2.3.2 and Tomcat 7.
However, when I use the 'New web service' wizard, I get the following error at WSDL creation:
java.lang.LinkageError: JAXB 2.1 API is being loaded from the bootstrap classloader, but this RI (from jar:file:/C:/Users/me/apache-cxf-2.3.2/lib/jaxb-impl-2.2.1.1.jar!/com/sun/xml/bind/v2/model/impl/ModelBuilder.class) needs 2.2 API. Use the endorsed directory mechanism to place jaxb-api.jar in the bootstrap classloader. (See http://java.sun.com/j2se/1.6.0/docs/guide/standards/)
at com.sun.xml.bind.v2.model.impl.ModelBuilder.<clinit>(ModelBuilder.java:173)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:456)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:302)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl$JAXBContextBuilder.build(JAXBContextImpl.java:1140)
at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:154)
at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:121)
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 javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:210)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:368)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:574)
at org.apache.cxf.jaxb.JAXBDataBinding.createContext(JAXBDataBinding.java:557)
at org.apache.cxf.jaxb.JAXBDataBinding.createJAXBContextAndSchemas(JAXBDataBinding.java:497)
at org.apache.cxf.jaxb.JAXBDataBinding.initialize(JAXBDataBinding.java:324)
at org.apache.cxf.service.factory.AbstractServiceFactoryBean.initializeDataBindings(AbstractServiceFactoryBean.java:87)
at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:445)
at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:508)
at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:245)
at org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:101)
at org.apache.cxf.frontend.AbstractServiceFactory.createService(AbstractServiceFactory.java:78)
at org.apache.cxf.tools.java2wsdl.processor.JavaToWSDLProcessor.process(JavaToWSDLProcessor.java:101)
at org.apache.cxf.tools.java2ws.JavaToWSContainer.processWSDL(JavaToWSContainer.java:110)
at org.apache.cxf.tools.java2ws.JavaToWSContainer.execute(JavaToWSContainer.java:75)
at org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:103)
at org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:58)
at org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:40)
at org.apache.cxf.tools.java2ws.JavaToWS.run(JavaToWS.java:77)
at org.apache.cxf.tools.java2ws.JavaToWS.main(JavaToWS.java:45)
I found some posts suggesting to copy jaxb-api-2.2.1.jar in %JAVA_HOME%/lib/endorsed, but that doesn't work for me...
Any idea? Thanks
Ok, some information may help you solve this problem by your own:
java.lang.LinkageError: JAXB 2.1 API is being loaded from the bootstrap classloader, but this RI (from jar:file:/C:/Users/me/apache-cxf-2.3.2/lib/jaxb-impl-2.2.1.1.jar!/com/sun/xml/bind/v2/model/impl/ModelBuilder.class) needs 2.2 API. Use the endorsed directory mechanism to place jaxb-api.jar in the bootstrap classloader. (See http://java.sun.com/j2se/1.6.0/docs/guide/standards/)
Do you know what is the bootstrap classloader? Its a "super" class loader. If you put a JAR in this classloader you can overwrite even java.lang.* classes. It's the first class loader in any Java application. It's a powerfull thing.
Let's take a look in your message:
JAXB 2.1 API is being loaded from the bootstrap classloader, but this RI ([...]) needs 2.2 API [...].
You just need to replace the version of your JAXB API, right? So, check what is on your bootstrap class loader (try print all JAVA_* variables and Java start line to find your bootstrap) and find what is wrong. Probably some JAR has the old version of JAXB and need to be replaced. Only that.
Related
I just downloaded Wildfly 9.0.0.CR2 with Java 7 on Mac 10.9.5. I notice by default, Wildfly 9 includes a bouncycastle module (modules/system/layers/base/org/bouncycastle/main/bcprov-jdk15on-1.52.jar) . I would like to install another bouncycastle module in Wildfly (bcprov-jdk16-1.46.jar). Is there a way I can disable the one that JBoss has included? When I tried to delete the module Jboss included (the modules/system/layers/base/org/bouncycastle/ folder), I get the error upon JBoss startup
08:36:19,086 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131)
at org.jboss.as.server.ServerService.boot(ServerService.java:350)
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:271)
at java.lang.Thread.run(Thread.java:745)
Caused by: javax.xml.stream.XMLStreamException: WFLYCTL0083: Failed to load module org.jboss.as.weld
at org.jboss.as.controller.parsing.ExtensionXml.parseExtensions(ExtensionXml.java:155)
at org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_4(StandaloneXml.java:433)
at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:144)
at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:106)
at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69)
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123)
... 3 more
You might have a look at this discussion, it is almost the same thing you want to do (opposite direction w.r.t. versions):
BouncyCastle 1.51 loading in war on Wildfly 8.0
The long and the short of it is, you can create a custom module (or, I think, another slot for the existing module?) and reference that one in your jboss-deployment-structure.xml instead of the default module wildfly is bringing with it.
If you don't want/need BC as a module, you could also just include it in the lib folder of your EAR/WAR and it will be loadable from there.
Our deployment structure looks essentially like this:
my.ear
+ lib/ <-- dependencies for multi-submodule deployment
+ META-INF/ <-- application.xml defines submodule(s) e.g. web.war,
<-- also jboss-deployment-structure.xml to include/export wildfly core modules for your EAR
+ web.war <-- our core deployment
And we include e.g. a different version of hibernate than in wildfly. I expect you can include a different BC version in your ear as well.
See also:
https://docs.jboss.org/author/display/WFLY8/Class+Loading+in+WildFly
Custom module tutorial:
http://middlewaremagic.com/jboss/?p=1933
Similar issue with resolution: https://developer.jboss.org/thread/175395
WildFly uses modular classloading and as such not everything is on classpath of every module.
Deployment itself is just another module that gets extra dependencies based on what deployment descriptors tell server should be added.
When it comes to bouncycastle, there are modules that themselves require it, but that doesn't mean they will expose this dependency to your deployment.
There was a bug in 8.0 that caused that BC was exposed to user deployment in case when user deployment was using web services. This was fixed since than.
Given that you use WildFly 9 that shouldn't a problem anymore.
As other suggested, you can create new module with different name or at least different slot name, which you can than include via your jboss-deployment-structure.xml
Just btw, bcprov-jdk16-1.46 is much older than what is provided in WildFly.
I am trying to implement JPA using DataNucleus in an OSGI Environment (Apache ServiceMix). I am following the guide mentioned here - http://www.datanucleus.org/products/datanucleus/jpa/osgi.html (Section under Name "JPA and OSGi")
As per the documentation here I am using the DataNucleus JPA jar. So I have Deployed this Jar on ServiceMix as follows -
osgi:install mvn:org.datanucleus/datanucleus-jpa/2.1.7
osgi:start bundleId
As this jar export the persistence provider,I have correctly changed the provider in my persistence.xml file to be org.datanucleus.jpa.PersistenceProviderImpl (which is exported by the above bundle) rather than usual org.datanucleus.api.jpa.PersistenceProviderImpl which is in a normal J2EE JPA APP.
I also have the DataNucleus Core Bundle running on my ServiceMix, which was installed on my ServiceMix using the following -
osgi:install mvn:org.datanucleus/datanucleus-core/4.0.0-release
osgi:start bundleId
Please Note: I donot have the datanucleus-api-jpa bundle running on my ServiceMix, as per the documentation, the datanucleus-jpa bundle would export the necessary classes and hence datanucleus-api-jpa bundle would not be required.
At runtime, I am getting the following error Caused by: java.lang.ClassNotFoundException: org.datanucleus.PersistenceConfiguration not found by org.datanucleus.jpa [261]
What I have noticed is that the DataNucleus Core version 4.0.0-release does not have this class, but this class exists in all previous releases (3.2.15).
I cannot deploy DataNucleus Core Version 3.2.XX onto my ServiceMix, because I have other bundles using DataNucleus Core 4.0.0-release and having both is not an option because of Singleton Creation problems.
Please let me know, if you need me to post my code, I will do so.
Please help
Cheers,
Abhijit
In conclusion, you are using incorrect/invalid jars. "datanucleus-jpa" was removed back in v2 of DataNucleus. All recent versions using "datanucleus-api-jpa" (or "datanucleus-api-jdo" if using JDO). A simple download of the DataNucleus zip file for 4.0.x would show this very clearly.
I try to deploy a simple application in Scala using akka on Tomcat 7.
In the first version, the actor system and the main actor were started directly from a Scala object.
In the second version, I created an initializer (extending ServletContextListener) in order to start the actor system and the actor at the deployment of the war.
In both case, I get a java.lang.LinkageError like the following :
java.lang.LinkageError: loader constraint violation: when resolving method "akka.actor.Props$.apply(Lscala/reflect/ClassManifest;)Lakka/actor/Props;" the class loader (instance of org/apache/catalina/loader/WebappClassLoader) of the current class, com/my-app/Transfert$, and the class loader (instance of org/apache/catalina/loader/StandardClassLoader) for resolved class, akka/actor/Props$, have different Class objects for the type scala/reflect/ClassManifest used in the signature
com.my-app.Transfert$.<init>(Transfert.scala:14)
com.my-app.Transfert$.<clinit>(Transfert.scala)
com.my-app.Transfert.getState(Transfert.scala)
org.apache.jsp.transfert_jsp._jspService(transfert_jsp.java:85)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:433)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:389)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:333)
javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
I searched on Google and everywhere, but I didn't find a simple example of how to deploy a Scala/akka application on Tomcat 7 ?
I know there was an akka.http package in akka 1.3, but I want to use akka 2.0 (at least). It seems akka.http has disappeared in favor of the use of play-mini. But I would prefer not to use play-mini or play.
Is there any advice ? Any reading suggestion ? Or ??
We have Akka actors 2.1 running inside Jetty 8 - it should not be too different.
You seem to be facing ClassLoader issues (I assume you are using java 6 and do not have binary compatibilities issues).
May I suggest you try to remove scala-library.2.10.0.jar and akka-actor_2.10-2.1.0.jar from your war and drop them in the tomcat 7 lib folder ?
I want to not use the built in Websphere 7 jpa plugin, instead use an application WEB-INF/lib/open-jpa 2 and a proprietary persistence provider. I cannot install the OSGI and JPA 2 feature pack for Websphere.
Originally, I was getting a sax parse error simply trying to load the persistence.xml (version="2" not supported). The error was thrown by a class in open-jpa 1.2.3. When I run websphere/appserver/bin/wsjpaversion.bat, the open-jpa 1.2.3 jar is displayed. By default it overrides the open-jpa 2 jar in the app. I created a shared library containing the open-jpa 2 jar with this config option checked: 'Use an isolated class loader for this shared library'. I set my application classloader to load parent last and assigned it the new shared library resource. The 'version 2' error is gone, but there is another problem. When I try to initialize an EntityManager I get an error:
Caused by: javax.persistence.PersistenceException: Failed to load provider from META-INF/services
at javax.persistence.spi.PersistenceProviderResolverHolder$DefaultPersistenceProviderResolver.getPersistenceProviders(PersistenceProviderResolverHolder.java:121)
at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:91)
at java.lang.J9VMInternals.initializeImpl(Native Method)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:200)
... 2 more
Caused by: java.lang.ClassCastException: com.ibm.websphere.persistence.PersistenceProviderImpl incompatible with javax.persistence.spi.PersistenceProvider
at javax.persistence.spi.PersistenceProviderResolverHolder$DefaultPersistenceProviderResolver.getPersistenceProviders(PersistenceProviderResolverHolder.java:110)
... 11 more
One more detail: inside the persistence.xml, the provider element is set to the proprietary PersistenceProviderImpl not the default Websphere persistence provider. So where is this websphere default coming from and how do I prevent it? (another important note: when I remove persistence.xml completely, I get the same error)
Thank you
Without installing the feature pack, you're fighting a losing battle. While it is possible to plug in your own JPA implementation, it is not possible to do that with JPA API — so WAS 7 ties you to the 1.0 version of JPA (see, for example, here how this is done — no class loader policy juggling will change that, though it seems tempting at first).
I have created one workbench application plugin not eclipse rcp application. I have not created any plugin template for that workbench application.
Now When I run the workbench application Activator is not calling. I put System.out.println("Insided start()") inside the start method of the
Activator.java. But it is not calling the start method. How I make call the start method? But when I make the option,Autostart=true in the runconfiguration,plug-ins,
It is starting the activator. But the problem is When I call IWorkbenchWindow window = Workbench.getInstance().getActiveWorkbenchWindow();
It is giving the error message saying could not create the workbench window. This error message is giving only when I make this plugin as AutoStart=true. What couldbe the problem?
Following are the error message I get..When I use
IWorkbenchWindow window = PlatformUI.getWorkbench().getActiveWorkbenchWindow();
java.lang.IllegalStateException: Workbench has not been created yet.
at org.eclipse.ui.PlatformUI.getWorkbench(PlatformUI.java:92) at
myworkbenchplugin.Activator.custom(Activator.java:43) at
myworkbenchplugin.Activator.start(Activator.java:36) at
org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:783)
at java.security.AccessController.doPrivileged(Native Method) at
org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:774)
at
org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:755)
at
org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:370)
at
org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:374)
at
org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1067)
at
org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:561)
at
org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:546)
at
org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:459)
at
org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:243)
at
org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:440)
at
org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:227)
at
org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:337)
As you already saw, you need to manage your OSGi bundle manifest to specify the right activation policy. Note though that:
The Eclipse-AutoStart and Eclipse-LazyStart headers have been deprecated in Eclipse 3.4.
As of the OSGi R4.1 specification the lazy activation policy has been adopted by the OSGi specification. The new OSGi bundle manifest header Bundle-ActivationPolicy can be used to specify a lazy activation policy.
The Equinox Framework version 3.4 or later will continue to support the deprecated Eclipse-LazyStart and Eclipse-AutoStart headers.
Bundle developers that want their bundles to work across other OSGi Framework implementations should add the Bundle-ActivationPolicy header to their manifest. In most cases you can simply add the following header:
Bundle-ActivationPolicy: lazy
See OSGi LazyStart design.
In your case, you can try Bundle-ActivationPolicy: lazy;exclude:="yourPluginId" if you want to be sure your plugin starts no matter what.
For getting the Active WorkbenchWindow, you can use PlatformUI.getWorkbench().getActiveWorkbenchWindow() as detailed in How to get the project name in eclipse?.
If you start your plugin when Eclipse starts, the Activator.start() will be called before the workbench is fully started. You need to push the code inside a UIJob/WorkbenchJob in the Activator, so that it will be called after the workbench windows are ready.