On 9/24/06, stephan opitz <[EMAIL PROTECTED]> wrote:
as i read http://www.diotalevi.com/weblog/?p=129 during my study of dependency injection with ejb i had the idea to support dependency injection with help of the tiger annotations. as in article written, dependency injection does not work "from house" in the model objects of jsf/shale.
Technically, this happens because the Tiger Extensions bypasses the normal bean creation process, and creates the bean itself. This has the side effect of bypassing container provided injections, because the container didn't create the bean. there was an author called gavin king who meant that it is easy to
implement. so if maybe set a flag in web.xml, that actual a java ee 5 server environment is given and maybe dependency injection of ejbs with tiger, could be made possible.
I'm not sure I would classify this as "easy", but some subset of what the app server can do for you seems like it would be "possible". There are a number types of annotations that could theoretically be supported in this manner, in roughly increasing order of difficulty: * "Common Annotations" things from JSR-250 (like @PostConstruct and @PreDestroy). * Java Persistence Architecture things from JSR-220 (@PersistenceContext and friends). * Resource injection (@Resource and @EJB). I'm not sure that the last one can be done without using app server internal APIs, but the first two should definitely be feasible. also the idea of dependency injection could used in other parts of the
framework...
If you mean, usable in non-managed-beans, I don't think that is ever going to be possible. Consider what has to happen for injection to work. Shale would have to intercept the creation of any arbitrary Java object, including things like: Foo foo = new Foo(); But the Java language doesn't support any mechanism to intercept this kind of thing. The best a framework can do is say "we'll support injection when you use this particular object creation factory approach" -- Java EE 5 covers all the cases (including JSF managed beans) where the app server provides objects for you, but that's about as far as an app server will ever be able to go. In the 1.0.3 version of Shale, I switched to using managed beans for just about all of the pieces of Shale that can be replaced by the user (such as the mapping from a view id to a managed bean name). That means (among other thigns) that if you use the managed bean facility to create those beans in the first place, you can leverage the injection capabilities. the power of shale tiger annotations, maybe should be extend. ok
annotations are only supported since java 5., but will be the future of development?! whats your ideas?
If the Shale community were willing to buy in to requiring Java SE 5 as a base JDK, I'd switch everything over in a shot. Besides the annotation capabilities, the language syntax improvements are really nice. Both would be huge helps to creating a very elegant application framework. If that doesn't happen right away, I still see a minimum requirement for SE5 at some point in the future, and annotation based configuration for many things as the default approach (there are things I don't think should be configured that way, but that's a different subject :-). stephan
Craig
