I have an app that uses apache-commons-collections v3.2.1. When I deploy the war file using the WAS 6.1 Integrated Solutions Console I get errors because the commons-collections.jar file in isclite.ear gets loaded before the one that I bundle with my .war file. The problem is that my application requires v3.0.0+ of commons collections. The one in isclite.ear is version 2.1.
So, can I deploy into WAS 6.1 without involving isclite? Can I just drop a war file into a directory somewhere? Is there an option I can select in the process of deploying through the admin interface to skip or remove the isclite.ear dependency?
Thanks.
I had a very similar problem with ColdFusion where a jar in the server was a different version than the one that was needed by my application. I had to call a non-delegating loader (one that doesn't ask the parent to first load the class before loading the requested jar). The loader I used is open source. You can find out about it at
http://groups.google.com/group/javaloader-dev
Related
My purpose is to run a JSF application on OSGI Framework. So, I am trying to deploy a WAR file to a servlet container for OSGi web applications, called PAX-WEB. I have a proper working JSF implementation working on WildFly 8.0 application server. I succesfully created OSGi-ified WAR file from this application. When I try to deploy it into PAX-WEB using Maven the following error occurs:
missing requirement: javax.servlet.annotation
I have these JARs in /lib folder of my application: jsf-api-2.1.7, jsf-impl-2.1.7, jsp-api-2.1, jstl-1.2. When I add javax.servlet-api-3.0.1.jar to my WAR file and re-deploy it, this time the following error occurs:
javax.faces.webapp.FacesServlet cannot be cast to javax.servlet.Servlet
With this error, I can run my JSF page, but it is not displaying JSF tags.
You're mixing two issues here.
One, your framework setup is missing the servlet classes. So in that case I propose to use the pax-web-jetty-bundle. It's an uber bundle and also contains and exports the servlet classes. In that case make sure you don't have the servlet jars in your framework setup available. Btw. taking a look at the samples and Integration tests of Pax Web itself helps already to understand which libraries are needed.
The second issue you are facing is an issue of adding the servlet classes to the war, this is per OSGi and servlet spec forbidden to do.
So without any further knowledge of your scenario you might be better of with using the Apache Karaf server (it uses Pax Web), cause there all infrastructure bundles are already included and known to work together.
One more thing, you get more and better feedback at the ops4j mailinglist.
Reading the documentation of redhat (https://access.redhat.com/site/documentation/en-US/JBoss_Enterprise_Application_Platform/6/html/Development_Guide/chap-Class_Loading_and_Modules.html) I found that the application server classloader
has a priority list when loading classes that are used to avoid any conflict between
loaded classes, The order is as below
Implicit dependencies.
These are the dependencies that are added automatically by JBoss Enterprise Application Platform 6, such as the JAVA EE APIs. These dependencies have the highest class loader precedence because they contain common functionality and APIs that are supplied by JBoss Enterprise Application Platform 6.
Refer to Section 3.7.1, “Implicit Module Dependencies” for complete details about each implicit dependency.
Explicit dependencies.
These are dependencies that are manually added in the application configuration. This can be done using the application's MANIFEST.MF file or the new optional JBoss deployment descriptor jboss-deployment-structure.xml file.
Refer to Section 3.2, “Add an Explicit Module Dependency to a Deployment” to learn how to add explicit dependencies.
Local resources.
Class files packaged up inside the deployment itself, e.g. from the WEB-INF/classes or WEB-INF/lib directories of a WAR file.
Inter-deployment dependencies.
These are dependencies on other deployments in a EAR deployment. This can include classes in the lib directory of the EAR or classes defined in other EJB jars.
I tried to test this order by using a JSF webapp (rich faces) in my EAR archive
My ear is as below :
sample.ear
--- sport.war
--- mysql.jar
--- lib
Usescase 1 : I added the JSF jars under the webapp (sport.war/WEB-INF/lib): [jsf-api-2.1.14.jar/jsf-impl-2.1.14.jar/portletbridge-api-3.1.2.Final.jar/portletbridge-impl-3.1.2.Final.jar], the jboss server started well and I don't have any exception
Usescase2: I added the JSF jars under sample.ear/lib
==> When I start the jboss server I get an exception (it sounds that the application server loaded the module JSF provided by jboss Implicit dependencies instead of the one in my sample.ear/lib)
I can't understand why in the 1srt usescase the Class Loading Precedence is not respected while in the 2sd usescase the Class Loading Precedence is respected?
Could you please clarify me this point
ENV
JBoss EAP 6.1.0.GA (AS 7.2.0.Final-redhat-8)
JDK 6
Without seeing the exact deployment exception that you got it is difficult to diagnose the issue.
In the first scenario the packaged libraries are loaded in the same class loader as your application.
In the second scenario the packaged libraries are loaded in a separate module and class loader.
The above means that , The deployment issue you were having fo not have to be related to Class Loading Precedence they could also be related to Class Loading Isolation.
Also Jboss and EAP already come with a prepackaged implementation of JSF, and you might be experiencing collisions due to version mismatch
If you were looking to replace the default JSF implementation on JBoss the better option to do so would have been to put the new JSF implementation in a static module, just like the default one , and have Jboss load it on demand.
When I deploy the jar file or Zip file it displays and error message saying there is no installed container capable of handling this application(I use admin console)
Primefaces is a JSF library, not an EAR/WAR/EJB-jar module. It is supposed to be deployed along with the application (i.e. within an EAR/WAR), not separately on the server. Include it in you application and it will available after deployment.
I'm developing a Liferay application, consisting on 2 different portlets, an both have to make certain operations in common, so I decided to put that operations in static methods in an external Utils class.
I have to externalize that class to avoid duplicating the same code in both portlets, and I want to have the portlets in different WAR files.
I know I can package the Utils class in a JAR file, but we are still developing and we don't want to regenerate the JAR and restart the Tomcat for every change.
Which is the best option and how can I perform it?
If you're using the Liferay SDK, you can use the clients (recently changed to shared) directory to put your common code.
A good example is how deploy-listener-shared is used in conjunction with deploy-listener-hook.
From what it looks like, all the configuration you need to do is to modify your build.xml files that will use the client\shared classes. If you look at build file of deploy-listener-hook you can see all you need to add is the.
For the new SDK:
<property name="import.shared" value="my-utils-shared" />
For the older SDK:
<property name="dependent.clients" value="my-utils-client" />
Hope this helps!
There is another method that involves building a JAR file but it doesn't require a server restart (on Tomcat at least).
Write a build script for your JAR file so it compiles, builds the JAR and finally copies it to the following location:
{tomcat}/webapps/ROOT/WEB-INF/lib
Then in your portlet open the "liferay-plugin-package.properties" (in Liferay Developer Studio / Liferay IDE this should open with a nice GUI).
Then add the name of your JAR to the "portal-dependency-jars" list in this file so in the source it would like (Or just hit the "Add" button in the GUI and select the JARs you want):
portal-dependency-jars=my-custom-lib.jar,my-other-custom-lib.jar
Save the file, and redeploy the portlet, and the JAR will be copied across when the portlet is deployed.
I've used this method for custom JARs, and 3rd party JARs that I've needed to use in my portlets.
For the development phase just package the jar file with both applications.
Unless one application depends on the other somehow it is completely ok.
Another solution is to use JRebel tool. It will allow you to redeploy jar in tomcat without restarting.
Also you may have several portlets in one .war. You may just define them both in portlet.xml.
I've got a large code base that currently runs on JSF 1.1 on embedded Jetty 5.1.14 server (Servlet 2.4). I've managed to get a JSF 2.0.9 app running on this version of Jetty even though I'd expected to require servlet 2.5, and I add EL 2.1.2 & the JSF jar to WEB-INF/lib. This works on a jetty config that excludes JSF 1.1.
The production environment consists of a large number of war and jar files on a single server instance.
JSF 1.1 is currently in the server ext/lib folder, and in a single war file I'd like to include the JSF 2 jar in the WEB-INF/lib. This is not possible as the server JSF version will load first and cause classpath pollution.
However would it be possible to eliminate the JSF 1.1 jar loading in just the one war file with a custom classloader? The documentation seems to cater for the case of adding paths to the classpath rather than excluding things. I wasn't clear whether it's loaded in the context of the server as a whole or just the war.
A little more information: Another potential solution is to simply upgrade to Jetty 8 and JSF 2.1+. Apart from convincing management that this is a good idea, we use an old WebMethods7 version, this has a graphical layout tool that produces some XML that is translated by a Component Application Framework, which uses the JSF APIs to generate content (so only a very few JSPs). This would simply be a case of seeing if it works, and if not having a total rethink because of the need to keep supporting this WebMethods "code".
The main goal here is to ultimately run up to date software although not necessarily in one step.
Jetty5 is incredibly old at this point and I would recommend working on the update to jetty8, or waiting a couple of months and making the jump to jetty9 which we are currently releasing milestones for. Changes in the newer jvm's since then alone are enough reason to update your jetty container.
I don't know if this approach was supported in jetty5 or not, but in jetty6 we have ability on the webapp context to modify the classes that are exposed to the context via system and server classes. If those hooks exists then you should be able to tweak that specific context to not expose the classes in the jar in ext/lib.