I have a JSF Mojarra 2.0.3 app that was developed entirely on Tomcat 7 where it works superbly. I need to deploy this application on JBoss or on Glassfish and the application runs but in some parts behaves strangely. On both JBoss 6 and on Glassfish 3 this exact same bizarre behavior occurs.
I believe this happens for a number of reasons:
1) These app servers have their own version of Mojarra JSF bundled within them and these are being used in lieu of the Mojarra 2.0.3 I have in the applications web_inf/lib folder.
2) I am using a third party rich control toolkit that is probably behaving strangely because it expects this specific version of Mojarra (2.0.3 to be exact).
Bottom line is, I am floundering in every attempt to surgically remove JSF from one of these app servers because I strongly suspect this is the reason why these app servers behave differently from Tomcat, which does not have JSF joined at the hip.
Due to client prejudices and inhouse expertise, JBoss is required to host on production so using Tomcat in production is not an option.
Help?
I'm not sure where the libs are in JBoss(simple Google might tell you) but in Glassfish you'll just want to replace the JSF 2.0 jars. They are located in .
install directory\glassfish\modules
Just replace the jsf-api and jsf-impl with the ones you used in the Tomcat version. Then you'll be on the same page.
Related
Establishing a maven cache path for Grails 2.5.6 applications has many side effects and I don't know if this is a known bug that I couldn't find reported or if I'm doing it wrong.
Our Grails applications (mostly in 2.0.4 version) have a grails.war.resources closure in the buildConfig.groovy that prevents certain static resources from reaching the war. However, for Grails 2.5.6 applications this closure didn't work until we created an empty ${HOME}/.grails/settings.groovy
Yes, empty (surprise 1). This situation happened both in Windows 7 using Eclipse Neon, and in a Red Hat Linux using Jenkins to build the applications.
Once we had this settings.groovy file we decided to use it to establish the maven cache path, so that both Grails and Java applications could share the same cache. The file contained one single line:
grails.dependency.cache.dir="D:/DEV-WAS8/CONF/m2/repository"
With this single line, building Grails 2.0.4 applications generated wars full of garbage because the grails.war.resources closure didn't work (surprise 2). This made no sense, but at least Grails 2.5.6 were built correctly. So we tried to establish the cache path only for 2.5.6 applications. The settings.groovy was the following one:
if (System.getProperty("grails.version")=="2.5.6") {
grails.dependency.cache.dir="D:/DEV-WAS8/CONF/m2/repository"
}
In this case grails.war.resources closure didn't work for 2.5.6 ones and 2.0.4 ones built correctly (Surprise 3).
grails.dependency.cache.dir being a System property, we established it at operating system level so that the settings.groovy file remained empty. Wars were generated correctly for both 2.5.6 and 2.0.4 but the maven cache path was not established correctly in Windows 7 using Eclipse Neon. However, it worked perfectly in Linux with Jenkins (Surprise 4).
How we solved it
To resolve the situation now we use an empty settings.groovy file and 2.5.6 applications establish the maven cache path in the buildConfig.groovy
The problem was that the grails.war.resources closure inside the buildConfig.groovy file was incorrectly nested within the grails.project.dependency.resolution closure. This, although incorrect, seemed to work in other Grails versions such as 1.3.7 and 2.0.4. However, the closure is not reachable any more in version 2.5.6 when nested. Once unnested it worked and war resources were filtered as expected
I have a JSF 2.0 web project and I use Glassfish 3.1.2 server. In this project, I have among other things :
a class called AjaxServlet annotated with #javax.servlet.annotation.WebServlet
a class called Session annotated with #javax.ejb.Stateful
When I deploy this project to Glassfish from eclipse, everything runs perfectly : in the administration console of Glassfish, the engines associated with the application are [ejb, jpa, web, weld]. But when I first export the project as a war, then from the admin console I deploy the war, the application doesn't work : the engines associated to the application are then [web] only.
How can I export an application to a war without loosing any information (all the engines)? I didn't declare my Servlet in web.xml because in JSF 2.0, we don't need that: the annotations are enough. Does anyone have an idea about what is going on here? I'm quite sure it is not a problem of Glassfish distributions (Web Profile Vs Full Platform) as the same Glassfish server is used for the 2 scenarios above.
Note for those who erroneously think my question is off-topic : Jsf is a framework for programming Java EE web applications. war is a way to package a Jsf application, in the same as jar is a way to package java classes. So my question is totally a programming topic! It is totally legitimate to have it here in StackOverflow. If exporting JSF application into war is not a programming issue, then compiling java classes into .class should not be a programming topic neither! So Pleaze don't downgrade for this reason!
You have to understand the difference between your eclipse environment and your glassfish environment. Not all your libraries that are available in eclipse might be included in your external environment. There are cases where programs compile in eclipse, but not when run from console.
Here's a tip:
Right click on project -> Navigate to Properties > Java Build Path > Order and Export, and ensure that all libraries you require are going to be exported.
I want to upgrade my web application to the latest JSF Mojarra (2.1.9 as of today is the latest) from Mojarra 2.0.5;
How do i do it ?...what are the steps involved ?..
At the moment my web app lib folder has got the old mojarra jars 'jsf-api.jar' and 'jsf-impl.jar'.
It would be a great help if any one can instruct each step . I am on a Websphere Application server 7.0.0.17
Just replace the two jsf-api.jar and jsf-impl.jar files from Mojarra 2.0.5 by the single javax-faces.jar file from Mojarra 2.1.9.
If Websphere 7 is already configured to use classloader mode "parent last", then you basically don't need to change anything else. But if it isn't (which would basically mean that the webapp-supplied Mojarra 2.0.5 was actually never been used and that Websphere's own JSF libraries is been used instead), then you still need to change the classloader mode to "parent last".
I know that by replacing the el-api.jar in the lib folder of the Tomcat 6 directory with an EL 2.2 capable version that it is possible to utilize the power of EL 2.2 in Tomcat 6. See the following questions:
http://code2inspire.wordpress.com/2010/11/05/how-to-enable-el-2-2-on-tomcat-6/
http://www.javaplex.com/blog/for-jsf-2-how-to-enable-el-2-2-on-tomcat-6/
I have an app that I need to deploy for a public facing site and I want to do it as cheaply as possible. The best bargain for me would be to go with a Shared Tomcat hosting provider where you share a Tomcat instance with others, however the one I talked to doesn't offer Tomcat 7 environments.
It would be a lot more expensive and time consuming for me to setup a VPS to do this, so I was wondering if there is anyway I can swing this on Tomcat 6 without the ability to modify the lib directory?
Use JBoss EL instead. It is EL 2.1 based, but offers the same enhancements as done in EL 2.2. Drop jboss-el.jar in /WEB-INF/lib and add the following to the web.xml:
<context-param>
<param-name>com.sun.faces.expressionFactory</param-name>
<param-value>org.jboss.el.ExpressionFactoryImpl</param-value>
</context-param>
No need to modify Tomcat's /lib. You only need to ensure that you're using Facelets instead of JSP.
I'm working on the project that uses Grails as Web framework and JBoss for deploying web-applications. JBoss allows to configure connection to database and then Grails could use JNDI datasource. However in our project we don't use JNDI datasources, we configure data sources for both development and production in DataSource.groovy. Other JBoss services are not used also.
I understand that if we are using JNDI datasource connections then we may benefit if several grails applications are deployed, because in this case there is no need for each grails application to establish its own connection.
So I wonder is there any sense to use JBoss instead of, say, Tomcat or Jetty, if not using it's services?
JBoss is a J2EE container. Compared to Tomcat which is a Servlet and JSP container only, the JBoss AS has a lot more features. Thus JBoss is also "heavier" than Tomcat, and depending on the size of your project this may not fit well with your development team since it has a longer development cycle (I heard there were a lot of improvements in JBoss 7, haven't tried it yet though.)
If you are not using any of the J2EE container features (JMS, EJB, etc.) then you could be fine going with Tomcat using a grails application. We use Tomcat at work for hosting one of our web applications.
In regards to connection pooling managed by JBoss, Tomcat can also do that. Take a look at this documentation page. Hope this helps.