Thanks Paul for you review. See below.
> -----Original Message-----
> From: Paul Hammant [mailto:[EMAIL PROTECTED]]
> Sent: 30 March 2002 12:39
> To: Avalon Developers List
> Subject: Re: [submission] AvalonJ2EE integration framework
>
> Vincent,
>
> First glance - it appears your are cementing some things that many of
us
> have done again and again in in-house bean projects before.. :-)
>
> Thoughts...
>
> 1) package name j2ee. Is that the correct name for something that is
> in the 'ejb' scope?
>
agreed. "ejb" would be a better name.
> 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.
We can surely have a j2ee.jar Ant property that points to where the
person building the project has its j2ee.jar file, right ? This is just
to compile it. We don't need to include it in a distribution. Anyway the
person who wishes to use these classes would be running in an EJB
container and would have it in its classpath.
>
> 3) CommonObject as am interface name does not sit well with me.
Me too ... :-). I had another name but there was the name of the company
in it and I changed it quickly. What do you propose ? AvalonAwareObject
?
>
> 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.
Not sure I understand. Do you mean to separately initialized a CM for
EJB and for standard java classes instead of in a single location ?
>
> 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?
We don't do IOC for EJBs (the only use case that I can think of is for
unit testing mockobjects - but there are probably others).
However we could have something like :
public class MyBean extends AbstractSessionBean
{
private transient componentManager;
public MyBean()
{
setComponentManager(super.getComponentManager());
}
public void setComponentManager(ComponentManager manager)
{
this.componentManager = manager;
}
public ComponentManager getComponentManager()
{
return this.componentManager;
}
[...]
}
which could be moved into AbstractEnterpriseBean.
>
> 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.
>
I've just done a search on my mail and couldn't find where I say "about
to". Can you clarify ?
Yes I am just peer reviewing ...
Do you have any opinion on the Logger and Configuration components ?
Should they be added to excalibur and used from this J2EE integration
stuff (and add getLogger(), getConfiguration() in CommonObject) ?
Thanks
-Vincent
> Regards,
>
> - Paul
>
>
>
> >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
> >
> >
>
>-----------------------------------------------------------------------
-
> >
> >--
> >To unsubscribe, e-mail: <mailto:avalon-dev-
> [EMAIL PROTECTED]>
> >For additional commands, e-mail: <mailto:avalon-dev-
> [EMAIL PROTECTED]>
> >
>
>
>
>
> --
> To unsubscribe, e-mail: <mailto:avalon-dev-
> [EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:avalon-dev-
> [EMAIL PROTECTED]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
