Pros/Cons of war vs. ear deployments (Jboss 4.2)

[stu2]

I'd like to switch to a war deployment to take advantage of Seam's dynamic classloader enhancements.

Using Jboss, are there any capabilities that will be lost? I'd like access to the full EJB 3 stack, will be using messaging, etc. Or is it really just a matter of packaging?

Thanks,

Stu

[christian.bauer]

Well, the EJB3 deployer will not scan your WAR for EJBs. So you can't have EJBs in there.

[stu2]

Ahh, so that hasn't changed. I wondered if the embeddable microcontainer stuff might make that a viable option.

Has anyone explored using the dynamic classloader for ear deployments? The docs say it's war-only. I understand any EJBs wouldn't be reloadable, but it would be fantastic to get this for everything else.

[christian.bauer]

I think all of this won't happen before JBoss5.

I checked out CVS of the Embedded JBoss5 last week and it's working nicely with hot-redeploy of virtual archives. Means I don't even have a WAR anymore, just a bunch of classes with annotations and a few config files, all in one directory. And then I programmatically feed that into a virtual EAR/JAR, which I deploy on JBoss5.

IMO this is the approach we should take. WAR and EAR are _deployment_ solutions, I'm not deploying anything when I'm developing software. I just want to see my stuff running in one way or another and I have no idea why everyone (including the IDE vendors) thinks that WARs and EARs are a good idea for that. They are not, in fact, they are so badly designed that everyone writes 5 pages of build.xml just to get the dozens of files into the right locations. Why can't I develop how I like and only use the EAR/WAR stuff when I want to actually _deploy_ my application and run it?

So this whole issue should be solved in the second half of this year... I can see other projects (Tapestry for example) also pushing in new directions and only good can come from it.

[christian.bauer]

By the way, the Seam hot deploy stuff is not that useful as it is right now. Because the hot-deployed components are in a different classloader, you can't reference them from classes that are not Seam components and in a different classloader. One example would be a servlet that calls a Seam component. I also found issues with restoring if PAGE context state. In the end I found the restrictions too severe and went back to manual redeployment when I change a class. It's not that bad, at least we can change and preview XHTML/CSS immediately.

[stu2]

Thanks for the info Christian. You saved me from jumping in to find this out myself. Agreed - the xhtml reloading is the most important, as everything else can be unit tested.

I am intrigued by the JBoss 5 capabilities though. I'll wait until it gets fully baked.

[maxandersen]

I fully agree on the fact that virtual archives is what is needed. JBoss 5 is building it into the core of AS but until we have that in JBoss Tools/RHDS we are working on having it at the IDE level.

Giving you an incremental update of the deployed artifacts removing the need for seperate assemble/copy step during development.

With respect to why WAR and EAR's still are interesting for IDE's then its because it gives a standard structure where you (and the tool) can agree on where is the class files, where are the web.xml, components.xml etc.

Virtual archives doesn't really solve that problem.
Your development files sometimes does not even contain enough information to tell the IDE what your "view of the world" is. The java source code is normally static; but config files with ${deploy.url}, ${deploy.dir} instead of the actual values makes it extremely hard for IDE's to deduce enough information to be really usefull.

I have some ideas for solving that; but there are many common corner cases to solve.

[tzman]

With applications having 500k+ lines of code, it is very important to us to shrink the amount of time it takes to code/test/redeploy. We have had success in the past with deploying the ejb's in an ear file and hot deploying the web components in an exploded war outside of the ear; the ejb components are tested outside of the container. Just starting to look at seam, but it appears as though this may be troublesome to say the least.

It seems as though most IDE solutions are fine with small applications where packaging and deployment times are negligible, but not very useful for large applications. Exadel?s solution fits into this category.

Just my 2 cents.

[maxandersen]

What do you mean "exadels solution fits into this category" ? Are you thinking about the default WTP deployment or ?

[tzman]

I pointed out Exadel only because I was just trying it out. The server publish action calls into a generated ant script that bundles and moves the file to the deploy directory. I believe this is actually a part of jst or wst?


Really the point of the comment is that having the ability to do hot deployments of code and only the code that has really been modified is/would be a huge productivity boost for us. This is more important on the ui/web side then the back end services.

I did not mean to point a finger at any specific tool, only making a generic comment about what our shop needs.

[maxandersen]

I just needed to find out what feature you were talking about ;)

and yes, this is something we have as a target - better hotdeployement.