myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul McMahan (JIRA)" <...@myfaces.apache.org>
Subject [jira] Commented: (MYFACES-1761) Handling PostConstruct annotations - wrong order
Date Fri, 09 Nov 2007 15:14:50 GMT

    [ 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.


Mime
View raw message