Task Scheduling

Bryan Sant bryan.sant at gmail.com
Wed Jan 25 13:22:34 MST 2006


On 1/25/06, Ryan Bowman <ryanlbowman at gmail.com> wrote:
> Um, you do know that the current version is 4.0.3, right?  It's worked

They have 5 in beta.  I haven't used it.  Maybe they fixed some things.

> okay for us, I don't know anything about ejbs, I'm just a code monkey

If you don't use EJBs, then you should just use a web container such
as Tomcat.  Your performance will improve.  And tomcat actually knows
how to dynamically load a WAR correctly.

> right now, so I don't know what other appservers would gives that
> jboss doesn't.  I think most, if not all, of the problems we've had
> with it have been misunderstandings, misconfig, etc on our part.

The J2EE spec doesn't define the specifics of how the app server
should manage  class loading -- so JBoss is free to be an idot and
still be "J2EE standards compliant".  However, EVERY OTHER app server
vendor in the world has followed a very intuitive classloader
convention.  Each WAR, or EAR, has it's own class loader hierarchy. 
Two or more WARs or EARs don't conflict or effect their neighbor, but
they do expose classes to their subordinate components.  So a WAR
inside an EAR would see the parents classes, but not the opposite. 
Well not with JBoss!!  JBoss' class loader model is screwed in a
number of ways, but basically it has a flat class loader.  Everyone
can see everyone elses classes.  It is TOTAL CHAOS.

To keep things sane, you should run a single application on a given
JBoss instance.  Running more than one WAR or EAR will only lead to
extreme anger and depression.

...Or just use Apache Geronimo or Resin and everything is cool...  But
again, Spring + Tomcat is typically a MUCH better solution (as it is
MUCH simplier AND more powerful) for most applications that you would
typically consider running on a full J2EE server.  With Spring,
developer and runtime performance goes up and complexity goes way down
-- it is magic.  Check it out at www.springframework.org.

-Bryan



More information about the PLUG mailing list