directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <aok...@bellsouth.net>
Subject RE: Turning Service Impls into POJOs
Date Sun, 07 Dec 2003 19:15:17 GMT
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

 

 


Mime
View raw message