I wanted to implement an EJB client for JBoss 7.1 following this tutorial
http://middlewaremagic.com/jboss/?p=1177#comments which is based on the JBoss tutorial:
https://docs.jboss.org/author/display/AS71/EJB+invocations+from+a+remote+client+using+JNDI
I already tried the troubleshooting tips there, but still I get an exception:
javax.naming.NoInitialContextException: Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file: java.naming.factory.initial
Did anyone else encounter this type of problem and knows which jars (or better Maven dependencies) are needed on the classpath?
Best regards,
Helge
Have you referred to the ejb-remote quick start ? https://github.com/jboss-jdf/jboss-as-quickstart/tree/master/ejb-remote
That quick start contains the two Maven projects that are referenced in the jboss.org doc and have all the required dependencies.
Related
This is a strange problem. I have an existing JEE project that is and has been in production on WebSphere 7. It is a multi-module EAR file. It has 2 WARs and 1 shared Java project. Most of it is Spring 4 based, but we have some web services we host using axis2 (1.5.4). This project does not use Maven. It does use a WebSphere deployment.xml (in the EAR) with the warClassloaderPolicy="SINGLE" and the classloader mode="PARENT_LAST". This controls the classloader policies for this EAR. All the jar files that the Java project and the WARs rely on are stored at the EAR level and referenced at the module level via the manifest files. That all works fine and has for several years.
Now I was trying to convert this project to a Maven project after all these years. Initially, I left the deployment.xml file settings as they always have been. But with these settings I was getting:
java.lang.VerifyError at com.sun.xml.bind.v2.model.impl.RuntimeBuiltinLeafInfoImpl "org.springframework.oxm.jaxb.Jaxb2Marshaller".
After much googling on this site and all around and trying 50,000 things, I tried one thing, which worked for most of the app. I switched the classloader mode to "PARENT_FIRST" and all of a sudden the WAR that exclusively uses Spring 4 worked. It started up without error and I was able to run it.
But, the other WAR which hosts the axis2 web services started getting the error:
org.apache.axis2.deployment.WarBasedAxisConfigurator <init> org.apache.commons.fileupload.FileUploadException....Caused by: java.lang.NoClassDefFoundError: org.apache.commons.fileupload.FileUploadException....Caused by: java.lang.ClassNotFoundException: org.apache.commons.fileupload.FileUploadException
This class (org.apache.commons.fileupload.FileUploadException) is in both the compile and runtime classpath. In eclipse I can see it in the "Maven Dependencies" library that the m2e eclipse plugin creates from the POM files. I can also see this jar in the WebSphere runtime module classpath inspector (it shows up in there 3 times! Once under each WAR and once just in a list from the Maven repository location.)
One thing of note is that I've configured the project with a parent POM, where most of the dependencies are declared at the parent and then are inherited for each of the modules. In the EAR project, the POM is using the maven-ear-plugin with skinnyWars=true. However, it appears the skinnyWars directive is not respected when the m2e eclipse plugin deploys the EAR into the local WebSphere server (that is evident because I see these jars showing up in the classpath 3 times). But when I create an EAR using the Maven build, the EAR comes out correctly with each jar only showing up in the EAR one time.
This is my last hope to post something here and see if someone has an idea for something to try, otherwise I can't think of anything else to try.
Thanks...
Is there a particular reason you need to run with a single class loader for all the WAR modules, other than convenience? If not, you could rework the application in order to allow you to run PARENT_FIRST in the Spring WAR and PARENT_LAST in the Axis2 WAR.
If that's not an option for some reason, the path of least resistance might be to go back to PARENT_LAST and remove some libraries from the app or module. The VerifyError generally occurs if you're running with PARENT_LAST and have a library in the app that is also present in the server - in this case, the exception looks like it's coming out of JAXB, so you might want to see if simply removing JAXB (and perhaps JAXP, if present, since it's heavily used by JAXB) from the application resolves the issue with your default setup.
You could also stick with PARENT_FIRST and move the Axis2 jars to an shared library with an isolated class loader, associated with the app. An isolated shared library would make just the stuff in the shared library PARENT_LAST, so you can avoid the VerifyError and still get PARENT_LAST for Axis2. The issue in the PARENT_FIRST case appears to be because you're picking up WebSphere's copy of Axis2 but somehow have a dependency inserted from your app's copy - the failing class load is occurring in a server-level loader, so it doesn't see the copy in your app.
I am trying to run my spring boot application (via Run As -> Spring Boot Application) in a tomcat8 container on STS and I am receiving these errors:
Caused by: java.lang.IllegalStateException: Expected method not found: java.lang.NoSuchMethodException: org.springframework.boot.context.embedded.tomcat.TomcatEmbeddedContext.addApplicationListener(org.apache.catalina.deploy.ApplicationListener)
at org.springframework.util.ClassUtils.getMethod(ClassUtils.java:627)
at org.springframework.boot.autoconfigure.websocket.TomcatWebSocketContainerCustomizer.addListener(TomcatWebSocketContainerCustomizer.java:85)
at org.springframework.boot.autoconfigure.websocket.TomcatWebSocketContainerCustomizer.access$100(TomcatWebSocketContainerCustomizer.java:36)
at org.springframework.boot.autoconfigure.websocket.TomcatWebSocketContainerCustomizer$1.customize(TomcatWebSocketContainerCustomizer.java:50)
at org.springframework.boot.context.embedded.tomcat.TomcatEmbeddedServletContainerFactory.configureContext(TomcatEmbeddedServletContainerFactory.java:355)
at org.springframework.boot.context.embedded.tomcat.TomcatEmbeddedServletContainerFactory.prepareContext(TomcatEmbeddedServletContainerFactory.java:184)
at org.springframework.boot.context.embedded.tomcat.TomcatEmbeddedServletContainerFactory.getEmbeddedServletContainer(TomcatEmbeddedServletContainerFactory.java:154)
at org.springframework.boot.context.embedded.EmbeddedWebApplicationContext.createEmbeddedServletContainer(EmbeddedWebApplicationContext.java:157)
at org.springframework.boot.context.embedded.EmbeddedWebApplicationContext.onRefresh(EmbeddedWebApplicationContext.java:130)
... 7 more
I have searched around for this quite a bit and have found little to guide me in figuring out what the problem is. After going through the spring boot code in the debugger I see that the object named "instance" referenced in the TomcatWebSocketContainerCustomizer.addListener() uses reflection to retrieve a handle to it. This object is associated with the tomcat 7.0.53 jar ($HOME/.m2/repository/org/apache/tomcat/tomcat-catalina/7.0.53/tomcat-catalina-7.0.53.jar). I do not see this in any of my maven dependencies and have tried several techniques to force it to tomcat 8.0.20, nothing seems to work.
After banging my head for a while I started looking at the run configuration for the project in STS (via Run As -> Run Configurations). I found that the Source tab shows tomcat 7.0.53 above version 8.0.20 along with several dependencies that aren't referenced in maven. I am at a loss on where these values come from and not sure how to edit it. For some reason when I try to manually delete these legacy jar files STS doesn't allow me to delete any of them.
Does anyone have an idea of where these dependencies may be coming from and how I can remove them?
They do reference my $HOME/.m2/path/to/tomcat-catalina/<version> dir, so I could simply remove them from my .m2 and theoretically it may work but I'd rather not do this if I don't have to.
I am using spring boot 1.2.x and all of them have this problem.
thanks.
I've got two ideas that you might try.
1) It is possible, that this may be manifestation of this bug in STS 3.6.4: https://issuetracker.springsource.com/browse/STS-4085
The depencies you aren't expecting to see may be coming from the maven 'test' scope. (The bug explicitly mentions 'srt/test' but the same happens with jar dependencies). You can verify whether this bug is the cause by using the regular "Run As Java Application" on your main class.
If that works, then it is almost certainly this bug. If it also fails with a similar error then its something else... then try:
2) You must be getting the unwanted tomcat version from somewhere, probably indirectly as dependency of something else.
Try using the m2e 'dependency hierarchy' to find where it came from like so:
open pom.xml
Click the 'Dependency Hierarchy' tab.
Type 'tomcat' in the 'Filter' box.
I finally figured it out.
In my $WORKSPACE/.metadata/.plugins/org.eclipse.m2e.core/workspacestate.properties it lists all poms, jars and wars from my workspace build with the maven plugin. I noticed that a pom in the file points to the exact version tomcat that is being loaded in my spring boot project. Once I deleted these projects from my STS I can successfully launch the spring boot app :-)
When I re-import the maven projects back to STS the error occurs again, then disappears when I remove them.
These projects have no connection to the project that I am trying to launch. Therefore I think the bug is in m2e.
I'll file a bug and update this post when it is complete.
thanks #Kris for working through it with me.
I am using aspectJ in my project and added dependencies in my POM file. When i am running my application on Websphere Application Server Liberty Profile, in the library folder aspectj.jar is not getting added/created. I am very new to using spring and never used server's to run a application. When i am trying to run the application on the server i am getting the following exception:
Caused by: java.lang.ClassNotFoundException: org.aspectj.weaver.reflect.ReflectionWorld$ReflectionWorldException
Can anyone please team whats going on wrong with the application ?
Thanks!
You'll need to make sure that aspectj is available to your application at runtime. The two basic approaches for this are to package it up with your application zip, or to make it available as a shared library in the server. The first approach has the advantage that you don't need to do any extra config, and no matter where you run your application, the dependency will be there. However, it has the disadvantage of bloating your application. If you end up running multiple applications on the server, it could also cause the apps to use more memory than they would if they were just using a shared copy.
For the first approach, if your dependency has the default scope in the pom, maven should automatically copy it to WEB-INF/lib (assuming your application is a war).
For the second approach, you can configure it in Liberty as a global library (available to all applications) by copying it to a wlp/usr/shared/config/lib/global folder in your Liberty install.
I am trying to get an apache camel app using CXF working on WebSphere.
Noticed a number of errors
Caused by: java.lang.IncompatibleClassChangeError: org.apache.neethi.AssertionBuilderFactory
at java.lang.ClassLoader.defineClassImpl(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:262)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:69)
This occurs because the org.apache.neethi classes are loaded from the WAS run-time instead of the neeti3.0.2.jar from WEB-INF/lib
here is the info from class loader:
class load: org.apache.neethi.builders.AssertionBuilder from: file:/D:/Tools/WebSphere/AppServer/plugins/org.apache.axis2.jar
The Web Application config has been changed to use the class loader policy. It is set to Parent Last. Yet this class seems to be using the Parent First Policy.
Is there anything in the CXF package that over-rides this policy?
I noticed that using Axis2 and WAS
http://axis.apache.org/axis2/java/core/docs/app_server.html
Avoiding conflicts with WebSphere's JAX-WS runtime has some additional steps mentioned for Axis2. Is there something similar that is required to get this to work?
Thanks
Manglu
Not specific to Camel, but we are dealing with a similar issue.
1) You can use an isolated shared library if you want. This seems to fix the classloader from pulling in these other libraries via OSGi. This solution isn't for everyone.
2) When setting an app that PARENT_LAST, make sure you're doing it in the correct place. If you have jars inside your wars, then you'll have to set PARENT_LAST on the WAR modules, not the application. In the WAS console> Applications > Application Type > websphere enterprise applications> MyEAR > manage Modules > MyWar > Change the "Class loader order" and make it "parent last"
3) After you make your changes, you can export the ear file. In the ear, there is a file META-INF/ibmconfig/cells/defaultCell/applications/defaultApp/deployments/defaultApp/deployment.xml that has this config. For maven ear's, you can put this into src/main/application for it to be packaged up with the ear.
Hope that this helps. Good luck.
We are discussing a similar topic at the Camel mailing lists. I suggest to take a look there: http://camel.465427.n5.nabble.com/camel-cxf-in-WebSphere-without-geronimo-jetty-depdendencies-possible-tp5726490.html
I am currently working on a portlet that is using the commons-collections jar file and am getting a NoSuchMethodError. To resolve this issue I need to change the classloader of my WAR file from PARENT_FIRST to PARENT_LAST (in the application.xml file).
However, when I do this my portlet will not launch and when I log into the console it displays the message "The portlet is temporarily disabled". If I change the classloader back to PARENT_FIRST then it will launch again but then I get the NoSuchMethodError.
Does anybody have any suggestions on how to fix this issue ?
I am not sure how, but today I started getting error messages in the logs when I was getting "The portlet is temporarily disabled". I was getting a java.lang.LinkageError which was down to the fact that I had the servlet-api-2.5.jar and a jaxb jar which was conflicting with webshpere j2ee.jar. Once I removed these dependencies and set the classloader to PARENT_LAST, it seems to work properly. It seems that a lot of people face similar issues. The link below is also useful http://forum.springsource.org/showthread.php?33663-dispatcher-servlet-quot-not-a-servlet-class-quot-in-websphere
#MTH,
please try adding commons-collections as a shared library. See here for an example on how others have used shared library support [1]. That will give you the steps, just do it for the jars that you need to override/replace from WAS's classloader
[1] http://portals.apache.org/jetspeed-2/deployguide/deploying-jetspeed-to-websphere.html#section_4_2
thanks,
dims
You haven't provided any logs... but still, one of the most important things to look out for when setting your application to run PARENT_LAST is that your application isn't bundled with any system-level classes that may conflict with the ones provided by WebSphere Portal. For example, classes that pertain to the Portlet specification or the JavaEE specification.