> -----Original Message-----
> From: Paul Hammant [mailto:[EMAIL PROTECTED]]
> 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-
> [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]>
