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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
