Ship JSF with web application ?

[Jan Goyvaerts]

It has been brought to my attention it is possible to deploy a war file including a complete JSF implementation. On a server actually not containing any JSF libraries. I always thought it was mandatory to deploy your JSF application on a JSF-compliant application server.

Checking the questions on SO, it looks like people are actually doing this on Tomcat and Jetty. 

I was wondering whether this is standard practice. And whether it is reliable.

Does anybody in here have practical experience with this ?

Thanks,

Jan

[Matthew Farwell]

Yes, I've done this, using JSF/Richfaces, deployed to Tomcat. Tomcat is the standard for this particular client, and this application was one of a number of JSF applications deployed on Tomcat.  This was an internal intranet application, which wasn't exposed to the internet.

Apart from not liking the technology and having lots of problems to do with the jsf lifecycle and its interaction with Richfaces, it's been reliable enough in production.

Matthew Farwell.

[Brian Smith]

Yes, shipping an application with JSF included generally works fine.  We have a number of deployments on different Tomcat versions, and test a lot on Jetty too.

It does get problematic when you're trying to ship the same war to clients using different containers, where some are full EE and some only servlet spec.  You will find you can't easily configure some of the full EE containers to do child first or isolated classloading so you get version incompatibilities when they also provide JSF.

I'd echo Matthew's comments on JSF and Richfaces in general, we consider it legacy and won't be using it for anything new.

regards

Brian

--
You received this message because you are subscribed to the Google Groups "Java Posse" group.

To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/SxJ_tXTJlZ0J.

To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Jan Goyvaerts]

You guys are talking about JSF 1 ? 

I thought only JSF 1 was terrible. But JSF 2 isn't. But then again, I never used JSF.

[Jan Goyvaerts]

just for the record - I've been charged to investigate the feasibility to ship JSF2 this way on a non-JSF compliant server. :-)

[Casper Bang]

A JAR in a classpath is a JAR in a classpath, no? I always assumed that when people pre-loaded runtime libraries it was out of a desire to minimize artifact size and/or optimize reusability within the JVM (thus by inference, minimize risk of the PermGenblowing up).

In my view, a project *should* be as self contained as possible, except for a precious few optimization aspects like pooling of connections, sharing of cache etc.

Few things are as daunting as trying to get a project to run, which is dependent on libraries and settings only the original developer knows about - and has likely forgotten.

[Joseph Ottinger]

You guys do realize you're ignoring the Java EE definition, where a deployer's role is to actually tailor the deployment for a specific container, right?

--
You received this message because you are subscribed to the Google Groups "Java Posse" group.

To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/6MhOVhqXmUMJ.

To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

--
Joseph B. Ottinger
http://enigmastation.com

Memento mori.

[Marco Faustinelli]

>On Friday, November 30, 2012 1:23:51 PM UTC+1, Joseph Ottinger wrote:
>You guys do realize you're ignoring the Java EE definition, where a deployer's role is to actually tailor the deployment for a specific container, right?

I believe this is a sign of the times. We started from a situation where the choice of the container was prioritary, strategic and made to last for years. Porting a complex app to another container may still be a nightmare today, and a key reason to stick to the legacy.

Now I hear good people say that a Tomcat instance with more than one app is an antipattern. AFAIK Grails ships an embedded Tomcat with every webapp unless told otherwise.

I understand single-app-Tomcat is not exactly what this thread is about, but still I see analogies with the current-thread-relevant move to virtual servers on demand, clouds and stuff; because it all makes the container a lesser priority.

The business case for moving heavy apps is growing and I think that therefore the case of self-sufficient apps is getting more important.

[Roland Tepp]

This is the ever lasting battle of modularity vs self containment.

I remember when I decided to try out OS X for the first time for real, I was amazed and awed how simple the installation process of an application was - you just dropped an application onto your computer and it was "installed".

Contrasting this with Windows and/or Linux way of installing applications, the whole process seemed downright ... simple. Until I stopped to think what it meant that is. Most of the apps in OS X are self contained bundles (folders) of all the dependencies of that app. After being horrified for a moment at the horrible waste of space, I was awed again.

Modularity is a great thing. In your application. And sometimes in service/OS level as well. But nothing beats the deployment of an app that can simply be "dropped in" to the container.

So yeah - I see nothing special in deploying your app with all the dependencies bundled alongside.
I'd even go one step further and bundle in the container (depending on the audience of the application of course). There are certainly examples of this type as well (think Jenkins from the top of my head)

[Jan Goyvaerts]

We're in the product business. One of the problems is that we're trying to make an application that fits as many servers as possible. 

So we can't ship an application server with it. Only a war file. WE have to fit into the customer's "ecosystem" without imposing them a server, database, etc...

My question is just whether it requires hacking to have JSF included IN the war file and still run reliably.

--
You received this message because you are subscribed to the Google Groups "Java Posse" group.

To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/NFwXklXEIuEJ.

[Joseph Ottinger]

It depends on the container. But again, the Java EE spec says that the *deployer* is responsible for connecting JNDI references to databases, including or excluding dependencies, etc.

[Jan Goyvaerts]

I'm afraid many customers are not aware of the JEE roles... :-)