s/as it doesn't additional complexity/as it doesn't introduce additional
complexity
Usually, errors don't matter, but I think it's more difficult to
understand otherwise.
On 11/13/2007 +0100,
Bernhard Huemer <[EMAIL PROTECTED]> wrote:
Hello,
Actually, the problem is that you can't take part in the initialization
process, i.e. there is no way to add support for additional,
non-standard injection annotations. For example, I thought of rewriting
Dennis' Guice integration:
///
public class GuiceLifecycleProvider implements LifecycleProvider {
private LifecycleProvider delegate;
public GuiceLifecycleProvider(LifecycleProvider delegate) {
this.delegate = delegate;
}
public Object newInstance(String className) throws ... {
Object bean = delegate.newInstance(className);
injectGuiceDependencies(bean);
return bean;
}
public void postConstruct(Object bean) throws ... {
delegate.postConstruct(bean);
}
// ...
}
\\\
The same goes for Spring @Autowire support, additional WebBeans
integration, etc. That's why I think that my patch provides more
flexibility.
However, if you really can't live with the seperation of initialization
and postconstruction, what about introducing "InjectionTasks"? The
ManagedBeanBuilder, for example, could register an InjectionTask that
handles the injection of managed properties. In fact, I'm thinking of a
more general approach of your patch so that others can perform
additional injection too.
///
public interface InjectionTask {
public void inject(Object bean) throws ...;
}
\\\
Nevertheless, I still think that the seperation would be the ideal
solution as it doesn't additional complexity.
regards
Bernhard
On 11/13/2007 +0100,
Paul McMahan <[EMAIL PROTECTED]> wrote:
Bernd,
My understanding of the JSF 1.2 spec is that annotation processing for
managed beans pertains to the injection of JavaEE managed resources.
Now Bernhard raises a good point which is that for JSF developers a
more practical use of the term "injection" could also mean the
initialization of managed bean properties from their application
config file, and they would expect this initialization to also work in
conjunction with the @PostConstruct annotation. While that behavior
is not prescribed by the spec, I agree that MyFaces users would
intuitively expect it to work that way.
His patch enforces this functionality by factoring the implicit
handling of @PostConstruct annotations out of the newInstance() method
and placing MyFaces in explicit control over when that one particular
type of annotation should be processed. However, I think a goal of
the LifecycleProvider interface has been and should remain to be
providing a clean separation for delegating annotation processing to
the container, and that MyFaces should assist rather than orchestrate
the overall process of resource injection for this one special case.
I think that the advantages of this approach are that it keeps MyFaces
more insulated from future changes to the annotation processing specs
and it makes MyFaces more portable by giving more flexibility to the
container. I also believe that further advantages of this approach
will become apparent as standards such as web beans emerge, where the
EJB and ManagedBean component models are unified.
Best wishes,
Paul
On Nov 12, 2007, at 2:46 PM, Bernd Bohmann wrote:
Hello Paul,
what is wrong with Bernhards patch?
Instead of handling all of the annotation processing in
LifecycleProvider.newInstance(String className)
he suggest to add a method
LifecycleProvider.postConstruct(Object obj)
this method is called after the properties are injected by the
annotation provider and the managed bean properties from the jsf impl.
Why we should delegate the injection of the none annotation based
managed bean properties to the LifecycleProvider? This must be
implemented by Geronimo and the MyFaces Default LifecycleProvider.
I would prefer only one place for the old style managed bean properties
injection.
Regards
Bernd
Paul McMahan schrieb:
The LifecycleProvider interface was introduced in MyFaces core 1.2.0 as
an integration point that allows Java EE containers to handle
annotation
processing for JSF managed beans. In order to help containers invoke
@PostConstruct methods more consistently with the Java EE RI
(glassfish)
we are discussing changing this API in:
https://issues.apache.org/jira/browse/MYFACES-1761
I attached a patch (MYFACES-1761-01.diff) to that JIRA that would
change
a method signature from :
LifecycleProvider.newInstance(String className)
to
LifecycleProvider.newInstance(ManagedBean beanConfig)
The only known implementer of the LifecycleProvider interface (outside
of MyFaces itself) is the Geronimo project, which is in favor of this
change. Are there any concerns with changing this external api in the
upcoming 1.2.1 maintenance release?
BTW, this patch also refactors ManagedBeanBuilder into
ManageBeanInitializer so that the existing code in that class can still
be used to initialize managed properties. Unless I am mistaken
ManagedBeanBuilder was not intended to be externally overridden or
extended, so refactoring it should not affect our users.
Best wishes,
Paul
