Websphere 8.5.5.2
Trying to deploy spring boot application in to websphere server. I already made sure class loader policy is parent last. Issue seems because websphere may need some additional configuration to recognize war without any web.xml? Not sure. Getting below error.
Caused by: javax.xml.bind.JAXBException: ClassCastException: attempting to cast jar:file:/usr/WebSphere850/AppServer/endorsed_apis/jaxb-api.jar!/javax/xml/bind/JAXBContext.class
to
wsjar:file:/usr/WebSphere850/AppServer/profiles/node01/installedApps/dchislwsapp020Cell01/My%20Application%20Service%20-%20Test%20Service.ear/test-plan-rest.war/WEB-INF/lib/jaxb-api-2.2.11.jar!/javax/xml/bind/JAXBContext.class.Please make sure that you are specifying the proper ClassLoader.`
You should be able to do this by adding
DisableIBMJAXWSEngine: true
to your application's META-INF/MANIFEST.MF to disable it at the application level.
To disable it at the server level follow the directions at: http://www-01.ibm.com/support/knowledgecenter/SS7JFU_6.1.0/com.ibm.websphere.express.doc/info/exp/ae/twbs_thirdparty.html?cp=SS7JFU_6.1.0%2F1-7-9-4-1-14-0 to disable at the server level.
Related
I am facing an issue in my restlet project where I have to code some operations only if the EAR is deployed in Websphere in a restlet server project. Is there any way we can get information through code to find out where is EAR/WAR deployed? (Is the EAR is deployed in Websphere or Tomcat or other servers).
Try to instantiate some WebSphere API class. If you get a NoClassDefFound, it's probably not running on WebSphere. You might have to do class.forName(Websphere class), so your code will compile outside websphere.
If you only need to check that for example in Servlet/Filter class you can look for servlet context attributes related to WebSphere, for example com.ibm.websphere.servlet.application.name = Default Web Application. You can find some attributes looi=king at the /snoop servlet if you have that installed.
Or, as Bruce suggested try to load some WebSphere class and be prepared for errors when they are not there.
I am working on a Server Migration Project from Weblogic to Websphere. The problem is that in Weblogic, we are already using a class specified as Startup-class in Weblogic (and arguments to the class like log4j config file) which is present in a jar which is added to Weblogic classpath by editing the startup script. This jar initializes a global log4j file which is for all the apps deployed on the server and not for any particular app. Each app is distinguished by a category of log4j.
Now I could not find a similar thing in Websphere. So what is the best solution? I can create a new application which would do all initializations like that of the startup classes. I thought of using startup-beans but read in some IBM documentation that they are deprecated due to EJB 3.1 Session Beans. Also how to make sure this app loads first? By giving Websphere xml file startup weight 1 like here?
I am using Weblogic 6.3.2 and Websphere 8.5
The WebSphere migration toolkit suggests to replace the WebLogic T3StartupDef and T3ShutdownDef implementations with either a ServletContextListener implementation, session startup bean (Singleton), or a servlet that is configured to load at startup time. If you haven't used the WebLogic to WebSphere migration toolkit, check it out. It provides a lot of help especially with deployment descriptor extensions.
The #Singleton session bean in EJB 3.1 replaces the proprietary WebSphere startup bean.
The best approach depends on the type of module you need the startup logic.
If you are considering the custom services option, note that the com.ibm.websphere.runtime package is not available in Liberty if you are considering the Liberty server.
It sounds like custom services (or a custom feature on Liberty profile) are the best analog if you need to run logic during server startup. Otherwise, if you just need to add a library to every application, then create a shared library and then either associate it with the server or associate it with specific applications or modules.
I'm trying to deploy a spring + angularJS app (packaging as war) into websphere (7.0.0.25), but even for the sample app I cloned from spring, I always get Error 404: SRVE0190E: File not found. And even for the spring app, I have to explicitly specify index.html in the URL, otherwise I get the same error. But the angular side is tolerable, can anyone help me with the spring side?
The sample application is: https://github.com/spring-guides/gs-convert-jar-to-war-maven.git
After doing "mvn clean package" in "/gs-convert-jar-to-war-maven/complete" to get the war, I follow the steps here to upload and deploy the war in websphere:
http://www.packtpub.com/article/deploying-applications-on-websphere-application-server-7.0-part1
I also tried this post to set the custom properties but still didn't work: http://frightanic.com/software-development/solution-to-error-404-srve0190e-on-websphere-6-1/
Also, both my app and the sample spring app don't have a web.xml as spring will take care of it. Both apps work fine in jetty and Tomcat. Only websphere has the problem. Besides, I don't know how to manually configure a web.xml if that will be the solution (need to be pointed to more resources).
The URLs I tried but failed to access the app are:
localhost:9080
localhost:9080/gs-convert-jar-to-war-0_1_0_war
localhost:9080/someAppName
Thanks in advance!
It turns out that websphere 7 doesn't support some spring annotations/classes. My solution is to write a web.xml file and turn off spring auto-configuration.
I have a webapp running JAX-RS web services using the Jersey implementation. The target app server is a WebLogic 12c whose default JAXRS implementation is Jersey v1.9.
1) when run on Jetty (6.1.26) with jersey-server-1.9 dependency, everything is fine.
2) when run on WebLogic 12c with jersey-core.jar + jersey-server.jar (v1.9) jars both embedded in the WEB-INF/lib of my war, it is also working.
2) when run on WebLogic 12c with the same war amputed from these 2 jars (assuming there are not needed as already provided by the weblogic Java EE stack), it does NOT work anymore. I got the following error:
"weblogic.application.ModuleException: [HTTP:101216]Servlet: "jersey-servlet" failed to preload on startup in Web application: "cachede-newgen.war".
com.sun.jersey.api.container.ContainerException: The ResourceConfig instance does not contain any root resource classes.
at com.sun.jersey.server.impl.application.RootResourceUriRules.(RootResourceUriRules.java:99)"
Needless to say the Jersey version is exactly identical in all three cases:
"Apr 24, 2013 4:10:24 PM com.sun.jersey.server.impl.application.WebApplicationImpl _initiate
INFO: Initiating Jersey application, version 'Jersey: 1.9 09/02/2011 11:17 AM'"
It sounds again (sight!) like a classpath or classloader issue :-(
Any idea or workaround to solve this issue (taking accound that I do NOT want to repeat jersey jars in every deployed war) ?
Ok I found the reason :-) - and "better_use_mkstemp" put me on the right direction (many thx!).
The solution consists in adding a reference to the deployed Jersey version in the weblogic descriptor file:
<library-ref>
<library-name>jersey-bundle</library-name>
<specification-version>1.1.1</specification-version>
<implementation-version>1.1.5.1</implementation-version>
</library-ref>
The strange thing is that, without such ref, the error message (ie "The ResourceConfig instance does not contain any root resource classes") gives the feeling that Jersey is able to start and scan your annotated classes...
NB: Actually, you also need a reference to the JSR-311 api, as explained here:
http://theblasfrompas.blogspot.be/2011/03/time-to-deploy-restful-web-service-from.html
Have you "deployed" the jersey jar to your server? In the admin console go to Deployables (click Customize the table and uncheck exclude libraries). See if Jersey is listed there. If not, you will need to "deploy" it and target whatever servers you need it on. Then try to redeploy your war file.
Jersey should live in:
wlserver_10.3/common/deployable-libraries
Those shared libraries aren't automatically available to your server until they are targetted to it.
Just remove all Jersey jars and add one Jersey Bundle jar it will work. I have faced the same Issue and resolved after adding Jersey Bundle jar into to class path.
I'm trying to get Tomcat 7 (comes with OpenEJB) to work with Jersey 1.9. I had my Jersey RestFUL service working with Tomcat 6. But as soon as I deployed the war file to Tomcat 7(OpenEJB) I get the following error.
I created a new dynamic web project in Eclipse and added the following jars to WEB-INF/lib folder without adding any extra code but I still got the same error. It seems like Tomcat 7's OpenEJB is not liking Jersey jars.
asm-3.1.jar
jersey-core-1.9-ea04.jar
jersey-server-1.9-ea04.jar
Caused by: org.apache.openejb.OpenEJBException: Unable to instantiate Application class: com.sun.jersey.api.core.ResourceConfig: null at
org.apache.openejb.config.AnnotationDeployer$ProcessAnnotatedBeans.deploy(AnnotationDeployer.java:1685)
at org.apache.openejb.config.AnnotationDeployer$ProcessAnnotatedBeans.deploy(AnnotationDeployer.java:1482)
at org.apache.openejb.config.AnnotationDeployer.deploy(AnnotationDeployer.java:293)
at org.apache.openejb.config.ConfigurationFactory$Chain.deploy(ConfigurationFactory.java:263)
at org.apache.openejb.config.ConfigurationFactory.configureApplication(ConfigurationFactory.java:693)
at org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal(TomcatWebAppBuilder.java:588)
... 23 more
Caused by: java.lang.InstantiationException
at sun.reflect.InstantiationExceptionConstructorAccessorImpl.newInstance(InstantiationExceptionConstructorAccessorImpl.java:30)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at java.lang.Class.newInstance0(Class.java:355)
at java.lang.Class.newInstance(Class.java:308)
at org.apache.openejb.config.AnnotationDeployer$ProcessAnnotatedBeans.deploy(AnnotationDeployer.java:1682)
Check out Apache TomEE Plus it is Tomcat with JAX-RS already integrated. You can skip the part where you hunt down libraries and try to get them integrated and move on to the writing code part.
Here's a video on how to set it up in Eclipse using the Tomcat web adpater and a simple Dynamic Web Project.
On the note of using EJBs as RESTful services, there are plenty of people that do that especially when JPA is involved. Aside from getting transactions for free, you also don't need a JAX-RS Application subclass or to map any REST servlets. A small perk, but nice.
As well you can expose the same class as a #Remote object and invoke it over RMI, as an JAX-WS #WebService and invoke it over HTTP/SOAP, or just annotate it #LocalBean and you can use the same object internally without the HTTP overhead. Nice to have the flexibility.
This stack trace makes me wonder if ResourceConfig has a no-argument default constructor. You'd see this if the OpenEJB deployment expects on and doesn't find it.
Since REST is an HTTP API for web services, why would you be using it with OpenEJB? I would guess that the two would be mutually exclusive. I'd write services using session EJBs or REST services, but not both.