avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Hammant <Paul_Hamm...@yahoo.com>
Subject Re: [submission] AvalonJ2EE integration framework
Date Sat, 30 Mar 2002 12:39:16 GMT

First glance - it appears your are cementing some things that many of us 
have done again and again in in-house bean projects before.. :-)


1) package name j2ee.   Is that the correct name for something that is 
in the 'ejb' scope?

2) legallity.  Apache can't include the ejb jar for compilation purposes 
in a source distro.  Same as we can't distribute servlet.jar in a source 
distro.  The best we could do is careful use of <available> and a Ant 
target or two to get it from a known place.

3) CommonObject as am interface name does not sit well with me.

4) Initialisation seems to be a class.  Apart from the name, would it 
not be better to interface/impl separate this and have /an/ impl extend 
AbstractEnterpriseBean ?  With two more Session/Entity abstractions 
extending it.

5) How are you going to perform the IoC style compose()ing in a bean 
container.  Is there a reverse IoC singleton that is called statically 
to do the IoC stuff?

6) Lastly, you say 'about to' in terms of use.  Maybe that means that 
you 'should do' first even with apache package names, evolve them a 
little then bring them back as a submission.  I guess that is your 
intention anyway...  you're just peer reviewing now.


- Paul

>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
>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
>- Have a Configuration component (a wrapper around property resource
>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 ?
>To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message