You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Paul McMahan <pa...@gmail.com> on 2007/11/12 18:00:47 UTC
external api change OK for myfaces-impl 1.2.1?
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
Re: external api change OK for myfaces-impl 1.2.1?
Posted by Bruno Aranda <br...@gmail.com>.
This is an implementation detail so it sounds fine to me. If there was
a way to deprecate the existing method instead of just replacing it
would be better though. If not, the change is just fine and I don't
expect someone using/extending directly the implementation.
Cheers,
Bruno
On 12/11/2007, Paul McMahan <pa...@gmail.com> wrote:
> 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
>
Re: external api change OK for myfaces-impl 1.2.1?
Posted by Paul McMahan <pa...@gmail.com>.
Whenever you have time sounds fine to me. Thanks again for your help
on this.
Best wishes,
Paul
On Nov 13, 2007, at 4:09 PM, Bernhard Huemer wrote:
> Hello,
>
> Ok, I'll do that on Thursday, if you don't mind.
>
> regards,
> Bernhard
>
> On 11/13/2007 +0100,
> Paul McMahan <pa...@gmail.com> wrote:
>> On Nov 13, 2007, at 3:03 PM, Bernhard Huemer wrote:
>>> 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 ...;
>>>
>>> }
>> Yes, if I understand this new interface correctly then I think it
>> would provide the best of both worlds. Bravo for an excellent idea!
>> I actually started this thread to make sure it's OK to change the
>> LifecycleProvider interface in the upcoming 1.2.1 maintenance
>> release. No concerns have been raised yet so I think that we can
>> proceed in that direction.
>> Would you mind updating the JIRA with this new idea since the rest
>> of our discussion is recorded there? And if you have a specific
>> implementation in mind then please feel free to modify my patch.
>> I really think we are on the right track here.
>> Best wishes,
>> Paul
>
Re: external api change OK for myfaces-impl 1.2.1?
Posted by Bernhard Huemer <be...@gmail.com>.
Hello,
Ok, I'll do that on Thursday, if you don't mind.
regards,
Bernhard
On 11/13/2007 +0100,
Paul McMahan <pa...@gmail.com> wrote:
> On Nov 13, 2007, at 3:03 PM, Bernhard Huemer wrote:
>
>> 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 ...;
>>
>> }
>
> Yes, if I understand this new interface correctly then I think it would
> provide the best of both worlds. Bravo for an excellent idea!
>
> I actually started this thread to make sure it's OK to change the
> LifecycleProvider interface in the upcoming 1.2.1 maintenance release.
> No concerns have been raised yet so I think that we can proceed in that
> direction.
>
> Would you mind updating the JIRA with this new idea since the rest of
> our discussion is recorded there? And if you have a specific
> implementation in mind then please feel free to modify my patch. I
> really think we are on the right track here.
>
>
> Best wishes,
> Paul
>
Re: external api change OK for myfaces-impl 1.2.1?
Posted by Paul McMahan <pa...@gmail.com>.
On Nov 13, 2007, at 3:03 PM, Bernhard Huemer wrote:
> 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 ...;
>
> }
Yes, if I understand this new interface correctly then I think it
would provide the best of both worlds. Bravo for an excellent idea!
I actually started this thread to make sure it's OK to change the
LifecycleProvider interface in the upcoming 1.2.1 maintenance
release. No concerns have been raised yet so I think that we can
proceed in that direction.
Would you mind updating the JIRA with this new idea since the rest of
our discussion is recorded there? And if you have a specific
implementation in mind then please feel free to modify my patch. I
really think we are on the right track here.
Best wishes,
Paul
Re: external api change OK for myfaces-impl 1.2.1?
Posted by Bernhard Huemer <be...@gmail.com>.
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 <be...@gmail.com> 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 <pa...@gmail.com> 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
>>>>
>>
>>
>
>
Re: external api change OK for myfaces-impl 1.2.1?
Posted by Bernhard Huemer <be...@gmail.com>.
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 <pa...@gmail.com> 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
>>>
>
>
Re: external api change OK for myfaces-impl 1.2.1?
Posted by Paul McMahan <pa...@gmail.com>.
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
>>
Re: external api change OK for myfaces-impl 1.2.1?
Posted by Bernd Bohmann <be...@atanion.com>.
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
>