On 12/8/08, David Jencks <[EMAIL PROTECTED]> wrote: > > 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.
Yeh Having played around with them a little the subset, what I like about them is that they are a lightweight standard which can be used to replace the invasive Avalon interfaces. More modern containers would probably just use ignore them. > 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 intende sound good > 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. I'll take a look The good news is that we only need to support @Resource and @PostConstruct, and we can ignore most of the complex stuff since we don't need it. > >> >> >> 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. My plan was to make Phoenix support them as a means of migrating away from Avalon. They happen to do just what I needed. > Spring is working towards (partly) becoming an osgi standard -- RFC 124 I think James needs to move to OSGi but I think we need a migration path which allows the phoenix container to retained for a while. I have some ideas now about running OSGi in Phoenix but I need to bypass the Avalon lifecycle timing since I'm using a listener. > If you really like annotations you might look at googles guice, > although IIUC it has problems dealing with non-singleton components. Oh well Robert > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
