geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <ammul...@alumni.princeton.edu>
Subject Re: Coupling to j2ee module
Date Sat, 13 Aug 2005 19:24:13 GMT
	While this doesn't concern me to the same degree, I'd be happy to 
move the management interfaces to a different package -- perhaps 
modules/management?

	I don't really know what to do about NameFactory -- it's pretty 
useful to have common constants and construction routines.  But it 
certainly doesn't need to be colocated with the JSR-77 implementations 
(while the name structure was defined by 77, there's no relationship at 
the code level).  I just don't know where else to put it.  Perhaps 
modules/common?

	Finally, why does any modification to the j2ee module require a
redistribution of everything else?  Can't you just redistribute the j2ee
module?  I mean, of course you'd need to redistribute elements that say,
implement an interface that just changed, but I don't see why changing the
EJB interface would require you to update the Jetty distribution.

Thanks,
	Aaron

On Sat, 13 Aug 2005, Jeremy Boynes wrote:
> 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
> 

Mime
View raw message