We Keep Coding

Deploy WAR or "fat" JAR?

I'm noticing a lot of projects (DropWizard, Grails, etc.) starting to embrace the notion of a "fat" JAR (using an embedded web server like Jetty or Tomcat) vs. the traditional WAR deploy. Both methods involve a single JVM process (i.e. no matter how many WARs are deployed to Tomcat, it's all the same JVM process).
Under what circumstances is either deployment method preferable over the other?

Here are some reasons:
In favor of JAR:
Simple to build and deploy.
Embedded servers like Jetty are easy to operate.
Applications are easy for users to start and they can run on their personal computers too, because they are lightweight.
Starting and stopping applications will require less knowledge than managing web servers.
In favor of WAR or EAR:
The server would provide features like deployment, restart, security and so on for multiple web applications simultaneously.
Perhaps a separate deployment team can handle the starting and stopping of apps.
If your supervisors like to follow rules, they will be happy to find that you are not breaking them.
Having said this, you can always provide 2 or 3 types of executables to cater to all needs. Any build tool makes this easy.

Distributing an application with an embedded webserver allows for standalone setup and running it by just calling java -jar application.jar.
However, there may be users who want to be in control of which web server is used or who want to deploy multiple applications into a single webserver (e.g. in order to prevent port clashes especially with ports 80 and 8080). In that case a "fat" jar might cause problems or at least some unneeded code and thus a larger memory footprint.
IMHO the best approach for those two cases would be to provide two artifacts: a "fat" jar for (easier) standalone setup and an application-only war/ear for those who want to deploy the application in their own container.

I am thinking about user perspective. You could wrap this one-self containing jar within a .exe or .dmg and just install it without the need to have additional instructions on how to deploy. Also, since you are doing the deploy for a particular server only, you could take advantage of that particular server

Questions about Spring DM,OSGi and web application

I've started looking at osgi with the main purpose to achieve the task ahead of me. Basically i would be able to distribute an web based application and build specific features of the whole web app separately in such a way that i can deploy at A my web app with features a,b,c and deploy at B with features a,c,d.
A little like how one can install plugin in joomla. So for example when i want to add a different aspect of the web application, i would build a small war with all the html and its admin section and have this feature admin section available in the main admin panel.
Second question is about Spring DM. most likely i will be using Spring and it seem logical i see what Spring DM has to offer.After downloading Spring DM .1.2.1 i found out that its lib folder contains spring jars for version 2.5.6.SEC01 but i planned on using 3.1.2 so am a little confuse as how everything will play nice together.
Thanks for reading

I've just been doing such an exercise so I can shed some light how you do it without the overhead of Spring. I've made a clear division: all application code is in the browser, all data handling is in the server. With HTML5 the browser has grown up to an impressive, portable, and powerful application environment. One has multiprocessing, messaging, modularity, and amazing visuals. I am using angularjs as the framework in the browser.
Angular works with a central routing table mapping the hash part of the page url to "modules" in Javascript. This makes it very easy to define what modules are part of the application. The server can easily control this part.
On the server side I have bundles that carry the Javascript code, the html fragments and the data handling. I based this on the OSGi Http Server model since it is more flexible. However, I added proper support for static resources in bundles: caching, streaming, ranges, etc.
In the server I used DS and bndtools to develop the bundles. This is an impressive development experience since it works like Smalltalk. You change and it is immediately reflected in the server. Adding bundles, removing bundles, the server keeps on running. Server restarts are rare during development.
The disadvantage is that there are unfortunately very few components that leverage OSGi. Most components, with Spring being the archetypical example, rely heavily on class loading hacks to wire applications from a central point. This is fundamentally not modular. For this reason I had to develop many highly cohesive and uncoupled components that leverage the OSGi service model. Once I get time I will donate them to an open source project.

I'm not sure you need to be considering OSGi, at least not directly, to achieve your state requirements. You said:
Basically i would be able to distribute an web based application and
build specific features of the whole web app separately in such a way
that i can deploy at A my web app with features a,b,c and deploy at B
with features a,c,d.
If these are youre requirements, then you don't actually need to concern yourself with OSGi directly, but rather find a web app framework that supports modular extensions. Which most likely means that the framework itself uses OSGi. I'm not familiar with Spring, but I do know that Struts 2 ( a comparable web app framework ) has an OSGi based plugin meant to achieve your use case.
On the other hand, if your idea is to play with OSGi, then I suggest you pick a lower level task, such as writing a web application framework, rather than a web app itself.

How to start a Java EE 6 project in Eclipse

