FAQ
Are any of these class names or context params start w/ javax.faces ? If
so, we can move the conversation back into the issue tracker and I'll close
the @PostConstruct issue once Paul says it's good to go. I don't see the
point of the system property though.

Dennis Byrne
On 3/2/07, Mathias Brökelmann wrote:

The RI uses two ways to lookup the implementation of the vendor
specific implementation of the InjectionProvider. They first try to
use a web context init param and if that is not configured they simply
use a system property. Both keyed by the class name of the
InjectionProvider interface.

2007/3/2, Paul McMahan <paulmcmahan@gmail.com>:
I think Mathias' suggestion is right on. I haven't looked at the RI
code but I read somewhere that it passes the name of
InjectionProviders via entries in META-INF/services. If MyFaces used
a similar approach I think it should work OK for Geronimo and just
about any other container that supports injection, And it should also
make MyFaces more interchangeable with the RI.

Best wishes,
Paul
On 3/2/07, Dennis Byrne wrote:
Similar to what Mathias mentioned?

http://issues.apache.org/jira/browse/MYFACES-1246#action_12475337

It's not much work (on our side) but it sounds pretty vendor specific.
Again, I don't have a better solution. Mathias writes "which is
implemented
by j2ee containers". I wonder if each container will end up looking
for
different interfaces. How would MyFaces find Geronimo's
implementation ? A
context parameter? A for loop like this ...

String[] providers = new String[]{"org,apache.geronimo.DIProvider",
"com.bea.DIProvider", "org.jboss.DIProvider"}

for(String clazz : providers){
try{
return ClassUtils.load (clazz)
}catch(){}
}

Dennis Byrne

On 3/1/07, Paul McMahan wrote:
OK, I think your interpretation of the spec makes sense and there's
one particular aspect we should discuss a little further.

The container doesn't know which classes are managed beans so it
wouldn't know when to intercept the instantiation process to perform
injection. What would you all think about MyFaces providing an
interface that containers could implement to perform injection on a
managed bean when MyFaces brings that bean into service? This would
allow MyFaces to maintain control of the timing while allowing the
container to scan for annotations and handle injection when prompted
to do so.

Best wishes,
Paul

On 2/26/07, Dennis Byrne wrote:
I know the specs can be vague sometimes, but I don't interpret the
first
paragraph of section 5.4 as meaning the JSF implementation is
responsible
for @EJB, @Resources, etc. The JSF spec specifically mentions
"the
container to inject references". If Geronimo can intercept the
instantiation of these classes in the classloader (something I
know
nothing
about right now), I think we are all good here. Wouldn't MyFaces
then
be
observing the requirements (in plain java) around @PostConstruct
after
Geronimo had injected the resources?

I think the JSF impl is only responsible for @PostConstruct and
@Predestroy.
This makes sense because scoped (request, session, application)
are the
only candidates for this, and it would be more awkward to do that
from
the
container. I say all of this in an open manner, so anyone feel
free to
discuss.

You're point about javax.annotation being in the Servlet 2.5 is
taken.
I
totally missed that.


Dennis Byrne
On 2/26/07, Paul McMahan wrote:
Actually by "dependency injection" I'm specifically referring to
the
portion of the JSF spec that discusses injecting resources where
certain annotations are found in a managed bean. So, while
scanning
for the @PreConstruct and @PostDestroy annotations MyFaces would
also
scan for @EJB, @Resource, @WebServiceRef, etc and then time the
invocation of @PreConstruct and @PostDestroy to support the
injection.
Tomcat provides an example of how this can be done. The
following
class scans for annotations when a web app starts:
http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/WebAnnotationSet.java
And then this class handles the injection and calling the
PostConstruct and PreDestroy methods when an servlet, filter, or
listener is brought into service:
http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/java/org/apache/catalina/util/DefaultAnnotationProcessor.java
Would it make sense for MyFaces to follow a similar approach for
managed beans? Also, I'm curious why you're hoping to avoid
importing
classes from javax.annotation classes since servlet 2.5containers are
required to support them. Is this so that MyFaces 1.2 can
support
servlet 2.4 containers?

Best wishes,
Paul
On 2/26/07, Dennis Byrne wrote:
I ended up going with Servlet/Request/Context attribute
listeners
for
@PreDestroy. This did not involve importing
javax.annotation.PreDestroy, so
people w/out application servers don't have to worry about
ClassDefNotFoundErrors. This also keeps us compatible with
the
reference
implementation in terms of timing, although I really wish
they'd
change
the
wording in the spec.

Dennis Byrne

On 2/26/07, Paul McMahan wrote:
Sorry if I'm behind on this discussion but what are the
current
thoughts on how dependency injection will be implemented for
managed
beans? The reason I'm curious is because PreDestroy and
PostConstruct
annotations are used to deal with injected resources, so
from a
timing
perspective it would be important to process all these
annotations
accordingly.

Best wishes,
Paul
On 2/24/07, Dennis Byrne wrote:
I'm weighing options about invoking @PreDestroy methods
(@PostConstruct
is
done BTW). I haven't made up my mind yet but here's where
I'm
at on
this.
As far as *when* this happens, the request is easy, in
FacesServelet.service(). Session and app scope are more
difficult
decisions.
A new
HttpSessionActivationListener.attributeRemoved
and a
new
ServletContextAttributeListener.attributeRemoved ()
seem
like nice solutions, but this doesn't meet the spec
requirements
for
5.4.1.
The methods have to be invoked *before* the bean is pulled
from
scope
and
the servlet API does not provide a
ServletContextAttributeListener.attribute_WILL_BE_Removed()
or a
HttpSessionActivationListener.attribute_WILL_BE_Removed
().
Also, I say *new* ServletContextAttributeListener and
because
StartupServletContextListener (already in code base)
implements
ServletContextListener, not
ServletContextAttributeListener.

The other side of the problem is *how* to invoke each
@PreDestroy
method,
much easier. Iterating over the attributes at each scope
level
is
trivial,
and so is determining if the bean's class is a managed
bean
class.
But
this
does not mean the *instance* was placed there by the JSF
implementation.
Using a list (at each level of scope) to track managed
instances
solves
the
problem, as long as you sync on the session (only one time
per
session)
in
order to avoid concurrency issues; it also means three
more data
structures
in memory.

--
Dennis Byrne


--
Dennis Byrne


--
Dennis Byrne


--
Dennis Byrne

--
Mathias


--
Dennis Byrne

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 10 of 33 | next ›
Discussion Overview
groupdev @
categoriesmyfaces
postedFeb 24, '07 at 6:31p
activeMar 12, '07 at 3:53p
posts33
users7
websitemyfaces.apache.org

People

Translate

site design / logo © 2019 Grokbase