You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Jeremy Boynes <jb...@apache.org> on 2005/08/13 20:45:17 UTC
Coupling to j2ee module
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
Re: Coupling to j2ee module
Posted by ja...@mac.com.
On 13 Aug 2005, at 19:45, Jeremy Boynes wrote:
> 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.
+1. Runtime dependency on this stuff is painful. Where possible
static inner classes or separate classes for the metadata would be
good. Even better would be to auto-generate all the metadata at build
time to ensure there's no runtime dependency on j2ee module and
remove lots of repetitive coding.
James
-------
http://radio.weblogs.com/0112098/
Re: Coupling to j2ee module
Posted by Jeremy Boynes <jb...@apache.org>.
Aaron Mulder wrote:
> 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?
>
:-(
We had this problem in core/common before and have tried gradually to
make things more modular.
David Jencks has had some thoughts about supporting different naming
schemes and I'd like to hear his thoughts.
> 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.
>
Because by changing it we just bumped the version of the j2ee module say
from 1.0.2 to 1.0.3 so then we have to update the Jetty module to
reflect the new dependency which ripples to things that use the Jetty
module and so on. So someone using Jetty needs to investigate why the
version changed which means investigating why the j2ee module version
changed which means determining whether the change did or didn't impact
their usage. Small change, big impact.
--
Jeremy
Re: Coupling to j2ee module
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
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
>