I have recently begun learning Java EE 6 after doing Java SE for some years now (together with other languages). I have bought different books about Maven, EJB, JSF, Glassfish and so on (not read them all yet though), and I feel absolutely overwhelmed of the complexity of just making a project.
How would I start a project from "scratch" (Not copying a from an example in the book) in eclipse? I can choose from Dynamic Web project, Maven project, EJB project, EAR application etc. Which should I use if I want to make an application that has EJB/JPA and JSF inside (web application)?
I know about the Standard Maven Directory Layout and archetypes, however I do not know which to choose if this is the way to do it. Of course, I understand that there are many ways of doing it and it is dependent on what I will use it for, but I am learning Java EE 6 so I want to at least have some knowledge of how to set up a basic project as well.
I am also rather overwhelmed by the POM file. How do I know which dependencies I need just to get started with a web application? Or is this included in the correct archetype (if I find one?)
I am using Glassfish as application server, Eclipse, EJB, JPA and JSF. Currently learning from book examples only.

Well, a complete answer to your question would pretty much need an entire book on it's own, but here's some pointers.
The notion of Java EE applications represents any kind of Java application that uses one or more of the Java EE APIs implementation and needs a Java EE application server to run. Java APIs are those such: Servlet,JSP, EJB, JPA, etc. Implementations of these APIs are usually provided by the application Server (like Tomcat has servlet and JSP implementations, Glassfish has those as well plus EJB, etc). There are, let's say non-application server Java EE APIs implementations like Hibernate's implementation of JPA. So in short if you use some of these APIs implementations in your app and deploy it into some application server like Tomcat, Glassfish, JBoss AS, etc, you have a Java EE application.
I've told you all this because in reality, most of the project management tools (like Eclipse, Maven, etc) use these subdivisions like Web-Application, EJB Module, Dynamic Web Project etc, as a custom denomination that establishes the ball park of what set of Java EE APIs your application will use. I.E. a Web Application or Dynamic Web Project will more likely use Servlet and JSP APIs, an EJB Module will (duh) use the EJB APIs and so on. These are, as I said, ball park denominations. A Dynamic Web Application can use EJB or JPA as well, it's not like it's written in stone.
When you use either of these tools such as Eclipse or Maven, to start one of these above mentioned, denominated projects, such as a Dynamic Web Project in Elcipse or a Standard Web Application with Maven, that respective tool will add the common sense dependencies to your template project (like Servlet and JSP in this case), and then let you handle it from here.
The idea here is to understand each type of template of your chosen tool before you use it at the start of your project. Like if you decide to use Eclipse and start with a Dynamic Web Project, you should check out what exactly Eclipse asks of you and does when you do that (it will ask you for the location of a locally installed Java EE application server from where it will pull in such dependencies as a Servlet Implemnentation and a JSP implementation amongs others). Or if you chose Maven, and start a standard web project, you should check out what dependencies it adds to your project via the pom.xml file, what the basic functions of THAT pom.xml file are, etc. You should also check out how each of these tools deploys your application when you tell it to do that, does it use some hot deploy feature of your Java EE server, does it need credentials to access that server first etc.
My brief advice is to start with the very basic example: Install a Tomcat (version 7 is recommended), start Eclipse for Java EE Development, add that Tomcat installation to your Eclipse config, start a Dynamic Web project that uses that Tomcat as Application server, and just do some basic servlets and JSP pages, then use Eclipse to deploy that sucker to tomcat and run it. Then you can branch off to more advanced stuff, like doing the same thing with Maven, integrating a Maven project with Eclipse, adding some more Java EE Stuff (like a JPA Implenentation), etc etc.

http://blogs.oracle.com/arungupta/entry/web_app_development_using_java provides a complete explanation of how to create a Java EE 6 project using Eclipse and GlassFish.
Alternatively, you can also NetBeans to create a Java EE 6 project as explained at:
http://blogs.oracle.com/arungupta/entry/screencast_37_java_ee_6

