thx, for detailed infos
2006/9/24, Craig McClanahan <[EMAIL PROTECTED]>:
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
