On Dec 8, 2008, at 10:52 AM, Stefano Bagnara wrote:
Robert Burrell Donkin ha scritto:
my starting point was JSR 250 (Common Annotations for the Java
Platform) which is used to control service injection in ejb3. i
hadn't
really studied in detail before but i took a better look and liked
what i saw. they're lightweight and not too strongly coupled to the
ejb model. it has the advantage of being a standard that plays well
with other containers.
[...]
opinions? etc
jsr250: it's a small java5 api jar. I don't know what containers
supports out of the box this api, today. A fast search didn't give me
results.
javaee 5 compliant servers support this for ee components, such as
ejb, servlet, jsp taglib beans, and jsf beans. I sincerely doubt you
will find anything supporting this for non-ee components, although
it's possible spring has some support for this stuff in a non-ee
context.
geronimo and openejb use the (geronimo subproject) xbean libraries to
implement support for this. xbean does all the hard work for you but
you need to write a bunch of code to call the xbean libraries and
relate the annotations to the intended targets.
basically you need to scan the code for annotations and track all of
them and figure out what they are trying to refer to. xbean-finder is
good for this.
Then whenever you create a managed object you need to deal with
injecting the values for the annotated stuff. xbean-reflect is good
for this.
If no container supports it then it is a simple way to "mark"
dependency
injection (as an alternative to doclets / xml configurations /
enabling
interfaces / naming conventions), right?
Marking stuff doesn't do you any good if there is no container
supporting the markings.
Spring is working towards (partly) becoming an osgi standard -- RFC 124
If you really like annotations you might look at googles guice,
although IIUC it has problems dealing with non-singleton components.
thanks
david jencks
the avalon service manager could be used but has the limitation that
every resource has to be a block provided to James. this is the heart
of my issues so i'd like to avoid this. phoenix supports application
listeners so that can be used to collect every block and make them
all
available by name to each mailet. that, i like: it's a lot less work.
this approach runs into a few problems with lifecycle order - events
are generated after service and initialization but that's ok: the
same
trick can be used to replace the avalon service and initialization
interfaces. the listener can then init everything once every service
has been loaded from the assembly.xml. for example
I guess your always talking of the *phoenix* service manager (avalon
service manager is simple and has not knowledge of "blocks").
About phoenix application listeners, I never used it, but if you think
they can be used to build our own "dependency injecting spoolmanager"
let's see a POC! it seems interesting to gradually move away from
phoenix schemas.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
