[
https://issues.apache.org/jira/browse/MYFACES-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12541341
]
Paul McMahan commented on MYFACES-1761:
---------------------------------------
Thanks Martin. As you can probably tell (and maybe agree?) I am still not
convinced by the original claim that the current @PostConstruct support in
MyFaces is not compliant with the wording in the JSF spec. In fact I could go
so far as to say that changing the current behavior actually introduces a bug
because the spec is clear about injection (and therefore the timing of
@PostConstruct) being limited to container managed resources.
So like you pointed out our next recourse is to look at the TCK and the RI for
enlightenment. MyFaces 1.2 passed the TCK so we are OK there. But I don't
think that the JSF RI (by itself) can be used to determine the meaning of this
language in the spec because IIUC the JSF RI only provides the "hooks" for
dependency injection.
Therefore my position is that it is the responsibility of the embedder of
MyFaces to ensure compatibility with the *glassfish* RI, and compatibility with
glassfish is not the responsibility of MyFaces itself. Testing the JSF RI's
resource injection behavior outside of a compliant JavaEE container (such as in
tomcat or jetty) is not valid IMHO.
MyFaces can help JavaEE containers meet this compatibility requirement by
refactoring ManagedBeanBuilder. And furthermore MyFaces can provide (as a
feature) default implementations of LifecycleProvider for various non-JavaEE
environments that include this functionality.
My hope is that we can implement this @PostConstruct behavior while keeping the
LifecycleProvider interface intact. LifecycleProvider.newInstance() is the
integration point for dependency injection in several JavaEE components in
Geronimo, and I do not think that it is necessary to change that interface to
provide the desired behavior.
> Handling PostConstruct annotations - wrong order
> ------------------------------------------------
>
> Key: MYFACES-1761
> URL: https://issues.apache.org/jira/browse/MYFACES-1761
> Project: MyFaces Core
> Issue Type: Bug
> Affects Versions: 1.2.0, 1.2.1-SNAPSHOT
> Reporter: Bernhard Huemer
> Fix For: 1.2.1-SNAPSHOT
>
> Attachments: MyFaces-1761.patch, postconstruct-demo.zip
>
>
> The specification states that managed bean methods annotated with
> @PostConstruct have to be called after the object is initialized and after
> dependency injection is performed. However, MyFaces calls those methods after
> the bean instance is created but before dependency injection is performed
> (for example, see
> http://www.nabble.com/myfaces-1.2.0-postConstruct-tf4760326.html ). In order
> to resolve this bug the LifecycleProvider interface has to be changed.
> Currently there's only one method responsible for creating/initializing a new
> bean: newInstance(). This design choice implicates that there's no
> possibility to seperate the steps "creating the bean" and "postconstructing
> the bean".
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
