[
https://issues.apache.org/jira/browse/MYFACES-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12541154
]
Paul McMahan commented on MYFACES-1761:
---------------------------------------
The original description for this issue says: "The specification states
that... after the object is initialized and after dependency injection is
performed"
But your quote from the spec says: "after the object is *instantiated*, and
after injection is performed"
I take this change in your terminology as agreement that creating
(instantiating) the bean does not involve setting its managed properties,
correct? Now it seems that you are instead interpreting the term "injection"
to include setting of managed properties from the application config file.
But I would have to disagree with that position as well because section 5.4
says (with *emphasis* added by me) :
"JSF Implementations that are running as a part of Java EE 5 must allow managed
bean
implementations to use the annotations specified in section 14.5 of the Servlet
2.5
Specification to allow the container to inject references to *container managed
resources* into
a managed bean instance before it is made accessible to the JSF application."
The spec goes on to provide the concise list of annotations where injection is
valid - @Resource, @EJB, @WebService, etc. I see no other discussion of
injection in the JSF spec. While I can understand your practical usage of this
term to include setting of managed properties, IMO that usage is not consistent
with the spec which is very clear about injection being limited to a specific
list of annotations for referencing container managed resources.
I still agree with you that making this change could be appropriate and I think
that consistency with the RI is important as well. Earlier when I mentioned
the RI I meant Glassfish and not the JSF RI in a standalone servlet container.
The JSF spec only discusses dependency injection in JavaEE. Which
environment did you test the attached sample in?
Your reaction towards my suggestion for keeping the LifecycleProvider interface
unchanged is on track with the reason I hope we can agree that we are
discussing a feature request and not a myfaces bug. If setting managed
properties before calling @PostConstruct is *not* required by the spec, then
3rd party implementations of LifecycleProvider are not required to do it. They
can (optionally) use a refactored ManagedBeanBuilder api to initialize the
managed bean or even process the application config file themselves. Apache
Geronimo would probably do the latter.
> 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.
