Re: [jira] @PreDestroy, Servlet API,
This thread seems to have died down. I've tried to start a new thread on a related proposal I've come up with while thinking about how to integrate MyFaces into geronimo, the subject is Proposal for annotation processing and there's a related jira issue https://issues.apache.org/jira/browse/MYFACES-1559 It's possibly my mail is messed up so I may have to repost the proposal as a reply to this message. many thanks david jencks Bernd Bohmann wrote: What is wrong with http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/java/org/apache/catalina/util/DefaultAnnotationProcessor.java ? big snip -- View this message in context: http://www.nabble.com/%40PreDestroy%2C-Servlet-API%2C-tf3284592.html#a9437097 Sent from the My Faces - Dev mailing list archive at Nabble.com.
Re: @PreDestroy, Servlet API,
Hello Dennis,
why we should look at the RI?
Can we use this Interface
http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/AnnotationProcessor.html?
Why you don't like to import javax.annotation. in the code. If the
annotation are missing in the container the annotations in the managed
bean would be meaningless. But maybe the annotation are required by the
servlet spec.
Why you create a own class for each Listener?
Regards
Bernd
Dennis Byrne wrote:
As much as I agree w/ you about how better things would be if this were in
the spec, and as much as I hate to bow down here, I am actually OK with
using com.sun.faces.spi.InjectionProvider as the parameter in MyFaces as
well ... for the sake of users. If anyone has a problem w/ it, we can go
with org.apache.myfaces.InjectionProvider.
Dennis Byrne
On 3/2/07, Mathias Brökelmann [EMAIL PROTECTED] wrote:
The RI looks for com.sun.faces.spi.InjectionProvider for a class
name which implements this interface. It would have been very nice if
this is part of the spec. But that is not the case so we need to find
a way to support any kind of j2ee container. IMO injecting j2ee
resources without knowing where these resources can be found is not
possible. Therefore myfaces should call an InjectionProvider which
simply do this job.
2007/3/3, Dennis Byrne [EMAIL PROTECTED]:
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]:
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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,
Re: @PreDestroy, Servlet API,
On 3/3/07, Bernd Bohmann [EMAIL PROTECTED] wrote:
Hello Dennis,
why we should look at the RI?
I'd prefer doing things that is compatible with them. This is easier on the
users and it makes passing TCK smoother.
Can we use this Interface
http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/AnnotationProcessor.html
?
I'd prefer something that would work on other Servlet containers. I am open
to ideas.
Why you don't like to import javax.annotation. in the code. If the
annotation are missing in the container the annotations in the managed
bean would be meaningless. But maybe the annotation are required by the
servlet spec.
I didn't do this for users who were using @PostConstruct in their managed
beans, I did this to avoid ClassDefNotFoundErrors for users who *didn't* use
@PostConstruct. However Paul has already pointed out in this thread that
this is not realistic, since Servlet 2.5 requires these annotations.
Why you create a own class for each Listener?
Regards
Bernd
Dennis Byrne wrote:
As much as I agree w/ you about how better things would be if this were
in
the spec, and as much as I hate to bow down here, I am actually OK
with
using com.sun.faces.spi.InjectionProvider as the parameter in MyFaces as
well ... for the sake of users. If anyone has a problem w/ it, we can
go
with org.apache.myfaces.InjectionProvider.
Dennis Byrne
On 3/2/07, Mathias Brökelmann [EMAIL PROTECTED] wrote:
The RI looks for com.sun.faces.spi.InjectionProvider for a class
name which implements this interface. It would have been very nice if
this is part of the spec. But that is not the case so we need to find
a way to support any kind of j2ee container. IMO injecting j2ee
resources without knowing where these resources can be found is not
possible. Therefore myfaces should call an InjectionProvider which
simply do this job.
2007/3/3, Dennis Byrne [EMAIL PROTECTED]:
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]:
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
Re: @PreDestroy, Servlet API,
Hello Dennis, I think the interface has nothing to do with tomcat. Would the interface meet your requirements? If yes, I would suggest following: Create a AnnotationProcessorFactory which return as default an AnnotationProcessor who is a copy of the tomcat DefaultAnnotationProcessor(the code has no dependency to other tomcat code). I think the factory should return a suitable AnnotationProcessor based on which Annotations are present in the classpath. Maybe we can make the AnnotationProcessor configurable. If you like I would add this code to 1.2. Regards Bernd
Re: @PreDestroy, Servlet API,
OK, I think the RI also recently added the META-INF/services
technique. But I don't know how reliable this sun blog entry is:
http://tinyurl.com/yrrjs2
Best wishes,
Paul
On 3/2/07, Mathias Brökelmann [EMAIL PROTECTED] 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 [EMAIL PROTECTED]:
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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.5 containers 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 [EMAIL PROTECTED]
Re: @PreDestroy, Servlet API,
I added a comment
http://blogs.sun.com/rlubke/entry/jsf_ri_1_2_and#comment-1172947192023 .
Two more ideas. Ryan mentions applications using facelets, jsf 1.2 and
servlet 2.4. Unless I'm missing something, there's one reason to use
annotation.getName().equals(javax.annotation.PostConstruct) rather than
annotation.class == PostConstruct.class. Also, the tomcat guys are
processing annotations even when the method is marked private.
Dennis Byrne
On 3/3/07, Paul McMahan [EMAIL PROTECTED] wrote:
OK, I think the RI also recently added the META-INF/services
technique. But I don't know how reliable this sun blog entry is:
http://tinyurl.com/yrrjs2
Best wishes,
Paul
On 3/2/07, Mathias Brökelmann [EMAIL PROTECTED] 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 [EMAIL PROTECTED]:
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
Re: @PreDestroy, Servlet API,
Just added an implementation of the annotation handling based on the
tomcat implementation.
Bernd
Dennis Byrne wrote:
I added a comment
http://blogs.sun.com/rlubke/entry/jsf_ri_1_2_and#comment-1172947192023 .
Two more ideas. Ryan mentions applications using facelets, jsf 1.2 and
servlet 2.4. Unless I'm missing something, there's one reason to use
annotation.getName().equals(javax.annotation.PostConstruct) rather than
annotation.class == PostConstruct.class. Also, the tomcat guys are
processing annotations even when the method is marked private.
Dennis Byrne
On 3/3/07, Paul McMahan [EMAIL PROTECTED] wrote:
OK, I think the RI also recently added the META-INF/services
technique. But I don't know how reliable this sun blog entry is:
http://tinyurl.com/yrrjs2
Best wishes,
Paul
On 3/2/07, Mathias Brökelmann [EMAIL PROTECTED] 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 [EMAIL PROTECTED]:
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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:
Re: @PreDestroy, Servlet API,
Are you under the impression that our 1.2 branch didn't already handle
@PostConstruct and @PreDestroy? Looks like the left hand doesn't know what
the right hand is doing here.
Dennis Byrne
On 3/3/07, Bernd Bohmann [EMAIL PROTECTED] wrote:
Just added an implementation of the annotation handling based on the
tomcat implementation.
Bernd
Dennis Byrne wrote:
I added a comment
http://blogs.sun.com/rlubke/entry/jsf_ri_1_2_and#comment-1172947192023 .
Two more ideas. Ryan mentions applications using facelets, jsf 1.2 and
servlet 2.4. Unless I'm missing something, there's one reason to use
annotation.getName().equals(javax.annotation.PostConstruct) rather
than
annotation.class == PostConstruct.class. Also, the tomcat guys are
processing annotations even when the method is marked private.
Dennis Byrne
On 3/3/07, Paul McMahan [EMAIL PROTECTED] wrote:
OK, I think the RI also recently added the META-INF/services
technique. But I don't know how reliable this sun blog entry is:
http://tinyurl.com/yrrjs2
Best wishes,
Paul
On 3/2/07, Mathias Brökelmann [EMAIL PROTECTED] 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 [EMAIL PROTECTED]:
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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.5is
taken.
I
totally missed that.
Dennis Byrne
On 2/26/07, Paul McMahan [EMAIL PROTECTED] 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,
Re: @PreDestroy, Servlet API,
??? Yes, I know it.
Dennis Byrne wrote:
Are you under the impression that our 1.2 branch didn't already handle
@PostConstruct and @PreDestroy? Looks like the left hand doesn't know what
the right hand is doing here.
Dennis Byrne
On 3/3/07, Bernd Bohmann [EMAIL PROTECTED] wrote:
Just added an implementation of the annotation handling based on the
tomcat implementation.
Bernd
Dennis Byrne wrote:
I added a comment
http://blogs.sun.com/rlubke/entry/jsf_ri_1_2_and#comment-1172947192023 .
Two more ideas. Ryan mentions applications using facelets, jsf 1.2 and
servlet 2.4. Unless I'm missing something, there's one reason to use
annotation.getName().equals(javax.annotation.PostConstruct) rather
than
annotation.class == PostConstruct.class. Also, the tomcat guys are
processing annotations even when the method is marked private.
Dennis Byrne
On 3/3/07, Paul McMahan [EMAIL PROTECTED] wrote:
OK, I think the RI also recently added the META-INF/services
technique. But I don't know how reliable this sun blog entry is:
http://tinyurl.com/yrrjs2
Best wishes,
Paul
On 3/2/07, Mathias Brökelmann [EMAIL PROTECTED] 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 [EMAIL PROTECTED]:
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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.5is
taken.
I
totally missed that.
Dennis Byrne
On 2/26/07, Paul McMahan [EMAIL PROTECTED] 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
Re: @PreDestroy, Servlet API,
Mathias, me and Paul were discussing the future of this feature. For the
most part we were in agreement. I appreciate your input, but it did not
gain traction w/ anyone. You then went ahead and committed a bunch of code.
IMO, you have not been a good team member today Bernd. Please assign the
issue to yourself.
Thank you very much for your interest in getting us closer to a
1.2implementation.
Dennis Byrne
On 3/3/07, Bernd Bohmann [EMAIL PROTECTED] wrote:
??? Yes, I know it.
Dennis Byrne wrote:
Are you under the impression that our 1.2 branch didn't already handle
@PostConstruct and @PreDestroy? Looks like the left hand doesn't know
what
the right hand is doing here.
Dennis Byrne
On 3/3/07, Bernd Bohmann [EMAIL PROTECTED] wrote:
Just added an implementation of the annotation handling based on the
tomcat implementation.
Bernd
Dennis Byrne wrote:
I added a comment
http://blogs.sun.com/rlubke/entry/jsf_ri_1_2_and#comment-1172947192023.
Two more ideas. Ryan mentions applications using facelets, jsf 1.2and
servlet 2.4. Unless I'm missing something, there's one reason to use
annotation.getName().equals(javax.annotation.PostConstruct) rather
than
annotation.class == PostConstruct.class. Also, the tomcat guys are
processing annotations even when the method is marked private.
Dennis Byrne
On 3/3/07, Paul McMahan [EMAIL PROTECTED] wrote:
OK, I think the RI also recently added the META-INF/services
technique. But I don't know how reliable this sun blog entry is:
http://tinyurl.com/yrrjs2
Best wishes,
Paul
On 3/2/07, Mathias Brökelmann [EMAIL PROTECTED] 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 [EMAIL PROTECTED]:
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
Re: @PreDestroy, Servlet API,
Sorry,
I ask you if it's ok to add the code.
I get no answer then I asume it's ok to add my idea.
It's only a different possible implementation.
If you don't like it you can remove it.
Is anything wrong with the code?
Bernd
Dennis Byrne wrote:
Mathias, me and Paul were discussing the future of this feature. For the
most part we were in agreement. I appreciate your input, but it did not
gain traction w/ anyone. You then went ahead and committed a bunch of
code.
IMO, you have not been a good team member today Bernd. Please assign the
issue to yourself.
Thank you very much for your interest in getting us closer to a
1.2implementation.
Dennis Byrne
On 3/3/07, Bernd Bohmann [EMAIL PROTECTED] wrote:
??? Yes, I know it.
Dennis Byrne wrote:
Are you under the impression that our 1.2 branch didn't already handle
@PostConstruct and @PreDestroy? Looks like the left hand doesn't know
what
the right hand is doing here.
Dennis Byrne
On 3/3/07, Bernd Bohmann [EMAIL PROTECTED] wrote:
Just added an implementation of the annotation handling based on the
tomcat implementation.
Bernd
Dennis Byrne wrote:
I added a comment
http://blogs.sun.com/rlubke/entry/jsf_ri_1_2_and#comment-1172947192023.
Two more ideas. Ryan mentions applications using facelets, jsf
1.2and
servlet 2.4. Unless I'm missing something, there's one reason to
use
annotation.getName().equals(javax.annotation.PostConstruct) rather
than
annotation.class == PostConstruct.class. Also, the tomcat guys are
processing annotations even when the method is marked private.
Dennis Byrne
On 3/3/07, Paul McMahan [EMAIL PROTECTED] wrote:
OK, I think the RI also recently added the META-INF/services
technique. But I don't know how reliable this sun blog entry is:
http://tinyurl.com/yrrjs2
Best wishes,
Paul
On 3/2/07, Mathias Brökelmann [EMAIL PROTECTED] 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 [EMAIL PROTECTED]:
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
Re: @PreDestroy, Servlet API,
Just revert my commit
Dennis Byrne wrote:
Mathias, me and Paul were discussing the future of this feature. For the
most part we were in agreement. I appreciate your input, but it did not
gain traction w/ anyone. You then went ahead and committed a bunch of
code.
IMO, you have not been a good team member today Bernd. Please assign the
issue to yourself.
Thank you very much for your interest in getting us closer to a
1.2implementation.
Dennis Byrne
On 3/3/07, Bernd Bohmann [EMAIL PROTECTED] wrote:
??? Yes, I know it.
Dennis Byrne wrote:
Are you under the impression that our 1.2 branch didn't already handle
@PostConstruct and @PreDestroy? Looks like the left hand doesn't know
what
the right hand is doing here.
Dennis Byrne
On 3/3/07, Bernd Bohmann [EMAIL PROTECTED] wrote:
Just added an implementation of the annotation handling based on the
tomcat implementation.
Bernd
Dennis Byrne wrote:
I added a comment
http://blogs.sun.com/rlubke/entry/jsf_ri_1_2_and#comment-1172947192023.
Two more ideas. Ryan mentions applications using facelets, jsf
1.2and
servlet 2.4. Unless I'm missing something, there's one reason to
use
annotation.getName().equals(javax.annotation.PostConstruct) rather
than
annotation.class == PostConstruct.class. Also, the tomcat guys are
processing annotations even when the method is marked private.
Dennis Byrne
On 3/3/07, Paul McMahan [EMAIL PROTECTED] wrote:
OK, I think the RI also recently added the META-INF/services
technique. But I don't know how reliable this sun blog entry is:
http://tinyurl.com/yrrjs2
Best wishes,
Paul
On 3/2/07, Mathias Brökelmann [EMAIL PROTECTED] 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 [EMAIL PROTECTED]:
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
Re: @PreDestroy, Servlet API,
No code in myfaces (or any other apache project) is owned by someone.
That is important for a healthy and moving community. Bernds
submission was a little bit fast but sometimes a complex issue is
better understand if we can look at the code - no matter if that is
the solution we finally have.
I wasn't aware that tomcat already has something like an
AnnotationProcessor which defines exactly that kind of
InjectionProvider which the RI uses. But it perfectly matches our
requirements.
How about this solution:
We define a myfaces specific interface of an
AnnotationProcessor/InjectionProvider which will be used throughout
the code in myfaces. The initialization code lookups an implementation
for that interface. If there is nothing found (through context param,
META-INF/service, etc.) we implement some fallback strategies to
either looking for a InjectionProvider implementation for suns RI or
if that also fails we try to lookup container specific implementations
like tomcats AnnotationProcessor implementation. If all fails we
supply a default implementation which only handles @PostConstruct and
@PreDestroy annotations - I don't think that it is possible to inject
any resource w/o knowing how to lookup these.
2007/3/3, Bernd Bohmann [EMAIL PROTECTED]:
Sorry,
I ask you if it's ok to add the code.
I get no answer then I asume it's ok to add my idea.
It's only a different possible implementation.
If you don't like it you can remove it.
Is anything wrong with the code?
Bernd
Dennis Byrne wrote:
Mathias, me and Paul were discussing the future of this feature. For the
most part we were in agreement. I appreciate your input, but it did not
gain traction w/ anyone. You then went ahead and committed a bunch of
code.
IMO, you have not been a good team member today Bernd. Please assign the
issue to yourself.
Thank you very much for your interest in getting us closer to a
1.2implementation.
Dennis Byrne
On 3/3/07, Bernd Bohmann [EMAIL PROTECTED] wrote:
??? Yes, I know it.
Dennis Byrne wrote:
Are you under the impression that our 1.2 branch didn't already handle
@PostConstruct and @PreDestroy? Looks like the left hand doesn't know
what
the right hand is doing here.
Dennis Byrne
On 3/3/07, Bernd Bohmann [EMAIL PROTECTED] wrote:
Just added an implementation of the annotation handling based on the
tomcat implementation.
Bernd
Dennis Byrne wrote:
I added a comment
http://blogs.sun.com/rlubke/entry/jsf_ri_1_2_and#comment-1172947192023.
Two more ideas. Ryan mentions applications using facelets, jsf
1.2and
servlet 2.4. Unless I'm missing something, there's one reason to
use
annotation.getName().equals(javax.annotation.PostConstruct) rather
than
annotation.class == PostConstruct.class. Also, the tomcat guys are
processing annotations even when the method is marked private.
Dennis Byrne
On 3/3/07, Paul McMahan [EMAIL PROTECTED] wrote:
OK, I think the RI also recently added the META-INF/services
technique. But I don't know how reliable this sun blog entry is:
http://tinyurl.com/yrrjs2
Best wishes,
Paul
On 3/2/07, Mathias Brökelmann [EMAIL PROTECTED] 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 [EMAIL PROTECTED]:
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote:
OK, I think your
Re: @PreDestroy, Servlet API,
I don't hold anything against you. Ultimately I feel like this is a
lose-lose situation for MyFaces because where things stand now, you are
likely to feel as though your efforts on that branch are not appreciated.
They are.
Ryan has responded ...
http://blogs.sun.com/rlubke/entry/jsf_ri_1_2_and#comment-1172947192000
Dennis Byrne
On 3/3/07, Bernd Bohmann [EMAIL PROTECTED] wrote:
Sorry,
I ask you if it's ok to add the code.
I get no answer then I asume it's ok to add my idea.
It's only a different possible implementation.
If you don't like it you can remove it.
Is anything wrong with the code?
Bernd
Dennis Byrne wrote:
Mathias, me and Paul were discussing the future of this feature. For
the
most part we were in agreement. I appreciate your input, but it did not
gain traction w/ anyone. You then went ahead and committed a bunch of
code.
IMO, you have not been a good team member today Bernd. Please assign
the
issue to yourself.
Thank you very much for your interest in getting us closer to a
1.2implementation.
Dennis Byrne
On 3/3/07, Bernd Bohmann [EMAIL PROTECTED] wrote:
??? Yes, I know it.
Dennis Byrne wrote:
Are you under the impression that our 1.2 branch didn't already
handle
@PostConstruct and @PreDestroy? Looks like the left hand doesn't
know
what
the right hand is doing here.
Dennis Byrne
On 3/3/07, Bernd Bohmann [EMAIL PROTECTED] wrote:
Just added an implementation of the annotation handling based on the
tomcat implementation.
Bernd
Dennis Byrne wrote:
I added a comment
http://blogs.sun.com/rlubke/entry/jsf_ri_1_2_and#comment-1172947192023.
Two more ideas. Ryan mentions applications using facelets, jsf
1.2and
servlet 2.4. Unless I'm missing something, there's one reason to
use
annotation.getName().equals(javax.annotation.PostConstruct)
rather
than
annotation.class == PostConstruct.class. Also, the tomcat guys
are
processing annotations even when the method is marked private.
Dennis Byrne
On 3/3/07, Paul McMahan [EMAIL PROTECTED] wrote:
OK, I think the RI also recently added the META-INF/services
technique. But I don't know how reliable this sun blog entry is:
http://tinyurl.com/yrrjs2
Best wishes,
Paul
On 3/2/07, Mathias Brökelmann [EMAIL PROTECTED]
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 [EMAIL PROTECTED]:
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote:
I know the specs can be vague sometimes, but I don't
interpret
the first
Re: @PreDestroy, Servlet API,
On 3/3/07, Mathias Brökelmann [EMAIL PROTECTED] wrote: No code in myfaces (or any other apache project) is owned by someone. That is important for a healthy and moving community. Bernds submission was a little bit fast but sometimes a complex issue is better understand if we can look at the code - no matter if that is the solution we finally have. I hope you did not get the idea that this was about territory here. How about this solution: We define a myfaces specific interface of an AnnotationProcessor/InjectionProvider which will be used throughout the code in myfaces. The initialization code lookups an implementation for that interface. If there is nothing found (through context param, META-INF/service, etc.) we implement some fallback strategies to either looking for a InjectionProvider implementation for suns RI or if that also fails we try to lookup container specific implementations like tomcats AnnotationProcessor implementation. If all fails we supply a default implementation which only handles @PostConstruct and @PreDestroy annotations - I don't think that it is possible to inject any resource w/o knowing how to lookup these. This sounds very similar to what Ryan just talked about in his blog. Bernd, if are happy w/ this and still interested, feel free to go forward with this. If you still want to, I ask that the default implementation uses the annotation name, rather than the annotation. This gives Tomcat 5.5/Facelets users fewer headaches. Do either of you have a problem w/ the context listener doing a classpath search for well known injection providers? I meet a lot of devs who find JSF too configuration heavy. Bernd if you don't get around to doing this, I will just end up doing it sometime next week. 2007/3/3, Bernd Bohmann [EMAIL PROTECTED]: Sorry, I ask you if it's ok to add the code. I get no answer then I asume it's ok to add my idea. It's only a different possible implementation. If you don't like it you can remove it. Is anything wrong with the code? Bernd Dennis Byrne wrote: Mathias, me and Paul were discussing the future of this feature. For the most part we were in agreement. I appreciate your input, but it did not gain traction w/ anyone. You then went ahead and committed a bunch of code. IMO, you have not been a good team member today Bernd. Please assign the issue to yourself. Thank you very much for your interest in getting us closer to a 1.2implementation. Dennis Byrne On 3/3/07, Bernd Bohmann [EMAIL PROTECTED] wrote: ??? Yes, I know it. Dennis Byrne wrote: Are you under the impression that our 1.2 branch didn't already handle @PostConstruct and @PreDestroy? Looks like the left hand doesn't know what the right hand is doing here. Dennis Byrne On 3/3/07, Bernd Bohmann [EMAIL PROTECTED] wrote: Just added an implementation of the annotation handling based on the tomcat implementation. Bernd Dennis Byrne wrote: I added a comment http://blogs.sun.com/rlubke/entry/jsf_ri_1_2_and#comment-1172947192023. Two more ideas. Ryan mentions applications using facelets, jsf 1.2and servlet 2.4. Unless I'm missing something, there's one reason to use annotation.getName().equals(javax.annotation.PostConstruct) rather than annotation.class == PostConstruct.class. Also, the tomcat guys are processing annotations even when the method is marked private. Dennis Byrne On 3/3/07, Paul McMahan [EMAIL PROTECTED] wrote: OK, I think the RI also recently added the META-INF/services technique. But I don't know how reliable this sun blog entry is: http://tinyurl.com/yrrjs2 Best wishes, Paul On 3/2/07, Mathias Brökelmann [EMAIL PROTECTED] 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 [EMAIL PROTECTED]: 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 [EMAIL PROTECTED] 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
Re: @PreDestroy, Servlet API,
Hello Dennis, should i readd the other possible implementation? :-) But I should write my own TestCases. I think it should be possible to use the PostConstruct and PreDestroy Annotations with tomcat 5.5 and facelets. When a InitialContext is available we should try resource injection, too. But it should be possible to add a own Provider for a container. The AnnotationProcessor/InjectionProvider are very similar. I don't like to define a new myfaces Interface for this use case. I would prefer the org.apache.AnnotationProcessor because is not tomcat specific and an apache implementation. Until we find a final solution we should only copy the code. It's no problem to use the annotation name instead of using the class. But personal i prefer the class. Regards Bernd Dennis Byrne wrote: On 3/3/07, Mathias Brökelmann [EMAIL PROTECTED] wrote: No code in myfaces (or any other apache project) is owned by someone. That is important for a healthy and moving community. Bernds submission was a little bit fast but sometimes a complex issue is better understand if we can look at the code - no matter if that is the solution we finally have. I hope you did not get the idea that this was about territory here. How about this solution: We define a myfaces specific interface of an AnnotationProcessor/InjectionProvider which will be used throughout the code in myfaces. The initialization code lookups an implementation for that interface. If there is nothing found (through context param, META-INF/service, etc.) we implement some fallback strategies to either looking for a InjectionProvider implementation for suns RI or if that also fails we try to lookup container specific implementations like tomcats AnnotationProcessor implementation. If all fails we supply a default implementation which only handles @PostConstruct and @PreDestroy annotations - I don't think that it is possible to inject any resource w/o knowing how to lookup these. This sounds very similar to what Ryan just talked about in his blog. Bernd, if are happy w/ this and still interested, feel free to go forward with this. If you still want to, I ask that the default implementation uses the annotation name, rather than the annotation. This gives Tomcat 5.5/Facelets users fewer headaches. Do either of you have a problem w/ the context listener doing a classpath search for well known injection providers? I meet a lot of devs who find JSF too configuration heavy. Bernd if you don't get around to doing this, I will just end up doing it sometime next week. 2007/3/3, Bernd Bohmann [EMAIL PROTECTED]: Sorry, I ask you if it's ok to add the code. I get no answer then I asume it's ok to add my idea. It's only a different possible implementation. If you don't like it you can remove it. Is anything wrong with the code? Bernd Dennis Byrne wrote: Mathias, me and Paul were discussing the future of this feature. For the most part we were in agreement. I appreciate your input, but it did not gain traction w/ anyone. You then went ahead and committed a bunch of code. IMO, you have not been a good team member today Bernd. Please assign the issue to yourself. Thank you very much for your interest in getting us closer to a 1.2implementation. Dennis Byrne On 3/3/07, Bernd Bohmann [EMAIL PROTECTED] wrote: ??? Yes, I know it. Dennis Byrne wrote: Are you under the impression that our 1.2 branch didn't already handle @PostConstruct and @PreDestroy? Looks like the left hand doesn't know what the right hand is doing here. Dennis Byrne On 3/3/07, Bernd Bohmann [EMAIL PROTECTED] wrote: Just added an implementation of the annotation handling based on the tomcat implementation. Bernd Dennis Byrne wrote: I added a comment http://blogs.sun.com/rlubke/entry/jsf_ri_1_2_and#comment-1172947192023. Two more ideas. Ryan mentions applications using facelets, jsf 1.2and servlet 2.4. Unless I'm missing something, there's one reason to use annotation.getName().equals(javax.annotation.PostConstruct) rather than annotation.class == PostConstruct.class. Also, the tomcat guys are processing annotations even when the method is marked private. Dennis Byrne On 3/3/07, Paul McMahan [EMAIL PROTECTED] wrote: OK, I think the RI also recently added the META-INF/services technique. But I don't know how reliable this sun blog entry is: http://tinyurl.com/yrrjs2 Best wishes, Paul On 3/2/07, Mathias Brökelmann [EMAIL PROTECTED] 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
Re: @PreDestroy, Servlet API,
Bernd Bohmann wrote: The AnnotationProcessor/InjectionProvider are very similar. I don't like to define a new myfaces Interface for this use case. I would prefer the org.apache.AnnotationProcessor because is not tomcat specific and an apache implementation. Until we find a final solution we should only copy the code. I just had a look at InjectionProvider, and somehow the API is identical to AnnotationProcessor. It did not start that way, and I did not look at InjectionProvider at all (so I suppose it means the API makes sense :D). The interface is used by Catalina (the Servlet container) and also Jasper (Jasper gets the implementation using a specific context attribute). Unfortunately, I don't see a way to do non proprietary annotation/injection processing, since the component that has to do it (JSP or JSF) cannot possibly get the configuration (which could define overrides, etc). Since I suppose you'll want to support all containers, that's a problem. (It would have been solved if the servlet spec had defined an interface like InjectionProvider in javax.servlet, of course.) It's no problem to use the annotation name instead of using the class. But personal i prefer the class. Rémy
Re: @PreDestroy, Servlet API,
Unfortunately, I don't see a way to do non proprietary annotation/injection processing, since the component that has to do it (JSP or JSF) cannot possibly get the configuration (which could define overrides, etc). Since I suppose you'll want to support all containers, that's a problem. (It would have been solved if the servlet spec had defined an interface like InjectionProvider in javax.servlet, of course.) This is going to go down in the same category as inter Portlet communication and j2ee 1.4 web services deployment. It's no problem to use the annotation name instead of using the class. But personal i prefer the class. Rémy -- Dennis Byrne
Re: @PreDestroy, Servlet API,
There were a few of us that wanted to push back on the WebTier EG around annotation support over the fact that there wasn't a clear API provided-- yet oddly enough, everyone is ending up with basically the same API :-) My hope is that the WebBeans JSR can bring some solidarity around this through an injection API which other 'legacy' APIs can simply defer to (Similar to ELResolver). It is tricky from a JSF standpoint, especially with session clustering-- but would WeakReference with your own ReferenceQueue fix this problem of associating the @PreDestroy event? -- Jacob Remy Maucherat wrote: Bernd Bohmann wrote: The AnnotationProcessor/InjectionProvider are very similar. I don't like to define a new myfaces Interface for this use case. I would prefer the org.apache.AnnotationProcessor because is not tomcat specific and an apache implementation. Until we find a final solution we should only copy the code. I just had a look at InjectionProvider, and somehow the API is identical to AnnotationProcessor. It did not start that way, and I did not look at InjectionProvider at all (so I suppose it means the API makes sense :D). The interface is used by Catalina (the Servlet container) and also Jasper (Jasper gets the implementation using a specific context attribute). Unfortunately, I don't see a way to do non proprietary annotation/injection processing, since the component that has to do it (JSP or JSF) cannot possibly get the configuration (which could define overrides, etc). Since I suppose you'll want to support all containers, that's a problem. (It would have been solved if the servlet spec had defined an interface like InjectionProvider in javax.servlet, of course.) It's no problem to use the annotation name instead of using the class. But personal i prefer the class. Rémy
Re: @PreDestroy, Servlet API,
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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.5 containers 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
Re: @PreDestroy, Servlet API,
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 [EMAIL PROTECTED]:
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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.5 containers 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 [EMAIL PROTECTED] 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
Re: @PreDestroy, Servlet API,
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]:
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
Re: @PreDestroy, Servlet API,
The RI looks for com.sun.faces.spi.InjectionProvider for a class
name which implements this interface. It would have been very nice if
this is part of the spec. But that is not the case so we need to find
a way to support any kind of j2ee container. IMO injecting j2ee
resources without knowing where these resources can be found is not
possible. Therefore myfaces should call an InjectionProvider which
simply do this job.
2007/3/3, Dennis Byrne [EMAIL PROTECTED]:
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]:
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
Re: @PreDestroy, Servlet API,
As much as I agree w/ you about how better things would be if this were in
the spec, and as much as I hate to bow down here, I am actually OK with
using com.sun.faces.spi.InjectionProvider as the parameter in MyFaces as
well ... for the sake of users. If anyone has a problem w/ it, we can go
with org.apache.myfaces.InjectionProvider.
Dennis Byrne
On 3/2/07, Mathias Brökelmann [EMAIL PROTECTED] wrote:
The RI looks for com.sun.faces.spi.InjectionProvider for a class
name which implements this interface. It would have been very nice if
this is part of the spec. But that is not the case so we need to find
a way to support any kind of j2ee container. IMO injecting j2ee
resources without knowing where these resources can be found is not
possible. Therefore myfaces should call an InjectionProvider which
simply do this job.
2007/3/3, Dennis Byrne [EMAIL PROTECTED]:
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]:
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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.5is
taken.
I
totally missed that.
Dennis Byrne
On 2/26/07, Paul McMahan [EMAIL PROTECTED] 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
Re: @PreDestroy, Servlet API,
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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.5 containers 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
Re: @PreDestroy, Servlet API,
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 [EMAIL PROTECTED] 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
Re: @PreDestroy, Servlet API,
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
Re: @PreDestroy, Servlet API,
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.5 containers 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
Re: @PreDestroy, Servlet API,
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 [EMAIL PROTECTED] 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.5 containers 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