I can choose from Dynamic Web project, Maven project, EJB project,
EAR application etc. Which should I use if I want to make an
application that has EJB/JPA and JSF inside (web application)?
Before EJB 3.1 spec it was not possible to deploy EJBs in war files, but now, you can. So for a quick prototype you can use a war file rather than an ear file if that's all you require and you are more familiar with it. Of course you can also deploy it in an .ear file.
I believe the Dynamic Web project in Eclipse generates a .war file that you can deploy in your AS.
If you are using Maven, you can also create your project with Maven beforehand, and then import using Maven (via M2Eclipse plugin). This works pretty well for me. Then, with the Glassfish Maven plugin, you can deploy your app to Glassfish via command line.
I am also rather overwhelmed by the POM file. How do I know which
dependencies I need just to get started with a web application? Or is
this included in the correct archetype (if I find one?)
You need the Java EE dependencies at least in a "provided" scope as the server will probably provide these for you. This way they will be available for you in compilation mode. For instance, the one for the JBoss Java EE 5 stack is as follows (not sure about the GlassFissh dependency, but the important stuff is not to include the library in your .ear / .war in order to avoid library conflicts):
<dependency>
<groupId>org.apache.openejb</groupId>
<artifactId>javaee-api</artifactId>
<version>5.0-1</version>
<scope>provided</scope>
</dependency>
Added: As you said, this can be overwhelming at the start, I think this is a good resource on how to setup a Glassfish / Java EE project. Pick the bits you are interested on and good luck.

The first thing I'd ask you is why you're learning so many technologies. If your purpose is getting a job, in my experience, there's a trend in companies away from Java EE and towards simpler solutions. For example, application servers are overkill for most organizations and Tomcat (or another web server) with helper technologies like Spring and standalone JMS servers replacing full-featured and much more complex Java EE servers.
I think you'd be better served focusing on core concepts and simpler technologies as you get started and staying away from IDEs, complex builds, EARs, etc. Instead, start with one or two technologies (e.g. a hello Tomcat app with a simple Ant build) and gradually add each technology in as you find the need. Better yet if you have a real world problem to solve, even if it doesn't pay.
Most companies (at least those with a technical clue) would rather hire a programmer who understands what value a technology like JSF adds and at what cost of complexity than someone with a lot of acronyms on their resume.

How to start a new web app project in Eclipse with Maven?
Just type "archetype:generate" and select JSF + EJB/JPA if available.
This one seems fine: 360: remote ->
org.jboss.weld.archetypes:weld-jsf-jee (Weld archetype for creating a
Java EE 6 application using JSF 2.0, CDI 1.0, EJB 3.1 and JPA 2.0
(persistence unit included))
The Appfuse are quite more complete and may embed stuff you will never
use and that you will have to remove.
After that mvn eclipse:eclipse to be able to load the project in eclipse.

Implications of building a java program against the jars of one web container and deploying it in another

What are the implications of building a java program against the jars of one web container (say Jetty) and running it in another (say Tomcat)?
I have an application which I run in Jetty durring development but which is deployed into a tomcat server for production (Why? because it seems easier to develop without having to run a whole tomcat server.)

You should compile against only the official Java EE API's for the level you target, for any non-developer builds. Preferably by a build engine. Preferably on a different operating system than you develop on.
For a web application this mean the appropriate servlet API as downloaded from Oracle. Similar for an enterprise application.
In my experience this is the best way to keep it straight.
Edit: Java EE SDK is available from http://www.oracle.com/technetwork/java/javaee/downloads/index.html. If you need an older version than Java EE 6, then follow the "Previous Releases" link.

You can get issues such as MethodNotFoundError. You can usually resolve these by making sure versions of jars installed on the servers match.

you typically want to develop where you deploy. It might be slightly harder to develop with tomcat vs jetty, but you have identified a potential mess of a problem with jar conflicts, so doesn't it seem worth it to develop with tomcat, since you deploy to tomcat?
Also, typically the pain of developing against tomcat/your container of choice is mitigated by putting in the time to write a ant (or other) task that will deploy your code to your development container. The work cycle bemoes
1) Write new code
2) make sure tests pass
3) run your 'redeploy' script
4) poke around in the running instance
You probably want to do that.
Finally, in the spirit of loose coupling, you probably do not want to depend on a container-specific libraries if you can avoid it; only do that as an absolute last resort.

How to develop a modular enterprise application using just GWT

Hi
I want to design and develop a big enterprise application using just
GWT in client side.
I want to break this enterprise application into parts and I call each
of them a module (or bundle or portlet or whatever!).
These modules might have relation with each other and might call some services that
exists in other modules (in both client and server side).
The problem is, These modules must be Designed , Developed, Compiled
and Deployed Independently and Dynamically and they will be placed and
shown together in one context on the client and the dependencies
between modules should be manageable (in both client and server side).
What can I do? What kind of technologies I can use to build an enterprise application like this?
When you develop an application that is not divided into parts (In the way that i mentioned) you can easily deploy your application after building your project, but when you change just one form in your application you have to build the entire application again, and deploy the entire application.
In this application I cannot stop the server to deploy the application again, I want to change and deploy that part of application that is needed to be changed not the entire application!!!
Of course I have searched about the way that I can solve my problem!!!
I have found that I can use OSGI on server side because it provides modularity at software construction level and helps me to manage life cycle of modules and many other benefits that you know!
And I have found that I can use Gadgets on client side.
What do you think? Are they good choices?
If they are good choices, how can I start? I know that we have different kinds of implementations of OSGi, like Apache Felix, Eclipse Equinox and Knopflerfish. Which one is good for this choice?
How GWT and OSGi can be integrated? How can they interact with each other?

