Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Development" <dev@myfaces.apache.org>
Message-ID: <14232887.1194621290594.JavaMail.jira@brutus>
Date: Fri, 9 Nov 2007 07:14:50 -0800 (PST)
From: "Paul McMahan (JIRA)" <dev@myfaces.apache.org>
To: dev@myfaces.apache.org
Subject: [jira] Commented: (MYFACES-1761) Handling PostConstruct annotations
 - wrong order
In-Reply-To: <13745061.1194387530811.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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