users@jpa-spec.java.net

[jpa-spec users] Re: [javaee-spec users] [jsr342-experts] Re: Re: Modularization Framework/SPI

From: Craig Ringer <ringerc_at_ringerc.id.au>
Date: Thu, 26 Jul 2012 21:54:45 +0800

On 07/26/2012 07:41 PM, Jeff Genender wrote:

> Here are what I usually hear:
>
> 1) The comments made come along the line of the thick stack and having resources used by major components that aren't used. Complaint is EE-bloat.
That's really interesting given the *relatively* small footprint of idle
Glassfish or JBoss AS 7 instances. Are they talking mostly about modern
EE6 servers, or proprietary/older stuff? More importantly, have any of
these customers backed these perceptions with /hard data/ and measurements?

I'd be fascinated to see measurements of the perceived bloat where app
deployments on EE servers are compared to roll-your-own equivalents.

I don't think AS7, Glassfish 3, etc are in any sense "light" - I'm just
wondering if roll-your-own systems actually gain anything much in
resource use terms, or whether most of that "bloat" lands up being in
the implementations of JPA, JTA, and the other parts of the stack
that're used in roll-your-own options too.

> 2) Ability to hot deploy/undeploy without corrupting the classloaders. Example... try to deploy/deploy a war many times in a standard JavaEE container until an OutOf Memory exception occurs.
I gave up on Glassfish and moved over to AS7 because of exactly this
problem. Thanks to its module system and class loader isolation I've
never seen a PermGenSpace OutOfMemoryException on AS7.

I agree that this is an extremely annoying and frustrating problem that
urgently needs a solution. With AS7, JBoss has demonstrated that the
solution doesn't need to be provided as part of, or mandated by, the EE
spec, it's possible within the scope of the existing specifications.

(I don't have any relationship whatsoever with JBoss, I just like
working with AS7 and have had good results with it).
> 3) Ability to provision applications and services on the fly without having to reboot - think cloud-like Applications As A Service (AaaS).
Under what circumstances would it be necessary to reboot normally? By
reboot do you actually mean reboot the host? Restart the app server?
Redeploy the app to the container? Deploy new apps or modules to the
container?

> 4) Ability to prevent class clashing with multiple versions. Wanting to run multiple applications in the same container without worry for parent classloading corruption - the class tree classloading issues.
Again, at least in my admittedly limited experience JBoss AS 7 seems to
have this mostly solved. About the only time you'll run into hiccups is
where instances want to cross module boundaries between an app-server
bundled version and a client version and encounter different and
incompatible versions of their classes. I've only encountered this once.

So long as the client and app server versions of libraries (or different
versions in different clients) don't have to come into direct contact
and interact, it all works quite peachily, and they all co-exist happily
on the same JVM. I've been very impressed.

Again, I'll admit I had problems with this when working on Glassfish,
especially with transitive dependencies liking to pull in conflicting
versions of Xerces when I didn't keep a close enough eye out.

> 5) Dependent execution. The ability to run transitive dependencies on other applications/jars, much like a Unix inti.d or Windows services model. i.e. an application can;t run until its other dependent applications are running.
You certainly need a module system for this.
> OSGi seems to wor in this model, albeit with a great amount of pain.
It does, and I agree it's painful.

Given the OSGi support in both Glassfish and AS7, I'm surprised your
customers felt compelled to roll their own rather than build on that
support. Was it the inability to replace wired-in components like JTA
implementations that swayed them?

--
Craig Ringer