You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Alex Karasulu <ao...@bellsouth.net> on 2003/12/07 20:10:17 UTC
Turning Service Impls into POJOs
Hello,
Take a look here:
Service Interface
http://cvs.apache.org/viewcvs.cgi/incubator/directory/ldap/trunk/eve/fronten
d/event/spi/src/java/org/apache/eve/event/?root=Apache-SVN
Implementations
http://cvs.apache.org/viewcvs.cgi/incubator/directory/ldap/trunk/eve/fronten
d/event/impl/src/java/org/apache/eve/event/?root=Apache-SVN
Here's another service:
Service Interface
http://cvs.apache.org/viewcvs.cgi/incubator/directory/ldap/trunk/eve/fronten
d/listener/spi/src/java/org/apache/eve/listener/?root=Apache-SVN
Implementations
http://cvs.apache.org/viewcvs.cgi/incubator/directory/ldap/trunk/eve/fronten
d/listener/impl/src/java/org/apache/eve/listener/?root=Apache-SVN
BTW Subversion ROCKS!!! - couldn't help but say that!!!
As you can see I have begun to write POJOs instead of services and wrap them
into container specific adapters. This way all of Eve's component's for
both the
frontend and the backend will be compatible with any container supplying an
adapter. Take a look at the Merlin (prefix) based adapters that I have
written in the respective
implementation directories.
The POJOification process has the following benefits:
* components can be tested without having to bend over backwards while
dealing with containers.
* POJO's are easier for people on the team to understand and work with
they
do not need to be experts in the container world.
* the work that needs to be done on a per-container basis can be done
by
those that actually have the proficiency with a specific container.
* the monitor concept is a good idea that is more useful than plain
old logging.
It allows us to decouple the component from the container where logging is
concerned. The monitor interface provided by the POJO service clearly
defines
what is worth monitoring or logging if that's what the monitor
is to do. For
more info on this topic take a look at the following Wiki
page:
http://nagoya.apache.org/wiki/apachewiki.cgi?AvalonNoLogging
Take a look at the monitor interfaces in the SPI directories
for each of these
services while reading the wiki page. This page was
originally written by
Leo Sutic.
Just to clarify this is not an attempt to make things work with Pico. It's
what's right to
do to make the components/services easier to manage, more testable with mock
objects
and compatible with any container/kernel that comes out of Avalon or
anywhere else.
The bottom line is to remain container independent while enabling the
potential
use of any container at the same time. The POJOification process does this
for
us.
I personally plan to support Avalon's Merlin however this opens the door for
the
use of these services in any other containers. If people are willing to
support other
containers by contributing adapters we'll take patches and add em to our
repo.
Thanks,
Alex
RE: Turning Service Impls into POJOs
Posted by Alex Karasulu <ao...@bellsouth.net>.
BTW a POJO is short for Plain Old Java Object.
Also plain old java object means one that does not have to follow
any conventions like a javabean or an Avalon component by
implementating interfaces or employing standards to participate in
some framework.
Hope that clarifies any questions. I should have put that into the
original email.
Alex
_____
From: Alex Karasulu [mailto:aok123@bellsouth.net]
Sent: Sunday, December 07, 2003 2:10 PM
To: 'Apache Directory Developers List'
Subject: Turning Service Impls into POJOs
Hello,
Take a look here:
Service Interface
http://cvs.apache.org/viewcvs.cgi/incubator/directory/ldap/trunk/eve/fronten
d/event/spi/src/java/org/apache/eve/event/?root=Apache-SVN
Implementations
http://cvs.apache.org/viewcvs.cgi/incubator/directory/ldap/trunk/eve/fronten
d/event/impl/src/java/org/apache/eve/event/?root=Apache-SVN
Here's another service:
Service Interface
http://cvs.apache.org/viewcvs.cgi/incubator/directory/ldap/trunk/eve/fronten
d/listener/spi/src/java/org/apache/eve/listener/?root=Apache-SVN
Implementations
http://cvs.apache.org/viewcvs.cgi/incubator/directory/ldap/trunk/eve/fronten
d/listener/impl/src/java/org/apache/eve/listener/?root=Apache-SVN
BTW Subversion ROCKS!!! - couldn't help but say that!!!
As you can see I have begun to write POJOs instead of services and wrap them
into container specific adapters. This way all of Eve's component's for
both the
frontend and the backend will be compatible with any container supplying an
adapter. Take a look at the Merlin (prefix) based adapters that I have
written in the respective
implementation directories.
The POJOification process has the following benefits:
* components can be tested without having to bend over backwards while
dealing with containers.
* POJO's are easier for people on the team to understand and work with
they
do not need to be experts in the container world.
* the work that needs to be done on a per-container basis can be done
by
those that actually have the proficiency with a specific container.
* the monitor concept is a good idea that is more useful than plain
old logging.
It allows us to decouple the component from the container where logging is
concerned. The monitor interface provided by the POJO service clearly
defines
what is worth monitoring or logging if that's what the monitor
is to do. For
more info on this topic take a look at the following Wiki
page:
http://nagoya.apache.org/wiki/apachewiki.cgi?AvalonNoLogging
Take a look at the monitor interfaces in the SPI directories
for each of these
services while reading the wiki page. This page was
originally written by
Leo Sutic.
Just to clarify this is not an attempt to make things work with Pico. It's
what's right to
do to make the components/services easier to manage, more testable with mock
objects
and compatible with any container/kernel that comes out of Avalon or
anywhere else.
The bottom line is to remain container independent while enabling the
potential
use of any container at the same time. The POJOification process does this
for
us.
I personally plan to support Avalon's Merlin however this opens the door for
the
use of these services in any other containers. If people are willing to
support other
containers by contributing adapters we'll take patches and add em to our
repo.
Thanks,
Alex