avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincent Massol" <vmas...@octo.com>
Subject [submission] AvalonJ2EE integration framework
Date Sat, 30 Mar 2002 12:04:59 GMT
Hi,

Here are some classes that I'd like to submit to the Excalibur project
for bridging the gap between Avalon and J2EE.

This is a first draft (and I am expecting comments). I am currently
using this system on a J2EE system and we'll go in production with it.

I have extracted out a part of our code, changed the package names, etc.

Here is how it works :

There are 3 kinds of objects in our system :
- standard java classes
- EJBs
- Avalon Components

The goal of these integration classes is to let any of these 3
components get a handle to each other. In order for this to work, any
standard java class that wants to have access to an Avalon component
must extend AbstractCommonObject and any EJB class that wants to have
access to an Avalon component must extend either AbstractEntityBean,
AbstractSessionBean or AbstractMessageDrivenBean. They will then benefit
from a getComponentManager() API.

[Note: The other option would have been to publish the Component Manager
to JNDI but I'm not too sure how to do that easily and we would fall
into the EJB paradigm. With the above solution we stay in the Avalon
paradigm].

Obviously any standard java class or any Avalon that wants to access an
EJB can do a JNDI lookup, but this is usually not needed as a good
architecture will probably use the components in the following kind of
way :

User ----> SLSB or MDB (coarse grained services) ----> Avalon component
(fine-grained services) ----> Avalon components (Data Managers - JDBC
access) ----> Avalon component (Generic JDBC Data Access component)

WRT logging and configuration, the strategy we have chosen (which is not
in the provided classes as I have removed it - You'll need to tell me if
I should add it again), is the following :

- Have a Logger component (i.e. not use the Loggable or LogEnabled
interfaces)
- Have a Configuration component (a wrapper around property resource
bundles)

This is in order to have a consistent way to log and configure between
EJBs, Avalon components and standard java classes. Again, I can provide
these classes (which could go in Excalibur) if there's interest. 

Note: I can also provide the generic JDBC data Access component.

Also, as Logging and getting configuration data are the most used
components, we have added specialized API in CommonObject (which I have
removed in the provided version) :

- getLogger()
- getConfiguration(String name) where name is the logical name of the
resource bundle (i.e the name in ECM systemConfig.xml).

Note: Actually we have added 2 more APIs: getTechnicalConfiguration()
and getMessageConfiguration() as we have chosen to have only 2
configuration files, one for technical properties and one for messages
(logging messages and exception messages that we want to externalize).

We have added an AbstractAvalonComponent which inherits from
CommonObject and implements getLogger(), getConfiguration(), etc.

Thus, any "component" (standard java class, EJB or Avalon component)
simply needs to issue :

getLogger().debug("....") or
getTechnicalConfiguration().getString("...") ....

to access the service.

Note: I have not provided AbstractAvalonComponent as it makes only sense
if have getLogger(), etc in CommonObject.

Last, the provided classes do not initialize the ECM. This is
application specific and depends completely of your application. In our
case (WebLogic 6.1) we do the initialisaton of ECM in an EJB (packaged
as a J2EE module) which we have configured to be loaded *before* any
other J2EE module (it is possible to specify that with WL).

The important step is that wherever you choose to initialize your ECM,
you must call the Initialisation.setComponentManager(ComponentManager)
method prior to any CommonObjet class calling getComponentManager().

Tell me what you like/don't like and I'll make the modification and
hopefully we'll be able to include that in Excalibur (I have chosen the
org.apache.avalon.excalibur.j2ee package but we can pick anything you
like) and add a chapter that recap what is said in this email in the
Developing with Avalon guide.

Last note: In our implementation the
Initialisation.getComponentManager() throws a Runtime exception if the
component manager has not been initialized. In the version I have
provided I have made it throw a ComponentException which is a checked
exception, thus, any method that calls getComponentManager() must either
catch it or rethrow it. I'm not sure if this is the best approach.
However, it seems ok as this is what is done by compose() and
CM.lookup(). Comments ?


How is that ?
Thanks
-Vincent

Mime
View raw message