directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen McConnell" <>
Subject RE: [seda] API & IMPL project/jar consolidation
Date Mon, 20 Sep 2004 09:45:32 GMT

> -----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,
> 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
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.  

Keep in mind that separation of API and implementation at the packaging
level is similar to the principals of separation of interface and class.
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
means that "implementation" dependencies are placed in separate isolated
classloaders derived from the api chain - thereby largely minimizing the
potential conflicts that can occur.

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.

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


View raw message