Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <42FE3FBD.8000701@apache.org>
Date: Sat, 13 Aug 2005 11:45:17 -0700
From: Jeremy Boynes <jboynes@apache.org>
User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc3 (X11/20050720)
MIME-Version: 1.0
To: dev@geronimo.apache.org
Subject: Coupling to j2ee module
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I am starting to get concerned about the degree of coupling to the j2ee 
module and wary of repeating what happened with core where we end up 
with everything in the server depending on it. The problem, of course, 
is that any modification to the j2ee module requires a redistribtion of 
everything breaking the modularity of the server.

One thing in there is NameFactory which is commonly used to generate 
GBeanInfo objects. For example, Jetty's HTTP connector contains
     infoFactory.addReference(
         "JettyContainer",
         JettyContainer.class,
         NameFactory.GERONIMO_SERVICE);

The other thing in there is all the common management APIs e.g. taking 
the Jetty connector again:

public abstract class JettyConnector
     implements GBeanLifecycle, JettyWebConnector {

and

     infoFactory.addInterface(JettyWebConnector.class);
     infoFactory.addInterface(StateManageable.class);

These usages mean that the Jetty web connectors cannot be used without 
the j2ee module being present at runtime.

So what should we do about this?
At a minimum I think we should separate the GBeanInfo construction from 
the implementation just like Hiram did for the connector module by 
moving it into a helper class. That will avoid the need to access j2ee 
classes in the initializer.

We should also reconsider whether a bean should implement its management 
interface (as define by the j2ee module). Doing so has the advantage 
that incomplete implementation is detected at compile time but the cost 
is the coupling back to the j2ee module. IMO the long term problems 
caused by coupling outweigh the advantage of compile time detection 
especially when there are even rudimentary unit tests present and when 
the interfaces are being proxied anyway.

At the least I think we should move the management interfaces to a 
separate module containing just those interfaces and without any J2EE 
implementation artifacts (like JVMImpl).

--
Jeremy