directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject RE: [seda] API & IMPL project/jar consolidation
Date Mon, 20 Sep 2004 15:06:51 GMT

Most of my comments are in line.  However before going further I just
wanted to say that I asked Stephen to show, really show where I was
messing up.  I asked for his expert opinion because of his expert
experience with ClassLoader issues in building IoC containers.  I also
asked because I wanted to make absolutely sure I was not doing something
that was going to come back to bite me in the arse.  I'm greatful that
he is willing to give the time to make sure the right outcome is

Ok with that said I still respectfully disagree with him for numerous
reasons outlined below.  Thanks to Stephen I think we can be sure that
there will be no CL issues in container environments unless someone opts
to use the packaged convenience Logging monitor classes within a
container environment.

On Mon, 2004-09-20 at 05:45, Stephen McConnell wrote:
> > -----Original Message-----
> > From: Noel J. Bergman []
> > Sent: 20 September 2004 02:24
> > To: Apache Directory Developers List
> > Subject: RE: [seda] API & IMPL project/jar consolidation
> > 
> > Stephen McConnell wrote:
> > > If I understand correctly you are including a reference to a
> > > version of commons-logging in classes that would not be
> > > isolated behind an api.
> > 
> > Commons Logging is intended to be an API.  The implementations are
> > supposed
> > to be decoupled.  If you have issues with how Commons is structured,
> you
> > should probably raise them (there).
> My point was not specific to commons logging - it was specific to
> consequences related to non-separation of services from implementation
> concerns at the packaging level and addressing the example from Alex

Packaging level separation analogies to interface+imlp code sparation
can only be taken so far.  To facilitate reusable components in a
framework I agree this is the best approach to deal with the various
ClassLoader issues you have shown to arrise.  You're totally right when
we're talking about people developing a common set of shared, reusable

> linked to the inclusion of common-logging under the SEDA API.  Logging
> in general is not part of a service contract (any logging) - its part of
> the implementation of the service.  

All POJO classes within the seda-x.y.jar will not depend on
commons-logging (CL).  If users of the API opt to replace the default
monitor adapters for POJO monitors with Logging monitors packaged for
convenience then they impose a RT depenency on CL.  All we can say is
Caveat emptor (let the buyer beware).  Use these Logging monitors at
your own risk - do not to use them in container environments where
ClassLoader conflicts may result.

> Keep in mind that separation of API and implementation at the packaging
> level is similar to the principals of separation of interface and class.

Again there is a limit to where this analogy can go.  We've approached
those limits here.

> One defines a contract while the other is the implementation of the
> contract.   With separation at package level a container can isolate
> implementation classes away from the main api classloader chain.  This

Right but this all depends on what you interpret as implementation and
as API.  An API can have classes in it.  API's are not just for
interfaces and exception classes.  As far as I am concerned the default
POJO implementations are part of the API.  They have ZERO deps like
their service interfaces.  They can be used or not but using them will
NOT impose a dependency on CL thanks to the NoLogging approach used

> means that "implementation" dependencies are placed in separate isolated
> classloaders derived from the api chain - thereby largely minimizing the
> potential conflicts that can occur.

Absolutely right if we were building reusable components for something
like Avalon Planet.  Still we do not have this problem for the SEDA API.

> Achieving good isolation requires that the entire api chain is composed
> of clean apis.  An api exposing common-logging (or any other
> implementation artifact) is not a clean api.  The result is the
> effective infection of the api chain by a badly structure api.  While
> infection may not be intentional, the existence of implementations
> classes opens up potential for conflict and potential security risks.

We package these logging monitors as optional monitor classes.  If they
are not used CL is never needed in any ClassLoader in the lineage path
of ClassLoaders.  There is no infection.  My Merlin wrappers never touch
these logging monitors because I use Avalon specific logging classes in
these wrapper implementations.  As far as I am concerned wrapper jars
will be separated as true implementation classes not being packaged as
part of the seda-x.y.jar.

If the logging monitors dependening on CL are used and the SEDA POJO's
live inside a container environment then we have the potential
'infection' you refer to true.

These monitors are here for a special standalone harness application
with a main() so it is not only used for unit testing.  It's used for
beta testing protocols our users develop inside the framework without
needing a container like Merlin, or Geronimo.  Or its used when they do
not want to run this thing with Merlin or Geronimo but want to keep
things really thin for there protocol server app.  The harness hardwires
all the POJOs so the frontend can come up without a microkernel.  For
this little application/tool I would like some logging to happen and I
use the CL monitors to achieve that.

I could have packaged this harness app/tool in a separate JAR but I
don't want more entropy.  Having this code sit in the same JAR when run
inside say Avalon containers does not impose the CL dependency unless I
start using these logging monitors in my wrappers.

> In this case .. the combining of the real SEDA api with implementation
> cases (or test classes exposing implementation classes mixed in with an
> api) will create a bad api in that it is the source of api chain
> infection. 

I'm willing to accept a comprimise.  If this move bites me in the arse I
can always come back and correct things by splitting up the JAR. 
Nothing is set in stone.  Look in the end you have some very good points
as a purist in the IoC world.  I'm willing to accept that you're right -
I just don't know if your conclusions are statistically significant
across use cases.  I'm willing to take a risk here. 

I would rather have less entropy, less confused users, happy users with
one jar hence a single artifact, and all the tools needed for a protocol
developer in one place.  This all in exchange for a small risk where
users of the API may contaminate a ClassLoader lineage path in a
container.  In the end 99% of the users will never create the problem u
mention.  Keeping them happy is my goal so long as this API spreads like
wild fire ;).  A single jar will help make that happen.


View raw message