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. 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? > 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]