Unfortunately what you want to do is not fully possible with GWT.
OSGi is a modularity solution for Java, or more accurately the JVM. A GWT client application does not run on the JVM, it runs on the browser in a JavaScript environment. Therefore OSGi cannot be used to create runtime-assembled modular GWT applications.
A GWT application can be modular at the source level, but the modules must be assembled into an application at build time. The resulting runtime is monolithic.
However, it's perfectly possible to use OSGi to host the GWT servlets, and you can use the full power of OSGi runtime modularity on the server side.
As an alternative you may want to look at Vaadin. This is a web framework that uses GWT to provide widgets, but the logic of the application runs on the server. As a result, it does support full runtime modularity through OSGi bundles. There is a cost with this approach though: your web application is quite chatty, with lots more communication going between the browser and the server than in GWT or in a traditional web application. It's possible that this approach will not scale to very large numbers of users.
As for whether to use Equinox, Felix or Knopflerfish... it really doesn't matter. Stick to the specification, and you can easily switch between implementations.

I did just this two years ago: OSGi and GWT for no downtime deployments of project modules.
Verdict: Don't do it unless you really must.
In short, OSGi is a beast and retrofitting an existing application for it is far from trivial. You're no longer making .war files (.ear now) and can't use the standard jars and Maven repositories you used before. Now everything needs to be a bundle. Trouble is, a lot of stuff (GWT, Spring, tons of libs) are not bundles! And you'll need to find them in an enterprise bundle repository or, even more fun, start rebundling 3rd party sources them yourself. Better yet, telling the other devs to rewrite everything that uses their favorite lib because bundling it would be too complex.
The GWT part didn't take that much work. The way contexts for modules were handled in gwt-servlet had to be modified so each module could find it's context on the server. We also had to make a way for most of the GWT services to register/unregister on load and a discovery service so they could know who else was out there.
Now the other pain: project explosion.
Let's say you had 20 modules you wanted to deploy independently. Well, to start with they're probably more coupled than you'd like, so better spent a few weeks breaking them into independent Maven projects and pushing common parts to a lib project. But now, you've got tons of dependencies to keep track of. When someone tweaks your lib project, do you need up upgrade every project or just 7 of them? In the classic stop the world deployment, you only had one version of all your code. Now, you need to decide if that forgot password form being upgrades will require you to also upgrade your index page module. You'll have a ton of version numbers to make up and keep track of. In our case, we quickly had 55 Maven projects building all the time in our CI server. This meant some checkins could trigger 55 builds. Eek.
Finally, JSON interfaces.
We used GWT RPC. It's magical. Write an interface and everything just works. It's also serialized and gzipped over the wire too. Awesome. But, the serialization policies depend on object and string lookup tables that are built at compile time per module. So, project A cannot RPC to project B. Boo. We chose to use JSON due to the graceful degradation, that is not failing when new unrecognized properties were present on objects. This means you'll again need a way to keep all the backend service calls coherent in the versions of the JSON they are expecting and can handle. Better simulate that live upgrade beforehand too.
So, final word: possible, but why? Do you really need OSGi to hot deploy modules because you're running a 1000% uptime business critical application? Or does your boss/architect just refuse to accept that 99.999% is good enough? You probably don't need that uptime and can achieve nearly 100% uptime with a good proxy to let you take instances in/out of the balancer pool. Also, don't forget that even if you can upgrade your projects live on the fly, I hope you've got a way to upgrade your database on the fly without dropping a single transaction.

I think you are setting yourself for more headaches than it is worth.
I would go with deploying the whole thing at a pop. If not you will end up with mismatched pieces of the application that are out of sync with each other. GWT has both Client and Server components and they need to be deployed together. If you have a zero downtime policy then you probably have load balancing in place.
I would use the load balancing software to deploy the new version of the app. Turn off one side (by diverting all traffic to the other side) deploy to it, do a quick smoke test, switch all traffic to the new side and repeat with the old side.