Hello Bernd,
Thanks for looking into this. I think geronimo might be able to work
with the changes you have made, but I don't think it would be a good
idea in the current form. I have two suggestions.
1. Please make use of the discovery mechanism optional. Geronimo
controls the
IMO the simple interface which David suggest is quite sufficient to
solve the problem. I also think that discovery to look up the
implementation is not a good way in a app server with a complex
classloader hierarchy.
2007/3/13, David Jencks [EMAIL PROTECTED]:
Hello Bernd,
Thanks for looking
Hello,
how can the simple interface handle managed beans declared to be in none
scope without knowledge of the scope.
See Section 5.4.1 of the jsf spec:
Methods on managed beans declared to be in request, session, or
application scope, annotated with @PostConstruct, must be called by the
On Mar 13, 2007, at 3:38 PM, Bernd Bohmann wrote:
Hello,
how can the simple interface handle managed beans declared to be in
none scope without knowledge of the scope.
See Section 5.4.1 of the jsf spec:
Methods on managed beans declared to be in request, session, or
application scope,
On Mar 13, 2007, at 3:42 PM, Bernd Bohmann wrote:
Hello David,
should every LifecycleProvider handle the difference between none
scoped beans and other scoped beans. This is not a clean interface.
As I mentioned in another post I think the spec intends that
postConstruct methods be
Hello David,
comments inline
David Jencks wrote:
On Mar 13, 2007, at 3:38 PM, Bernd Bohmann wrote:
I read this to mean that the jsf implementation is prohibited from
calling posConstruct methdods after putting the bean in scope, but that
it is required to call postConstruct on all
On Mar 13, 2007, at 4:39 PM, Bernd Bohmann wrote:
Hello David,
comments inline
David Jencks wrote:
On Mar 13, 2007, at 3:38 PM, Bernd Bohmann wrote:
I read this to mean that the jsf implementation is prohibited from
calling posConstruct methdods after putting the bean in scope, but
that
AFAIK the LifecycleProvider will not handle the scope of the beans.
After calling newInstance(..) the returned value will be placed by
myfaces into the right scope (after injecting the declared managed
bean properties in faces config).
2007/3/13, Bernd Bohmann [EMAIL PROTECTED]:
Hello David,
David Jencks wrote:
I get to set the instance I want to use, and you get to use discovery?
I also don't have to worry about whether the discovery framework is
actually thread safe.
Ok, but I think it's thread safe.
I will apply your changes.
Regards
Bernd
There's been a lot of discussion about annotation processing in a
long thread http://www.nabble.com/%40PreDestroy%2C-Servlet-API%2C-
tf3284592.html#a9136472
The current state of the code is that managed objects are created by
MyFaces code, and then fed to an annotation processor using an
Hello David,
we can move the AnnotationProcessor to the package org.apache.myfaces or
an other package and add the method
Object newInstance(String className);
to the interface.
(I like the idea for possible constructor dependency injection)
And we should lookup the
11 matches
Mail list logo
