You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Vincent Massol <vm...@octo.com> on 2002/03/30 13:04:59 UTC
[submission] AvalonJ2EE integration framework
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
Re: [submission] AvalonJ2EE integration framework
Posted by Paul Hammant <Pa...@yahoo.com>.
Vincent
>>to get it compiling from a position of 'vanilla' CVS checkout.
>>
>
>Ok. It is easy no ?, simply do like Ant is doing and only build stuff
>for which you have the correct jars in your classpath ? (using
><available> as you mentionned). Just output a warning that it won't be
>built because j2ee.jar is not in the classpath or something like it.
>
Yes.
>>InitialiZation sounds like it should be an interface. It also sounds
>>very generic, like it should be in the core framework.
>>
>>interface ComponentManagable extends ComponentManaged {
>> void setComponentManager(ComponentManager manager)
>>}
>>
>>class AbstractComponentManagable implement ComponentManagable {
>> // blah
>>}
>>
>>Yeesh, I have just seen the static in the methods you submitted.
>>
>static
>
>>is implicitly part of the anti-pattern to the IoC pattern (when
>>
>overused).
>
>Yes, this is all nice but looks very overkill to me for a simple adapter
>class. You still haven't resolved the difficult question of how you
>initialize the component manager for objects that extend
>ComponentManageable. See below.
>
>But I'm +1 to add these interfaces. They are a bit artificial but that's
>ok.
>
You're trying to make something reusable and reimplementable yes? If
no, then perhaps it should not be in our framework... ;-)
>>>However we could have something like :
>>>
>>>public class MyBean extends AbstractSessionBean
>>>{
>>> private transient componentManager;
>>>
>>> public MyBean()
>>> {
>>> setComponentManager(super.getComponentManager());
>>> }
>>>
>>In the constructor ? None of the framework implementing beans
>>
>anywhere
>
>>else at Apache or SourceForge (BICBW) have component manager in
>>initialized in the constructor.
>>
>
>I would agree with you if I were trying to create a component manager
>framework. But this is not the case. I'm just writing an adapter to
>bridge the gap between 2 existing component frameworks and I don't
>really care whether the adapter itself does implement IOC or not.
>
Hmmmmm. Refer my above comment.
Are you beans going to use logging? Yes I would guess. I'll also guess
they are going to use Log4J (as every does). Ahhh, but we have an IoC
alternative to Log4J, called LogKit.
Consider :
class Bean01 .. {
public Bean01() {
}
public void ejbPostCreate() {
AvalonEJBSingleton.get().doLifecycleStartup(this);
}
}
class AvalonEJBSingleton {
// blah
public void doLifecycleStartup(Object bean) {
if (bean instanceof LogEnabled) {
((LogEnabled) bean).enableLogging(mLogger);
}
if (bean instanceof Contextualizable) {
((Contextualizable) bean).contextualize(getContext());
}
if (bean instanceof Configurable) {
((Configurable) bean).configure(.... );
}
if (bean instanceof Composable) {
((Composable) bean).compose(mCompMgr);
}
if (bean instanceof Parameterizable) {
((Parametrizable) bean). .....
}
// others are irrelvent under EJB control.
}
}
I.e. just because you only have need for compMgr, does not mean it is
all you should write when trying to make Avalon comps...
>
>>This < http://jakarta.apache.org/avalon/framework/lifecycle.html > is
>>
>an
>
>>essential read.
>>
>
>I have read it several times ... It's good but it has nothing to do with
>EJBs. I can't change the EJB lifecycle. I have to do with what exists.
>
Logging, Context, Parameters.
If EJB had daemon beans like Enterprise Object Broker, then Startable,
Runnable too..
>>First line "Here are some classes that I'd like to submit to the
>>Excalibur project" eluding to "about to" as in imminent/future.
>>
>>Of course you are factually correct in that you did not say it :-)
>>
>
>yes. My intent is double :
>- bring some ideas on the mailing list and show how I have performed the
>integration between Avalon and EJB for my current project,
>- formalize a bit (although I haven't much time) the result and submit
>it so that it can be included either as part of Excalibur in sources
>and/or as documentation.
>
Man ' have not much time' is a warning sign. I am lucky enough to be
unemployed at the moment so can make noise, diffs or commits quite alot.
I think you have something here in terms of enhancing the EJB
environment. I think we are prepard to grant you space to evolve this
(i.e. we do not rush in and do it on our own before your finish).
However, I think you should make the time, OR lengthen the timescale
for deliver (to us).
>This current discussion is only to get this started and will lead me to
>propose some reworked classes (change names and maybe strategy if you
>convince me you have better).
>
Hopefully we have given you food for thought....
>>>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) ?
>>>
>>I think your *big* problem is the one of how to 'decorate' the
>>
>lifecycle
>
>>things post construction. Maybe some sucky static accessor to the
>>Avalon-like kernel from ejbPostCreate()...
>>
>
>ah. Here's the heart of the issue, I agree. There are several solutions
>:
>
>- simply call getComponentManager().lookup("") whenever you need a
>component from your EJB (which is what we're doing on the project).
>
>- use the constructor as mentioned above. You haven't convinced me it is
>a problem.
>
This is snipped from your proposal.....
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;
}
}
You do not see a problem? I could leave you to torture yourself, but it is as follows..
class Clazz {
public Clazz() {
hello(); // <-- can't do that, it ain't an instance yet.
}
private void hello() {
}
}
>- use ejbCreate or ejbPostCreate. Seems ok to me (with the risk of being
>called more often that the constructor solution - I'm not sure, would
>have to look at the EJB lifecycle again).
>
:-)
>
>But for all these approaches you still need to publish the ECM
>somewhere. The solution I proposed was to publish it in Initialisation
>(which name should be changed, I agree :-)).
>
>It seems we are in agreement after all ?
>
>Shall I make a second proposal ?
>
:-)
But please encompas more of the Avalon framework interfaces.
>You still haven't given me your opinion about the unified
>logging/configuration ... :-)
>
See above.
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [submission] AvalonJ2EE integration framework
Posted by Vincent Massol <vm...@octo.com>.
> -----Original Message-----
> From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
> Sent: 30 March 2002 14:08
> To: Avalon Developers List
> Subject: Re: [submission] AvalonJ2EE integration framework
>
> Vincent
>
> >>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.
> >
> Use of course is a different issue. I am principally worried about
the
> newbie's attempt to compile the whole of Excalibur. A property is a
> start, but I have illustrated in todays other thread that I belive
that
> we should smooth the patch of the newbie with decent suggestions on
how
> to get it compiling from a position of 'vanilla' CVS checkout.
Ok. It is easy no ?, simply do like Ant is doing and only build stuff
for which you have the correct jars in your classpath ? (using
<available> as you mentionned). Just output a warning that it won't be
built because j2ee.jar is not in the classpath or something like it.
>
> >>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
> >?
> >
> ComponentManaged (it is an interface). Still not perfect.
>
> public interface ComponentManaged {
> ComponentManager getComponentManager() throws ComponentException;
> }
>
> Note also that 'public' does/should not be specified on interface
methods.
Ah! This is new to me. Cool, I have learnt something today ! :-). Makes
sense. I shall add this as a feature request for checkstyle ...
>
> >>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 ?
> >
> InitialiZation sounds like it should be an interface. It also sounds
> very generic, like it should be in the core framework.
>
> interface ComponentManagable extends ComponentManaged {
> void setComponentManager(ComponentManager manager)
> }
>
> class AbstractComponentManagable implement ComponentManagable {
> // blah
> }
>
> Yeesh, I have just seen the static in the methods you submitted.
static
> is implicitly part of the anti-pattern to the IoC pattern (when
overused).
Yes, this is all nice but looks very overkill to me for a simple adapter
class. You still haven't resolved the difficult question of how you
initialize the component manager for objects that extend
ComponentManageable. See below.
But I'm +1 to add these interfaces. They are a bit artificial but that's
ok.
>
> >
> >
> >>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).
> >
> But you are trying to use interfaces from 'framework' that exist
because
> of a belief in the IoC design.......
>
> >However we could have something like :
> >
> >public class MyBean extends AbstractSessionBean
> >{
> > private transient componentManager;
> >
> > public MyBean()
> > {
> > setComponentManager(super.getComponentManager());
> > }
> >
> In the constructor ? None of the framework implementing beans
anywhere
> else at Apache or SourceForge (BICBW) have component manager in
> initialized in the constructor.
I would agree with you if I were trying to create a component manager
framework. But this is not the case. I'm just writing an adapter to
bridge the gap between 2 existing component frameworks and I don't
really care whether the adapter itself does implement IOC or not.
>
> This < http://jakarta.apache.org/avalon/framework/lifecycle.html > is
an
> essential read.
I have read it several times ... It's good but it has nothing to do with
EJBs. I can't change the EJB lifecycle. I have to do with what exists.
>
> > 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 ?
> >
>
> First line "Here are some classes that I'd like to submit to the
> Excalibur project" eluding to "about to" as in imminent/future.
>
> Of course you are factually correct in that you did not say it :-)
yes. My intent is double :
- bring some ideas on the mailing list and show how I have performed the
integration between Avalon and EJB for my current project,
- formalize a bit (although I haven't much time) the result and submit
it so that it can be included either as part of Excalibur in sources
and/or as documentation.
This current discussion is only to get this started and will lead me to
propose some reworked classes (change names and maybe strategy if you
convince me you have better).
>
> >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) ?
> >
> I think your *big* problem is the one of how to 'decorate' the
lifecycle
> things post construction. Maybe some sucky static accessor to the
> Avalon-like kernel from ejbPostCreate()...
ah. Here's the heart of the issue, I agree. There are several solutions
:
- simply call getComponentManager().lookup("") whenever you need a
component from your EJB (which is what we're doing on the project).
- use the constructor as mentioned above. You haven't convinced me it is
a problem.
- use ejbCreate or ejbPostCreate. Seems ok to me (with the risk of being
called more often that the constructor solution - I'm not sure, would
have to look at the EJB lifecycle again).
But for all these approaches you still need to publish the ECM
somewhere. The solution I proposed was to publish it in Initialisation
(which name should be changed, I agree :-)).
It seems we are in agreement after all ?
Shall I make a second proposal ?
You still haven't given me your opinion about the unified
logging/configuration ... :-)
Thanks
-Vincent
>
> Regards,
>
> - Paul H
>
>
>
> --
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [submission] AvalonJ2EE integration framework
Posted by Paul Hammant <Pa...@yahoo.com>.
Vincent
>>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.
>
Use of course is a different issue. I am principally worried about the
newbie's attempt to compile the whole of Excalibur. A property is a
start, but I have illustrated in todays other thread that I belive that
we should smooth the patch of the newbie with decent suggestions on how
to get it compiling from a position of 'vanilla' CVS checkout.
>>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
>?
>
ComponentManaged (it is an interface). Still not perfect.
public interface ComponentManaged {
ComponentManager getComponentManager() throws ComponentException;
}
Note also that 'public' does/should not be specified on interface methods.
>>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 ?
>
InitialiZation sounds like it should be an interface. It also sounds
very generic, like it should be in the core framework.
interface ComponentManagable extends ComponentManaged {
void setComponentManager(ComponentManager manager)
}
class AbstractComponentManagable implement ComponentManagable {
// blah
}
Yeesh, I have just seen the static in the methods you submitted. static
is implicitly part of the anti-pattern to the IoC pattern (when overused).
>
>
>>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).
>
But you are trying to use interfaces from 'framework' that exist because
of a belief in the IoC design.......
>However we could have something like :
>
>public class MyBean extends AbstractSessionBean
>{
> private transient componentManager;
>
> public MyBean()
> {
> setComponentManager(super.getComponentManager());
> }
>
In the constructor ? None of the framework implementing beans anywhere
else at Apache or SourceForge (BICBW) have component manager in
initialized in the constructor.
This < http://jakarta.apache.org/avalon/framework/lifecycle.html > is an
essential read.
> 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 ?
>
First line "Here are some classes that I'd like to submit to the
Excalibur project" eluding to "about to" as in imminent/future.
Of course you are factually correct in that you did not say it :-)
>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) ?
>
I think your *big* problem is the one of how to 'decorate' the lifecycle
things post construction. Maybe some sucky static accessor to the
Avalon-like kernel from ejbPostCreate()...
Regards,
- Paul H
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [submission] AvalonJ2EE integration framework
Posted by Vincent Massol <vm...@octo.com>.
Thanks Paul for you review. See below.
> -----Original Message-----
> From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
> 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-
> 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>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [submission] AvalonJ2EE integration framework
Posted by Paul Hammant <Pa...@yahoo.com>.
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?
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.
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: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [submission] AvalonJ2EE integration framework
Posted by Peter Donald <pe...@apache.org>.
Hi,
Looks good. A few things though; static variables violate the EJB spec and
are thus not portable across different vendors EJB implementations. Thus I
believe that the Initialization class will only work in certain EJB
containers. Quite a few vendors are starting to implement isolation via a
number of hacks or solid engineering. (Some of it looks sweeet!!!)
I suspect that the big name containers will actually be moving to the Isolate
API in Q1->Q2 2003 which will mean that static variables will be guarenteed
not to work - even for non-cluster, non-distributed completly in-JVM local
EJBs.
Thus I would suggest that you seriously consider using JNDI to store the
ComponentManager in. I am not aware about how different vendors tools support
this and unfortunately I think that it is different for each vendor. Most of
them do however provide some mechanism to do it.
As about how to integrate it into the EJB system .. not sure. I guess I would
do it like something like the following...
public interface AvalonEJBFrame
{
Logger getLogger();
Configuration getConfiguration(); //or Parameters
ServiceManager getServiceManager(); //or ComponentManager
}
public abstract class AbstractAvalonEJB
{
private AvalonEJBFrame _frame;
protected void initialize()
{
Context c = new InitialContext();
_frame =
(AvalonEJBFrame)c.get( "java:.insert proper namespace here" + getName() );
}
protected void dispose()
{
_frame = null;
}
protected Logger getLogger() { return _frame.getLogger(); }
protected Configuration getConfiguration()
{ return _frame.getConfiguration(); }
protected ServiceManager getServiceManager()
{ return _frame.getServiceManager(); }
}
And then have each different EJB type call initialize/dispose where it is
most appropriate for that bean. (ie ejbCreate or whatever).
Note however that I dont use the ECM and all my EJB efforts to date have been
toy applications so I could be completely wrong.
Anyways what do you think of that ?
--
Cheers,
Pete
"Invincibility is in oneself, vulnerability in the opponent." -- Sun Tzu
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>