I'm using WebSphere 9.0.5.3 and after migrating CXF-core lib from 3.1.x to 3.2.x I'm facing this problem :
AbstractJAXRS E No resource classes found
with CXF 3.1.x everything works fine my server is working and my rest services are working as well.
ps1: I have already disabled JAXRSEngine of WebSphere and working with my own libraries ( in the shared isolated package ) and as I said it was working fine with the previous version
ps2: I have already modified the class loader policy ( Multiple -
single )
with some debugging, I figured out that WebSphere is not even loading my classes ( annotated with #path)
ps3: have already upgraded jaxrs-ws-rs to 2.1.1 because CXF 3.2.x
supports JAX-RS latest 2.1 spec even though this spec is backward
compatible with jaxrs 2.0
and i have already upgraded also all the CXF JAXRS related jars and still have
the same problem
PS4: my application is working fine with tomcat 8 and Wildfly/JBoss so
i don't think i have a problem with my resources classes
PS5: in the same jar, the other classes are loaded so WebSphere is filtering the resources classes and not loading them
the main problem here is why websphere is not loading my resouruce classes i have just upgraded the jar and I kept the old configurations ?
The IBM WebSphere Application Server does not provide direct support for JAXRS 2.1. However, what you are attempting may still be possible. Beyond setting the "com.ibm.websphere.jaxrs.server.DisableIBMJAXRS20Engine" property to "true" you should also set the JAXRS provider to "2.0 spec" via the command prompt or administrative console, see the following for details: https://www.ibm.com/support/knowledgecenter/SSEQTP_9.0.5/com.ibm.websphere.base.doc/ae/rwbs_jaxrs_coexist.html
Beyond this, if you need the JAX-RS 2.1 APIs, then you will need to package the APIs with your application. You might also need to use parent-last classloading or package them in an isolated shared library associated with your application. Either approach poses some classloading risk.
Related
it seems jboss AS 7.1 supports ejb 2.1.Our ejb 2.1 based application is deployed on jboss 5 AS. We are migrating it to jboss7.1. but i want to know what are the additional configurations required to run ejb 2.1 without any errors?
EJB2 is still supported in AS7.x, the issue might be that AS7 is a new implementation and some of the tuning options and configuations are not available for AS7 - especially the EntityBean CMP.
There are some added for EAP6 (based on AS7) you might download the unsupported version.
Wildfly (the successor of JBossAS) will not continue to support EJB2 EntityBeans because EJB3.2 declare it as optional.
Note EJB2 session beans are still supported but I recommend to upgrade it to EJB3 this should faily simple.
You might keep the EJB2 interfaces to provide an interface for EJB2 clients, but I expect effort for the client as well as the lookup Strings changed.
If the appliation should be kept for the future I would recommend to migrate to EJB3
I'm trying to create a page that validates url parameters and redirects to error page when parameters are not present.
Developing on TomEE 1.7.3 and Eclipse. Project set to Development mode. I'm targeting JSF 2.2.
I've used these questions:
Redirect before loading the page in JSF2
NLS missing message: CANNOT_FIND_FACELET_TAGLIB
My code works, however I'm getting warnings on Eclipse and on Server:
How can I rid of these warnings? Will these show in Production environment too?
First of all, TomEE 1.7.x ships with JSF 2.1, not 2.2. The migrated xmlns.jcp.org namespace domain is only available since JSF 2.2. Unless you've manually upgraded TomEE itself to use JSF 2.2, this won't work at all and you should keep using java.sun.com XML namespace domain.
How can I rid of these warnings?
Have a concrete JSF 2.2 implementation JAR file in project's Build Path. In case of Java EE servers, this is usually to be done by setting the server as Targeted Runtime in project's properties. The server plugin will then auto-reference server's own libraries in Build Path. Obviously, this will only work properly if the server plugin is decent and you have correctly upgraded the server itself to physically use JSF 2.2.
If this still doesn't work (because of poor server plugin), then download the individual JSF implementation JAR file, put it somewhere in project (but NOT in /WEB-INF/lib, otherwise it will conflict with server's own JSF impl during runtime and cause class/method/abstract related exceptions over all place), and add it to project's Build Path.
Will these show in Production environment too?
I can't imagine how as production servers usually don't run server via an IDE and HTTP clients usually aren't able to monitor the server's VGA output.
To create REST web services, I usually just use com.sun.jersey; but now, I keep seeing org.glassfish.jersey.core as well. So, I was wondering what is org.glassfish.jersey.core? Is this another implementation of JAX-RS?
The com.sun.jersey packages are Jersey 1.x (which is included in Glassfish 3.x).
The org.glassfish.jersey.core packages are Jersey 2.x (which is included in Glassfish 4.x).
You shouldn't mix both versions in a web application.
We are encountering issues while deploying the new core SDM modules (wars) in weblogic 12c version. The new SDM core module (wb-tss-core-sdm-web-war-0.9.1.war) uses the JSF ,SeamListeners & FacesServlet (version 1.2 jars) and we have found that the JSF 1.2 version is not directly compatible with the weblogic 12c version. Hence, the application deployment is failed with user defined listener conflict issue
As per Weblogic 12c documentation,
"WebLogic Server 12.1.1 has enhanced support for JSF and JSTL. In this
release, JSF 2.x and JSTL 1.2 have been incorporated directly in the
server's classpath. Your applications deployed to WebLogic Server can
seamlessly make use of JSF 2.x and JSTL 1.2 without requiring you to
deploy and reference separate shared libraries, as was the case in
previous releases. For backward compatibility, WebLogic Server
provides JSF and JSTL libraries that can be deployed and referenced by
applications. See Deploying JSF 1.2 and JSTL Libraries. "
We had tried to install the JSF 1.2 wars explicitly in the weblogic server path as per the documentation to support the backward compatibility and forced the SDM application/war to use the JSF 1.2 version jars by adding the below entries in the weblogic.xml .
<wls:library-ref>
<wls:library-name>jsf</wls:library-name>
<wls:specification-version>1.2</wls:specification-version>
<wls:implementation-version>1.2</wls:implementation-version>
<wls:exact-match>false</wls:exact-match>
</wls:library-ref>
But the deployment is failed again with FacesServlet listener issue as the "jsf-impl-1.2_04_P02.jar" jar is already part of (wb-tss-core-sdm-web-war-0.9.1.war) war .
Tried to add the following entries in the weblogic,xml to force the application to use the application specific jars/classes which are part of the application war file.
<wls:prefer-application-packages>
<wls:package-name>javax.faces.*</wls:package-name>
<wls:package-name>com.sun.faces.*</wls:package-name>
<wls:package-name>com.bea.faces.*</wls:package-name>
<wls:package-name>com.sun.facelets.*</wls:package-name>
</wls:prefer-application-packages>
After adding the above entries, the application deployment is completed successfully but have noticed the following errors in the console:
<BEA-101162> <User defined listener com.sun.faces.config.ConfigureListener failed: javax.faces.FacesException: org.jboss.seam.jsf.SeamApplicationFactory.
javax.faces.FacesException: org.jboss.seam.jsf.SeamApplicationFactory
Due to this above error, some of the Jasper file upload SDM screens are not accessible and it is getting failed with this error:
java.lang.IllegalStateException: Application was not properly initialized at startup, could not find Factory: javax.faces.render.RenderKitFactory. Attempting to find backup.
How do we get past this?
We had the same issue during migration of JBoss Seam application from Weblogic 10.3.3 to Weblogic 12.1.1.
It was resolved by switching to Weblogic's default JSF 2.1.14 and updating Seam version to 2.3.
Hope this helps.
Not sure if you saw the longer discussion on this question:
Migrating JSF-Application to Weblogic 12
This helped me when analysing a similar library migration issues (hibernate was on my list).
When I develop an Axis2 web service on Eclipse, I noticed that Eclipse is automatically copying the classes from the lib folder of Axis2 to the lib folder of the new project. However, not all classes from the lib folder of Axis2 are being copied. Interestingly, the web service runs without any problem when deployed to Tomcat via Eclipse even if some the jars from Axis2 were not copied. Also, when I viewed the temp file of Tomcat, Tomcat seems to generate the jars for the listed modules on modules.list of the web service.
Can someone enlighten me regarding what is happening on this? Why Eclipse doesn't copy all the jars from Axis2? Why can the web service run on Tomcat even without the other jars from Axis2? What are those temp files for? When and why is it being generated?
I tried to run the same project on WebSphere and I am encountering a ClassDefNotFound exception because of the missing jars. My problem was solved when I copied all the Axis2 jars that was not copied by Eclipse to my project. But I'm not comfortable with my solution because Tomcat can run my project even without those jars. Is my solution really the right solution? Or am I missing a configuration setting?
This is just for clarification:
My web service is already running in Axis2. My class loading policy is set to PARENT_LAST. I know that since WebSphere has its own Axis2 configuration, the class loading policy must be set to PARENT_LAST so that WebSphere will use the Axis2 from the project itself. Aside from setting the class loading policy, I did something to make my web service run on WebSphere. I describe what I did above. My question is why such method must be taken?
WebSphere has it's own axis2 configuration as part of its Java EE server spec for JAX-WS. Change your class loading policy to PARENT_LAST and check if that solves your problem.
Edit:
As the original post already states: WebSphere is a Java EE server depending on version it supports its the standard Java JAX-WS web services. Actually web services became part of the standard jdk.
If you use JAX-WS like mentioned in Introduction to JAX-WS or building web services then you don't have to add any 3rd party library for getting your web services running. As soon as you use the non JDK implementation like axis2 you have to package it with your application.
IBM didn't just pack the axis2 into their WAS/JDK, they modified it. I'm not sure what Tomcat delivers, however as long as you use JAX-WS it shouldn't matter. With JAX-WS you don't have any direct import of the org.apache.axis packages. If you use these imports you have to supply the libraries and make sure that yours are loaded.