Hi,
I have just finished reading the excellent "Developing with Avalon" PDF
(thanks Berin !) and am very eager to introduce Avalon in my current project
: e-business project using J2EE 1.3.
Here is how I view the integration. I'd like to have feedback in order to
confirm this is the best way to use Avalon in J2EE :
* I plan to only use Avalon Framework, Avalon Excalibur (and possibly Avalon
Cornerstone - but I have not looked at it yet). I don't see the need for
Phoenix at this point.
* There are 2 kinds of components in the application :
- the J2EE components : MDB, Session Beans and Entity Beans
- Avalon-style components : Logging, Configuration, DataAccess, some
business components that have been implemented as standard java classes
because Entity Beans are not performant enough, ...
* There will be 2 containers in my application :
- the J2EE container from the application server which manages the life
cycle of its components using the J2EE spec
- a ContainerComponent class that manages the life cycle of the Avalon
Components (see page 38 of "Developing with Avalon" for the
ContainerComponent)
* The ContainerComponent will be instanciated and initialized in the init()
method of an InitializationServlet Servlet (which has the load-on-startup
attribute set in web.xml so that the initialisation will be performed on
startup). During this initialization, the ExcaliburComponentManager will be
bound to the application server JNDI tree under a given name.
* In the setEntityContext(), setSessionContext() and
setMessageDrivenContext() of the EJBs, we will retrieve the ComponentManager
from the JNDI tree and save it as a class variable of the EJB. Similarly, it
will be removed in the unsetXXXContext() (or ejbRemove() for Session Beans
and MessageDriven Beans)
* All EJBs will use the ComponentManager to use Avalon Component
* All EJBs that need to use an Avalon component (that will be all of them as
logging will be an avalon component - see below) will have to implement the
Initializable interface.
* All components (EJBs and Avalon Components) will extend AbstractLoggable.
However, for EJBs, as the EJB container will not call setLogger() by
default, we'll have to do it ourselves, in setXXXContext(). We'll retrieve
the Logger to use by looking up an Avalon Logging Component, which will have
a getLogger(String category) method which will return a Logger object. Then,
we'll call setLogger(logger) on the EJB. Example:
public void initialize()
{
[...]
// get the ComponentManager from JNDI (default InitialContext())
// Initialise logging
Logging logging = manager.lookup(Logging.ROLE);
setLogger(logging.getLogger(this.getClass().getName()));
[...]
}
public void setSessionContext(SessionContext context)
{
this.context = context;
initialize();
}
Note: As this will be a typical construct for all EJBs (getting the
component manager from JNDI + initializaing logging), we will create a
static helper class for that.
* EJBs that need configuration parameters will implement Configurable. Same
as for logging, the initialize() method will need to call a Config component
that returns a Configuration object.
* Testing: Avalon components will be very easy to unit tests (using JUnit +
Mock Objects strategy) as they implement the IOC pattern.
* EJB Testing: If the EJB makes use of its EJBContext, we'll have to
subclass the EJB, add a compose(ComponentManager) method and override the
initialize() method so that it does nothing. If the EJB does not make use of
its EJBContext, then we will simply not call setXXXContext() as part of the
test initilisation.
What do you think ? Am I missing something ? As someone already done this ?
Thanks
-Vincent
--
Vincent Massol, [EMAIL PROTECTED]
OCTO Technology, www.octo.com
Information System Architecture Consulting
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
