I wrote a small avalon compatible container called Pulga (15K). It handles
the avalon life cycle and provides an option to the dependency
injection strategy used by Avalon (Serviceable) using annotations. Example:
Instead of:
public void service(ServiceManager manager) {
MyComponent component = (MyComponent) manager.lookup(MyComponent.ROLE);
}
just use:
@Depedency
private MyComponent component
Of course, implementing Serviceable still works.
I dislike ECM/Fortress because they have lots of dependencies. Pulga has a
really small set of dependencies and works with conventions to simplify it's
configuration file. For example, if you component is:
interface: my.package.Component
implementation: my.package.impl.ComponentImpl
You don't even have to declare it in pulga.xml, which resembles roles.xmland
system.xconf.xml.
There are lots of other useful conventions too.
--
Leandro Rodrigo Saad Cruz
CTO - InterBusiness Technologies
db.apache.org/ojb
guara-framework.sf.net
xingu.sf.net
On 6/24/06, Peter Courcoux <[EMAIL PROTECTED]> wrote:
Hi Jurgen,
I just knew someone was going to ask that.
The recommended (Excalibur project) replacement is Fortress. I think it
builds a graph of component dependencies and starts them in the right
order. It also, I believe, doesn't do much, if any, playing with
classloaders. I think that these are the two areas which cause our
problems with ECM.
I have a Fortress 1.0 service which I wrote a while ago, but If I recall
correctly the meta data tools did not play nicely with Java 5 and
tagging some of the Fulcrum components was a nightmare because of how
they were structured. I think fulcrum security was the problem here.
It just seemed like too much work. Maybe the 1.1 release of Fortress
fixes the java 5 problem. If so it might be worth looking at.
YAAFI is worth looking at. I just don't know if it has been used in a
large complex application and if it handles these issues. I have been
meaning to look again at this for a long time but haven't got round to it.
I think the Coccon project had ECM problems and wrote an enhanced
container specifically for Cocoon. This might be worth investigating.
Overriding all this is the question of how much traction Avalon has and
is it worth the effort. The Avalon project basically self-destructed and
has fragmented. I don't know how big a community there is with Avalon
knowledge now.
I have been trying to avoid making a decision for as long as possible.
Personally, I think that the osgi framework looks like it has most
following, eclipse runs on the equinox osgi runtime and has the PDE
which provides support for developing osgi compliant bundles.
There is also Felix at the ASF and other implementations around. I think
I'm fed up with Avalon and would rather put extra effort to learn how to
use something like equinox. I think it is possible to convert Avalon
components to osgi bundles and there is a new embeddable osgi
implementation being worked on at the eclipse project at the current
time. I am watching this and will be experimenting with it shortly.
In short, I'm not sure that Avalon is worth the effort. Not for me
anyway. However, there are some options, both Avalon and non-avalon.
It really depends on who gets to it first and how they feel about it
all. :-)
Regards,
Peter
Jürgen Hoffmann wrote:
> Hi Peter,
>
> Am Samstag, 24. Juni 2006 21:48 schrieb Peter Courcoux:
>
>>Hi all,
>>
>>I agree that 2.4 is the way to go. I have several applications including
>>some fairly large ones using 2.4-m1 in production
>
>
> great to hear that, makes me move even faster :)
>
>
>>and the only thing I would really like to do is get rid of ECM as
>>the Avalon Services Container. There can be problems with this
>>with large complex multithreaded applications with lots of components.
>
>
> would you suggest to replace it wiht some other container? If yes which?
>
> Kind regards
>
> Juergen
--
------------------------------
Peter Courcoux
Telephone : +44 (0)1923 661488
Mobile : 07880 605626
email : [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
