RE: Re: Re: EAR/WAR Deployment

> From: Buck
>
> > Not only that, there will be different deployment
> > models for different application servers, and that's
> >a sure harbinger of pain and suffering for application
> >developers and end users.
>
> Probably true, just like every other platform.  Of course, vendors could
> work with the J2EE people and enhance the standard...

Because I don't have to do it with Tomcat, and Tomcat is free.  The big
picture here, the issue is that I can avoid the whole J2EE muck-up by using
Tomcat.  And now there's NO WebSphere market, 3rd party or otherwise.

Deployment should NOT be a extra cost option.


> I'm not qualified to be able to tell one way or another, but isn't there
> always a better way to build a mousetrap?

What are you saying?  Buck, J2EE is poorly designed from a business
application deployment standpoint.  It has absolutely no ability to work in
a real world environment.  It works if you're deploying a new application on
a server and you can afford to have the server down the entire time you're
deploying.  It DOES NOT WORK for hot-swap upgrades.  This is not about a
better mousetrap, it's about not having indoor plumbing.


> > Somebody needs to stand up, look the J2EE
> > developers right in the eye, and say, "You are
> > not meeting the needs of the business community."
>
> Go for it!  You're on the Java Toolbox team; perhaps you have
> some links or references we can use to influence the J2EE
> standard setters?

Much easier way - vote with your wallet.  Don't use stuff that isn't ready
for primetime.  Use other solutions and tell the vendor why.  I guarantee
you they'll change their tune.  But if you and others like you continue to
work around the problems and just accept them, then they won't get fixed
anytime soon.


> > Because otherwise, you're going to have to use
> > a third party product just to develop you applications,
> > and heaven help you if you need to support a
> > platform that vendor doesn't support.
>
> But that's the case already, isn't it?  Nobody uses Emacs and Javac for
> production work, do they?  Maybe I misunderstand the situation.
> It wouldn't
> be the first time...

Actually, lots of people use Javac in conjunction with Ant or make for
production work.  I'm not sure what you're getting at.  With WebSphere 3.5,
we could easily create our own directory structure and deploy at will.  And
in fact, through judicious use of symbolic links, I'm managing to do just
that.  But you want to know the sad thing?  Symbolic links aren't supported
by EAR/WAR files.  So now that I've gotten around the problem, I'm stuck
with another limitation that was put in place by folks who don't understand
business application development.

Anyway, if I'm not making sense, then perhaps you might try deploying a few
net changes and see what happens.  On my model 270, deploying a single-line
fix ON A TRIVIAL APPLICATION took 20 minutes, most of which time the
application server was unavailable.  If you think this is acceptable from a
production standpoint every time you need to deploy a hot fix, then you come
from a different environment than I do.

Joe