[seam-issues] [JBoss JIRA] Commented: (SEAMFACES-185) Add support for activating beans based on the JSF project stage

[Christian Kaltepoth (JIRA)]

    [ https://issues.jboss.org/browse/SEAMFACES-185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12631228#comment-12631228 ] 

Christian Kaltepoth commented on SEAMFACES-185:
-----------------------------------------------

Hey all!

I spent some more work on this issue and I'm very content with the results. I added a SPI called {{WebXmlLocator}}. There are currently two implementations:

* The first implementation only works if the current context classloader is a {{URLClassLoader}}. This class uses {{URLClassLoader.getURLs()}} to find the {{classes}} directory which is then used to find {{web.xml}}
* The new implementation uses Stuart's approach. It uses {{getResource()}} to get the URL of the its own class file and tries to locate {{WEB-INF/lib}} by looking at this URL. This implementation works fine on AS6/AS7 which don't use {{URLClassLoader}}. 

I did some intensive testing with different containers. I can confirm that the current code supports the following containers:

* JBoss AS 7.1.0-SNAPSHOT
* JBoss AS 7.0.2
* JBoss AS 6.0.0
* Apache Tomcat 7.0.20
* Glassfish 3.1.1
* Jetty 8.0.0
* Maven Jetty Plugin ({{mvn jetty:run}})

I would be great if somebody of you could have a look at my branch. I created a pull request to simplify the review process.

https://github.com/seam/faces/pull/55

Just a few notes regarding my branch:

* I only added new classes and didn't change existing code except for the provider-configuration file
* All code is documented and formatted according to the JBoss Community code conventions
* The branch includes a simple Arquillian test that checks that the default project stage is used if not JNDI entry or web.xml is found.
* I added some simple unit tests for some classes to the impl module. So I had to add junit there again. I hope this is OK. I don't think that simple unit tests belong to the testsuite module.
* I also added a new chapter about this feature to the documentation.

I'm looking forward to get any kind of feedback!

Thanks

Christian

> Add support for activating beans based on the JSF project stage
> ---------------------------------------------------------------
>
>                 Key: SEAMFACES-185
>                 URL: https://issues.jboss.org/browse/SEAMFACES-185
>             Project: Seam Faces
>          Issue Type: Feature Request
>    Affects Versions: 3.0.2
>            Reporter: Christian Kaltepoth
>             Fix For: 3.1.0.Tracking
>
>
> Hey all,
> I think it would be a great enhancement if Seam Faces could support activation of beans only in specific JSF project stages. MyFaces CODI supports a similar feature with the {{@ProjectStageActivated}} annotation.
> Examples:
> {code}
> @ProductionStage
> @ApplicationScoped
> public class ProductionEntityManagerProducer {
>   ...
> }
> @DevelopmentStage
> @ApplicationScoped
> public class DevelopmentEntityManagerProducer {
>   ...
> }
> {code}
> Another very interesting usecase would be to enable specific interceptors/decorators only in development stage. This could be used for debugging stuff that is only interesting during development.
> I think this could be easily implenented using an CDI extension that vetos beans that do not match the active project stage. The only problem I'm seeing is that we will need the JSF project stage in an very early stage during application startup (actually before JSF started up). This means that we would have to determine the project stage JSF will use ourselves.
> The JSF spec describes that the project stage can either be set with a servlet context parameter or using JNDI. If the latter one is uses, we could simply do a JNDI lookup in the extension. No problem here. If the developer uses a servlet context parameter the situation will become more problematic, because we will need a reference to the ServletContext in the extension.
> What do you think of this feature? Would it be useful? Any further ideas for the implementation?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira