I am working on some migration project, involves moving around quite a few stuff from Ant/CVS/Jboss4/Java5 to Maven/SVN/Jboss7/Java6 - this gets nasty.
First step, I am working on moving the ant build to maven - that it in iteslf involve a lot of complication. Now that I get the ear file built, and I compared it with the ear from ant build, I think I got it good with the maven build.
Now, deploying on Jboss4 first, I encouter
[ejb.EJBDeployer.verifier] EJB spec violation:
Warning: The message driven bean must declare one onMessage() method.
2011-11-08 15:25:03,079 ERROR (Thread: main) [jboss.deployment.MainDeployer] Could not create deployment: file:/opt/jboss-4.0.3SP1/server/default/tmp/deploy/tmp46514Billing-EAR-1.0.ear-contents/processsubscriptionbean-1.0.jar
org.jboss.deployment.DeploymentException: Verification of Enterprise Beans failed, see above for error messages.
at org.jboss.ejb.EJBDeployer.create(EJBDeployer.java:575)
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:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:118)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:127)
at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:80)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
at $Proxy24.create(Unknown Source)
at org.jboss.deployment.MainDeployer.create(MainDeployer.java:935)
at org.jboss.deployment.MainDeployer.create(MainDeployer.java:925)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:789)
I came across this thread jBoss deployment of message-driven bean spec violation - so I figured I was using the wrong library on my new maven build, I replaced it and made sure it's using the same javax.jms library (this now points to the same jar containing javax.jms.Message as the original ant build) - in fact I simply grabbed the jar referenced by the ant build and upload it to maven repo and reference it from my maven build.
But I still encounter the above problem. The original ant-build would deploy with no problem, but currently I am stuck at this issue for the maven-build ear.
Any suggestion on what other steps i can take to make sure there are no different class files issue? Thanks!
Is the javax.jms library being packaged in your ear (jboss-j2ee.jar, jboss-client.jar, etc)? If so, you don't want that since you want to use the one provided by the app server. You can fix this by changing the dependency in your pom to have the <scope>provided</scope> for anything that shouldn't be in your ear.
Related
I've been working on an Eclipse plugin codebase that builds with Maven Tycho. I can provide some snippets that anyone asks for, but you can get the code at https://git.opendaylight.org/gerrit/#/admin/projects/yangide (I believe that should be open).
I usually test it with an "Eclipse Application" launch config, loading all the plugins in the workspace. This works.
I sometimes test it by referencing the update site zip that I build locally. This works most of the time.
Recently, someone else I work with has deployed the update site to a public URL (https://nexus.opendaylight.org/content/sites/p2repos/org.opendaylight.yangide). This was built from master.
When I install from this into a standalone Eclipse, at some point after startup I see the following error:
Exception:java.lang.LinkageError: org/antlr/v4/runtime/TokenStream
at org.antlr.v4.runtime.Parser.setInputStream(Parser.java:530)
at org.antlr.v4.runtime.Parser.<init>(Parser.java:182)
at org.opendaylight.yangtools.antlrv4.code.gen.YangParser.<init>(YangParser.java:188)
I've actually seen this same exception sometimes when testing with the locally built update site zip, but rarely. I'm seeing it every time with this deployed update site.
So I understand that "Linkage Error" means that the class had already been loaded by another classloader which conflicts with this.
So, I started it up again with "-verbose:class" to at least see some information about the loading of this class.
From this output, I saw the following:
[Loaded org.antlr.v4.runtime.TokenStream from file:/home/opnfv/frameworks/eclipse-neon/java-mars/eclipse/../../../../.p2/pool/plugins/net.sf.eclipsecs.checkstyle_6.16.0.201603042321/checkstyle-6.16.1-all.jar]
[Loaded org.antlr.v4.runtime.TokenStream from file:/home/opnfv/frameworks/eclipse-neon/java-mars/eclipse/configuration/org.eclipse.osgi/605/0/.cp/libs/antlr4-runtime-4.5.1.jar]
[Loaded org.antlr.v4.runtime.TokenStream from file:/home/opnfv/.m2/repository/org/antlr/antlr4-runtime/4.5.1/antlr4-runtime-4.5.1.jar]
Note that this plugin obtains several jars from a Maven repo, as opposed to a p2 repo, including the "antlr4-runtime-4.5.1.jar" file. Most of these jars are not available in a public p2 repo. One of the plugins uses the "copy" and "copy-dependencies" goals of the "maven-dependency-plugin" to get Maven artifacts, and then specifies the local paths to those jars in the "Bundle-ClassPath" property in the META-INF/MANIFEST.MF file. other plugins in the codebase specify that plugin as a dependency.
Update:
Note that I sometimes see the following variation of this in the log:
Exception in thread "Yang indexer" java.lang.LinkageError: loader constraint violation: loader (instance of org/eclipse/osgi/internal/loader/EquinoxClassLoader) previously initiated loading for a different type with name "org/antlr/v4/runtime/TokenStream"
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.defineClass(ModuleClassLoader.java:272)
at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.defineClass(ClasspathManager.java:632)
at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findClassImpl(ClasspathManager.java:588)
at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClassImpl(ClasspathManager.java:540)
at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClass(ClasspathManager.java:527)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.findLocalClass(ModuleClassLoader.java:324)
at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:327)
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:402)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:352)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:344)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:160)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at org.antlr.v4.runtime.Parser.setInputStream(Parser.java:530)
Update:
I realized that it might be useful to add "-verbose:class" to the launch config test case, because that is not having this problem. When I searched for the same class reference in the output, I only saw one occurrence:
[Loaded org.antlr.v4.runtime.TokenStream from file:/home/opnfv/workspace3/.metadata/.plugins/org.eclipse.pde.core/.bundle_pool/../../../../../../../media/sf_laptophome/git/yangide/plugins/com.cisco.yangide.yangparser/libs/antlr4-runtime-4.5.1.jar]
Remember that this is just loading the plugins from the workspace. This path is essentially in my workspace. In any case, it never tried to load it from those other two jar files.
This was because the Checkstyle Eclipse plugin "leaked" another version of ANTLR into this other (yangide) Eclipse plugin which uses a Package-Import.
I'm using Jenkins 1.6.20 (Git Client Plugin 1.18.0, Git Plugin 2.4.0) to get the Java application code from bitbucket.org and deploy it to Apache Tomcat 8.0.23.
The error appears while deploying and looks like:
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'requestMappingHandlerMapping' defined in class path resource [org/spr$
public java.util.List by.ipps.accounting.ws.PositionWS.getEmployeePost(java.lang.Long)
to {[/positionListJson/{id}],methods=[GET],params=[],headers=[],consumes=[],produces=[application/json],custom=[]}: There is already 'resourceWS' bean method
public by.ipps.accounting.model.Employee.EmployeePost by.ipps.accounting.ws.ResourceWS.getEmployeePost(java.lang.Long) mapped.
bla-bla-bla ... so many errors ...
Caused by: java.lang.IllegalStateException: Ambiguous mapping found. Cannot map 'positionWS' bean method
public java.util.List by.ipps.accounting.ws.PositionWS.getEmployeePost(java.lang.Long)
to {[/positionListJson/{id}],methods=[GET],params=[],headers=[],consumes=[],produces=[application/json],custom=[]}: There is already 'resourceWS' bean method
public by.ipps.accounting.model.Employee.EmployeePost by.ipps.accounting.ws.ResourceWS.getEmployeePost(java.lang.Long) mapped.
The problem is that the class (with annotation #Controller) PositionWS with method getEmployeePost was renamed to ResourceWS a week ago, so exists no more, so I should not get this error.
To fix this I have to create a blank PositionWS controller (with no methods in it), commit & push that to bitbucket (and delete (cus i really don't need it) later and commit & push).
It seems to be like a bug in any of the applications I use. I can't find out in which app there is a bug to report it. Tell me please, if anyone faced such problems.
The heart of the issue was in incorrect configuration of Jenkins, it was my fault.
When I was configuring Jenkins I set maven goal as "install", but it must be "clean install". According to this Jenkins never deleted old files and kept them, so got a lot of issues of different kinds and with different log messages.
Due to Jenkins working specialty it downloads project files and try to assemble it on path /var/lib/jenkins/jobs/<projectName>/workspace/target/.
So I've drop the data in this folder and afterwards set maven goal to "clean install" and that fixed the issue.
I am trying to add metrics library to existing webservice on WAS 7. I am getting below error
Error 404: javax.servlet.UnavailableException: SRVE0203E: Servlet [AdminServlet]: com.yammer.metrics.reporting.AdminServlet was found, but is missing another required class. SRVE0206E: This error typically implies that the servlet was originally compiled with classes which cannot be located by the server. SRVE0187E: Check your class path to ensure that all classes required by the servlet are present.SRVE0210I: This problem can be debugged by recompiling the servlet using only the classes in the application's runtime class path SRVE0234I
What are the other run-time dependencies required for metrics-servlet-2.2.0?
I have metrics-core-2.2.0.jar and metrics-servlet-2.2.0.jar in my WEB-INF\lib folder.
Threads, ping and healthcheck servlets work fine.
I think your missing some more required jars, are you not using maven or gradle for dependency management
Please refer here to know all required jars that metrics-servlet-2.2.0.jar depends on. http://mvnrepository.com/artifact/com.yammer.metrics/metrics-servlets/3.0.0-BETA1
My suggestion is, it is always difficult to maintain dependencies without Maven/Gradle or any other build tools :).
I'm trying to see if Quartz can solve a problem for me. But I can't get it to work. Right now I'm stuck at the following error (relevant part)
Caused by: org.quartz.SchedulerConfigException: Unable to instantiate class load helper class: org.quartz.simpl.CascadingClassLoadHelper cannot be cast to org.quartz.spi.ClassLoadHelper [See nested exception: java.lang.ClassCastException: org.quartz.simpl.CascadingClassLoadHelper cannot be cast to org.quartz.spi.ClassLoadHelper]
at org.quartz.impl.StdSchedulerFactory.instantiate(StdSchedulerFactory.java:706)
at org.quartz.impl.StdSchedulerFactory.getScheduler(StdSchedulerFactory.java:1484)
at org.jboss.seam.async.QuartzDispatcher.initScheduler(QuartzDispatcher.java:69)
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 org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:144)
... 73 more
Caused by: java.lang.ClassCastException: org.quartz.simpl.CascadingClassLoadHelper cannot be cast to org.quartz.spi.ClassLoadHelper
at org.quartz.impl.StdSchedulerFactory.instantiate(StdSchedulerFactory.java:703)
I have googled and it seems to be a question that is asked a lot but I don't find any answers. I have the quartz-jars in both my webapp and ear.
Is there anything in my configuration that can cause this problem?
JBoss 5.1
Quartz JBoss 2.1.6
This is a class loading issue. JBoss already has the org.quartz.spi.ClassLoadHelper.class in its class path since JBoss uses it for internal timers for different tasks. The JBoss provided quartz.jar is located in /jboss-as/common/lib/quartz.jar . So you are providing another quartz.jar with your application which is causing conflict with the existing quartz classes that is provided with JBoss.
To solve this issue you have two options:
Option 1. Remove the quartz jars from your ear and war. This is the better and easier option in my opinion unless for some reason you need a different version of quartz for your application than the one JBoss provides.
Option 2. Create a META-INF\jboss-classloading.xml file and isolate your ear (and may be your WAR WEB-INF\jboss-classloading.xml if there is a need for the EAR classes to not see WAR classes). This blog is one of the good ones at explaining the jboss5 or jboss6 class loading and this tutorial based blog is also a good resource.
I'm working on a project which includes persistence library (JPA 1.2), EJB 3 and Web presentation layer (JSF). I develop application using Eclipse and application is published on Websphere Application Server Community Edition (Geronimo 2.1.4) through eclipse plugin (but the same thing happens if I publish manually). When publishing to server I get the following error:
java.lang.NoClassDefFoundError: Could not fully load class: manager.administration.vehicles.VehicleTypeAdminBean
due to:manager/vehicles/VehicleType
in classLoader:
org.apache.geronimo.kernel.classloader.TemporaryClassLoader#18878c7
at org.apache.xbean.finder.ClassFinder.(ClassFinder.java:177)
at org.apache.xbean.finder.ClassFinder.(ClassFinder.java:146)...
In web.xml I have reference to EJB:
<ejb-local-ref>
<ejb-ref-name>ejb/VehicleTypeAdmin</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<local>manager.administration.vehicles.VehicleTypeAdmin</local>
<ejb-link>VehicleTypeAdminBean</ejb-link>
</ejb-local-ref>
EJB project has a reference to persistence project, and Web project has references to both projects. I don't get any compilation errors, so I suppose classes and references are correct.
I don't know if it is app server problem, but I ran previously application on the same server using same configuration parameters.
Does anybody have a clue what might be the problem?
Looks almost like it couldn't find the class manager.vehicles.VehicleType when it was attempting to create/load the class manager.administration.vehicles.VehicleTypeAdminBean.
I've encountered similar problems before. When the class loader attempts to load the class it looks at the import statements (and other class usage declarations) and then attempts to load those classes and so on until it reaches the bottom of the chain (ie java.lang.Object). If it cannot find one class along the chain (in your case it looks like it cannot load VehicleType) then it will state that it cannot load the class at the top of the chain (in your case VehicleTypeAdminBean).
Is the VehicleType class in a different jar? If you have a web module and and EJB module do you have the jar containing the VehicleType class in the appropriate place(s). Sometimes with web projects you have to put the jars in the WebContent/WEB-INF/lib folder or it won't find them.
Are both of these projects deployed separately (ie. two ears? or one ear and one war?) or are they together (ie, one ear with jars and a war inside?). I'm assuming the second given you declared your EJB local?
The jars that you are dependent on also have to be declared in your MANIFEST.MF files in the projects that use it.
I'm kind of running on guesses since I do not know your project structure. Showing that would help quite a bit. But I'd still check on where VehicleType is located with regards to your EJB class. You might find it isn't where you think it is come packaging or runtime.
Thanks #Chris for WebContent/WEB-INF/lib idea ! it works for me by following these steps :
1- Export my EJBs to a JAR (MyEJBs.jar)
2- I created another jar with your_installation_path/IBM/SDP/runtimes/your_version/binCreateEJBStrub.bat via CMD.exe, by executing this command :
createEJBStubs.bat <my_path>/MyEJBs.jar -newfile –quiet
3- A new jar will be automatically created in the same directory as MyEJBs.jar named MyEJBs_withStubs.jar
4- Put your new jar in WebContent/WEB-INF/lib
5- Call your EJBs by :
MyEJBRemote eJBRemote;
InitialContext ic = new InitialContext();
obj = ic.lookup("your_ejb_name_jndi");
eJBRemote = (MyEJBRemote ) PortableRemoteObject.narrow(obj,
MyEJBRemote.class);
eJBRemote = (MyEJBRemote ) obj;
Now you can call your EJBs from another EAR