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 2001/11/10 19:04:51 UTC
Avalon and J2EE : Best practices
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, vmassol@octo.com
OCTO Technology, www.octo.com
Information System Architecture Consulting
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon and J2EE : Best practices
Posted by Berin Loritsch <bl...@apache.org>.
Jeremias Maerki wrote:
> Hi Vincent
>
> Today, I've taken your collected thoughts and put them to use. They were
> very clear and helpful and I'm quite pleased with the results. Well, I
> haven't done any direct EJB testing, yet. I've expected pitfalls but
> there weren't any until now. I think it would be very helpful if these
> ideas could be integrated into Berin's "Developing with Avalon" at some
> time. I'd gladly help doing it as soon as I've finished those two
> projects I'm currently working on (that will be the beginning of March,
> I think).
We would welcome the donation!
>
> On Sat, 10 Nov 2001 18:04:51 -0000 Vincent Massol wrote:
>
>>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 :
>>
>
> <snip/>
>
>>What do you think ? Am I missing something ? As someone already done this ?
>>
>
> Cheers,
> Jeremias Märki
>
> mailto:jeremias.maerki@outline.ch
>
> OUTLINE AG
> Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
> Fon +41 (41) 317 2020 - Fax +41 (41) 317 2029
> Internet http://www.outline.ch
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
> .
>
>
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon and J2EE : Best practices
Posted by Vincent Massol <vm...@octo.com>.
> -----Original Message-----
> From: Jason van Zyl [mailto:jvanzyl@zenplex.com]
> Sent: 20 December 2001 21:17
> To: Avalon Developers List
> Subject: Re: Avalon and J2EE : Best practices
>
> On 12/20/01 1:04 PM, "Vincent Massol" <vm...@octo.com> wrote:
>
> > - In order to consistently do logging (with Log4J) and configuration
> > (single system configuration file) in both J2EE component and Avalon
> > components, we have done the following :
> >
> > * Created a Logger component,
> > * Created a Configuration component (that uses properties file - I
will
> > submit it for Excalibur in beginning of January),
> > * Defined an AbstractComponent class that is Composable, retrieve
the
> > Logger and Configuration components from the CM and offers 2 getters
:
>
> Simply as a point of interest, in the course of looking at using
Avalon
> with
> Turbine I did much the same in stratum (which is the refactoring of
all
> the
> tools that have grown in turbine, a turbine commons of sorts) in order
to
> do
> what need to do vis-à-vis logging and configuration.
>
I guess there must have been a hard discussion at the beginning of
Avalon to decide whether to promote logging and configuration as
lifecycle interface rather than components ... ;-)
In the service framework I had written (babel on sourceforge), I had
decided to implement them as component but I had a BaseLog and
BaseConfig classes which was used for all logging and configuration
related to the Component Manager itself (because it is possible it fails
before the logging service is initialized or if there is no logging
service registered - same for the configuration). However, in the
implementation, the logging and configuration components were actually
using the BaseXXX classes.
[snip]
-Vincent
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon and J2EE : Best practices
Posted by Jason van Zyl <jv...@zenplex.com>.
On 12/20/01 1:04 PM, "Vincent Massol" <vm...@octo.com> wrote:
> - In order to consistently do logging (with Log4J) and configuration
> (single system configuration file) in both J2EE component and Avalon
> components, we have done the following :
>
> * Created a Logger component,
> * Created a Configuration component (that uses properties file - I will
> submit it for Excalibur in beginning of January),
> * Defined an AbstractComponent class that is Composable, retrieve the
> Logger and Configuration components from the CM and offers 2 getters :
Simply as a point of interest, in the course of looking at using Avalon with
Turbine I did much the same in stratum (which is the refactoring of all the
tools that have grown in turbine, a turbine commons of sorts) in order to do
what need to do vis-à-vis logging and configuration.
> getLogger() and getConfiguration()
> * Our Avalon components extends AbstractComponent
> * We have a ComponentUtilities static class for other non EJB and non
> Avalon classes (during the migration phase and before all non EJB
> classes are components or attached to components) :
>
> public final static ComponentManager getComponentManager()
> {
> // Get CM from static variable
> return InitialisationEJB.manager;
> }
>
> public final static Component getComponent(String role)
> {
> final ComponentManager manager = getComponentManager();
> Component component;
> try
> {
> component = manager.lookup(role);
> }
> catch (ComponentException e)
> {
> throw new CriticalException("cannot get component for role [" +
> role + "]", e);
> }
>
> return component;
> }
>
> * We have defined a AbstractEnterpriseBean class that extends
> AbstractComponent. It contains empty EJB lifecycle methods that are
> common to session beans and entity beans. In the default constructor, we
> call :
>
> compose(ComponentUtilities.getComponentManager());
>
> * We also have a AbstractSessionBean and AbstractEntityBean classes that
> extend AbstractEnterpriseBean and simply add the empty EJB lifecycle
> methods related to Session beans and entity beans respectively.
> * We have a EJBUtilities class with static methods to get EJB home and
> bean reference (saved as static variables). We will probably move this
> class to be a single threaded Avalon component in the future.
>
> Thus we are able :
> - to use Avalon Components
> - to use standard java classes (to be migrated to components in the
> future or will act as helper classes of components)
> - to use EJBs
> - All 3 kinds can call each other with no problem
> - All 3 kind use a unified system configuration file
> - All 3 kind use a unified logging service (based on Log4j)
>
>> I think it would be very helpful if these
>> ideas could be integrated into Berin's "Developing with Avalon" at
> some
>> time. I'd gladly help doing it as soon as I've finished those two
>> projects I'm currently working on (that will be the beginning of
> March,
>> I think).
>>
>
> definitely. + a sample j2ee application that shows it all.
>
> -Vincent
>
>> On Sat, 10 Nov 2001 18:04:51 -0000 Vincent Massol wrote:
>>> 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 :
>>
>> <snip/>
>>
>>> What do you think ? Am I missing something ? As someone already done
>> this ?
>>
>> Cheers,
>> Jeremias Märki
>>
>> mailto:jeremias.maerki@outline.ch
>>
>> OUTLINE AG
>> Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
>> Fon +41 (41) 317 2020 - Fax +41 (41) 317 2029
>> Internet http://www.outline.ch
>>
>>
>> --
>> 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>
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon and J2EE : Best practices
Posted by Vincent Massol <vm...@octo.com>.
> -----Original Message-----
> From: Jeremias Maerki [mailto:jeremias.maerki@outline.ch]
> Sent: 20 December 2001 15:32
> To: Avalon Developers List
> Subject: Re: Avalon and J2EE : Best practices
>
> Hi Vincent
>
> Today, I've taken your collected thoughts and put them to use. They
were
> very clear and helpful and I'm quite pleased with the results. Well, I
> haven't done any direct EJB testing, yet. I've expected pitfalls but
> there weren't any until now.
Thanks Jeremias. We have made progress with our application and have now
completely integrated Avalon and J2EE and it works fine.
Here are some ideas (I will try to find some time later in January to
participate in a chapter on J2EE integration in "Developing With Avalon"
and to package a sample application showing it in real) :
- With WL 6.1, it is not possible to specify that a war should be
deployed before an EJB jar. Thus we had to move the initialization of
Excalibur CM to an EJB that we package in a separate EJB jar. Then, it
is possible with WL 6.1 to explicitely define the deployment order of
EJB jar. We save the CM as a static variable or this initialization EJB.
- In order to consistently do logging (with Log4J) and configuration
(single system configuration file) in both J2EE component and Avalon
components, we have done the following :
* Created a Logger component,
* Created a Configuration component (that uses properties file - I will
submit it for Excalibur in beginning of January),
* Defined an AbstractComponent class that is Composable, retrieve the
Logger and Configuration components from the CM and offers 2 getters :
getLogger() and getConfiguration()
* Our Avalon components extends AbstractComponent
* We have a ComponentUtilities static class for other non EJB and non
Avalon classes (during the migration phase and before all non EJB
classes are components or attached to components) :
public final static ComponentManager getComponentManager()
{
// Get CM from static variable
return InitialisationEJB.manager;
}
public final static Component getComponent(String role)
{
final ComponentManager manager = getComponentManager();
Component component;
try
{
component = manager.lookup(role);
}
catch (ComponentException e)
{
throw new CriticalException("cannot get component for role [" +
role + "]", e);
}
return component;
}
* We have defined a AbstractEnterpriseBean class that extends
AbstractComponent. It contains empty EJB lifecycle methods that are
common to session beans and entity beans. In the default constructor, we
call :
compose(ComponentUtilities.getComponentManager());
* We also have a AbstractSessionBean and AbstractEntityBean classes that
extend AbstractEnterpriseBean and simply add the empty EJB lifecycle
methods related to Session beans and entity beans respectively.
* We have a EJBUtilities class with static methods to get EJB home and
bean reference (saved as static variables). We will probably move this
class to be a single threaded Avalon component in the future.
Thus we are able :
- to use Avalon Components
- to use standard java classes (to be migrated to components in the
future or will act as helper classes of components)
- to use EJBs
- All 3 kinds can call each other with no problem
- All 3 kind use a unified system configuration file
- All 3 kind use a unified logging service (based on Log4j)
> I think it would be very helpful if these
> ideas could be integrated into Berin's "Developing with Avalon" at
some
> time. I'd gladly help doing it as soon as I've finished those two
> projects I'm currently working on (that will be the beginning of
March,
> I think).
>
definitely. + a sample j2ee application that shows it all.
-Vincent
> On Sat, 10 Nov 2001 18:04:51 -0000 Vincent Massol wrote:
> > 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 :
>
> <snip/>
>
> > What do you think ? Am I missing something ? As someone already done
> this ?
>
> Cheers,
> Jeremias Märki
>
> mailto:jeremias.maerki@outline.ch
>
> OUTLINE AG
> Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
> Fon +41 (41) 317 2020 - Fax +41 (41) 317 2029
> Internet http://www.outline.ch
>
>
> --
> 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: Avalon and J2EE : Best practices
Posted by Jeremias Maerki <je...@outline.ch>.
Hi Vincent
Today, I've taken your collected thoughts and put them to use. They were
very clear and helpful and I'm quite pleased with the results. Well, I
haven't done any direct EJB testing, yet. I've expected pitfalls but
there weren't any until now. I think it would be very helpful if these
ideas could be integrated into Berin's "Developing with Avalon" at some
time. I'd gladly help doing it as soon as I've finished those two
projects I'm currently working on (that will be the beginning of March,
I think).
On Sat, 10 Nov 2001 18:04:51 -0000 Vincent Massol wrote:
> 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 :
<snip/>
> What do you think ? Am I missing something ? As someone already done this ?
Cheers,
Jeremias Märki
mailto:jeremias.maerki@outline.ch
OUTLINE AG
Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
Fon +41 (41) 317 2020 - Fax +41 (41) 317 2029
Internet http://www.outline.ch
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon and J2EE : Best practices
Posted by Peter Donald <do...@apache.org>.
On Sun, 11 Nov 2001 21:05, Vincent Massol wrote:
> The most interesting part of Avalon for me is not the services but rather
> the fact that it uses best practice patterns and especially IOC. This is
> sooo important. Because on almost all my projects I have to mentor teams of
> developers who are very juniors and who 1/ have never programmed in java
> and 2/ have no experience with OOP/COP. Using Avalon gives them a
> documented framework that will force them to program properly.
>
> One of the big driver in favor of IOC for me is that it will lead to code
> that can easily be unit tested using Mock Objects (www.mockobjects.com)
> [and of course flexible and without to many dependencies - but that's why I
> can unit test it easily with mocks, i.e. isolate a portion of code from its
> domain (i.e. calling and caller classes)].
Hadn't thought of it in that way. You just convinced me that maybe I should
push to to have avalon/Framework adopted for our EJB stuff ;)
--
Cheers,
Pete
----------------------------------------
"Liberty means responsibility. That is
why most men dread it." - Locke
----------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon and J2EE : Best practices
Posted by Vincent Massol <vm...@octo.com>.
----- Original Message -----
From: "Peter Donald" <do...@apache.org>
To: "Avalon Developers List" <av...@jakarta.apache.org>
Sent: Sunday, November 11, 2001 1:40 AM
Subject: Re: Avalon and J2EE : Best practices
> On Sun, 11 Nov 2001 12:15, Vincent Massol wrote:
> > > Anyways I am only just getting into serious EJB work so ... ;)
> >
> > good ... do you plan to use avalon with j2ee ?
>
> With j2ee - yes. A lot of the stuff is already integrated with J2EE APIs.
In
> particular the Framework and Excalibur parts of Avalon is easily used in
> servlets and RMI/CLI/GUI/Other clients. It also works great as an endpoint
of
> JMS messages.
>
> However with EJBs I am not sure. Most of the EJB stuff I have being
playing
> with is relatively standard buisness orientated stuff. Essentially
> manipulation of databases and as such there has never been any demand for
any
> of the Avalon components (excepting Logging).
>
Well, I have been designing and implementing e-business solutions with
J2EE/EJB for the past 3 years and I can tell you that for each project I had
to rewrite the equivalent of Avalon/Excalibur. Probably the main reason was
that my favourite architecture (on the business tier) has been facade
stateless session beans around standard java data access classes (manager
class to manage life cycle of data objects and JDBC service for the
persistence). You also need a consistent way of configuring your application
(you must not use the ejb deployment descriptor as they only convey config
parameter for the ejbs and your application also has standard classes,
servlets, ....). In total here are the services I have used on all projects
:
- jdbc wrapper
- jndi wrapper
- configuration
- logging
- java-xml mapping
- jms wrapper (not on all projects)
I had to use them so frequently, I decided to create an open source project
so that we could have everyone in the company improve it and benefit from it
on all our projects. We also expected to have outside review and help. We
put that framework on sourceforge and called it Babel. It looks very similar
with Avalon/Excalibur (although not as complete). We have now decided to
stop it and use Avalon instead.
> However I suspect in the future where we are going to need some XML
> manipulation utilities that I will be using Avalon components from EJBs.
How
> it gets done I am not sure at this stage.
>
> --
> Cheers,
>
> Pete
>
> -------------------------------------------------
> We should take care not to make the intellect our
> god; it has, of course, powerful muscles, but no
> personality.
> -------------------------------------------------
>
> --
> 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: Avalon and J2EE : Best practices
Posted by Vincent Massol <vm...@octo.com>.
The most interesting part of Avalon for me is not the services but rather
the fact that it uses best practice patterns and especially IOC. This is
sooo important. Because on almost all my projects I have to mentor teams of
developers who are very juniors and who 1/ have never programmed in java and
2/ have no experience with OOP/COP. Using Avalon gives them a documented
framework that will force them to program properly.
One of the big driver in favor of IOC for me is that it will lead to code
that can easily be unit tested using Mock Objects (www.mockobjects.com) [and
of course flexible and without to many dependencies - but that's why I can
unit test it easily with mocks, i.e. isolate a portion of code from its
domain (i.e. calling and caller classes)].
-Vincent
----- Original Message -----
From: "Peter Donald" <do...@apache.org>
To: "Avalon Developers List" <av...@jakarta.apache.org>
Sent: Sunday, November 11, 2001 1:40 AM
Subject: Re: Avalon and J2EE : Best practices
> On Sun, 11 Nov 2001 12:15, Vincent Massol wrote:
> > > Anyways I am only just getting into serious EJB work so ... ;)
> >
> > good ... do you plan to use avalon with j2ee ?
>
> With j2ee - yes. A lot of the stuff is already integrated with J2EE APIs.
In
> particular the Framework and Excalibur parts of Avalon is easily used in
> servlets and RMI/CLI/GUI/Other clients. It also works great as an endpoint
of
> JMS messages.
>
> However with EJBs I am not sure. Most of the EJB stuff I have being
playing
> with is relatively standard buisness orientated stuff. Essentially
> manipulation of databases and as such there has never been any demand for
any
> of the Avalon components (excepting Logging).
>
> However I suspect in the future where we are going to need some XML
> manipulation utilities that I will be using Avalon components from EJBs.
How
> it gets done I am not sure at this stage.
>
> --
> Cheers,
>
> Pete
>
> -------------------------------------------------
> We should take care not to make the intellect our
> god; it has, of course, powerful muscles, but no
> personality.
> -------------------------------------------------
>
> --
> 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: Avalon and J2EE : Best practices
Posted by Peter Donald <do...@apache.org>.
On Sun, 11 Nov 2001 12:15, Vincent Massol wrote:
> > Anyways I am only just getting into serious EJB work so ... ;)
>
> good ... do you plan to use avalon with j2ee ?
With j2ee - yes. A lot of the stuff is already integrated with J2EE APIs. In
particular the Framework and Excalibur parts of Avalon is easily used in
servlets and RMI/CLI/GUI/Other clients. It also works great as an endpoint of
JMS messages.
However with EJBs I am not sure. Most of the EJB stuff I have being playing
with is relatively standard buisness orientated stuff. Essentially
manipulation of databases and as such there has never been any demand for any
of the Avalon components (excepting Logging).
However I suspect in the future where we are going to need some XML
manipulation utilities that I will be using Avalon components from EJBs. How
it gets done I am not sure at this stage.
--
Cheers,
Pete
-------------------------------------------------
We should take care not to make the intellect our
god; it has, of course, powerful muscles, but no
personality.
-------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon and J2EE : Best practices
Posted by Vincent Massol <vm...@octo.com>.
----- Original Message -----
From: "Peter Donald" <do...@apache.org>
To: "Avalon Developers List" <av...@jakarta.apache.org>
Sent: Sunday, November 11, 2001 1:07 AM
Subject: Re: Avalon and J2EE : Best practices
> Hi,
>
> Sounds good but I have a few questions.
>
> On Sun, 11 Nov 2001 05:04, Vincent Massol wrote:
> > * 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)
>
> Why use static/class members and not use instance variables. Instance
> variables should work I think and IIRC using static variables will make
your
> EJBs non-compliant and can be non-portable if you want to start doing some
of
> the more fancy clustering stuff.
I probably used the wrong word as I meant instance variable (I used class
variable to mean the same but I did not imagine them static). We agree here.
>
> > * 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.
>
> Im not sure this is ideal unless the EJB has large number of configurable
> options. I would hope/think that most containers have a simple graphical
> client where you can put config parameters into JNDI space. Would it be
> better to use that ? If there was large numbers of parameters then
probably
> not but if there is only a small number of parameters ?
>
2 things here :
- it depends on the application server and I can tell you it is very far
from being true. Most application server have a very basic read-only JNDI
tree (not persistent), so I you wish to save parameters in JNDI you have to
install a separate LDAP server.
- I would like to have the same configuration mechanism for all my classes
whether they are avalon components or EJB. It doesn't mean that the
configuration component will not retrieve its configuration parameters from
JNDI
> Anyways I am only just getting into serious EJB work so ... ;)
good ... do you plan to use avalon with j2ee ?
cheers,
-Vincent
>
> --
> Cheers,
>
> Pete
>
> -----------------------------------------------
> "You can't depend on your eyes when your
> imagination is out of focus." -Mark Twain
> -----------------------------------------------
>
> --
> 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: Avalon and J2EE : Best practices
Posted by Peter Donald <do...@apache.org>.
Hi,
Sounds good but I have a few questions.
On Sun, 11 Nov 2001 05:04, Vincent Massol wrote:
> * 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)
Why use static/class members and not use instance variables. Instance
variables should work I think and IIRC using static variables will make your
EJBs non-compliant and can be non-portable if you want to start doing some of
the more fancy clustering stuff.
> * 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.
Im not sure this is ideal unless the EJB has large number of configurable
options. I would hope/think that most containers have a simple graphical
client where you can put config parameters into JNDI space. Would it be
better to use that ? If there was large numbers of parameters then probably
not but if there is only a small number of parameters ?
Anyways I am only just getting into serious EJB work so ... ;)
--
Cheers,
Pete
-----------------------------------------------
"You can't depend on your eyes when your
imagination is out of focus." -Mark Twain
-----------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>