[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=12626513#comment-12626513 ] 

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

Hey all,

I just finished a first version of this extension. It seems to work very well. Here a small description of the implementation:

I added the following annotations:

* {{@Development}}
* {{@Production}}
* {{@UnitTest}}
* {{@SystemTest}}

Users can place these annotations on beans to restrict the bean to a certain project stage. If at least one of these annotations is present on a type and the extension detects a different project stage, the type gets vetoed.

The extension uses a SPI called {{ProjectStageDetector}} to obtain the project stage the JSF implementation will use (as CDI starts up before JSF). There are currently three implementations for the project stage lookup, executed in the order of their appearance in this list:

# Read a custom system property {{org.jboss.seam.faces.PROJECT_STAGE}}. This detector runs first so that users are able to manually overwrite the project stage the other detectors find.
# Parse the web.xml file of the webapp and search for the standard context parameter for the project stage.
# Try to find the project stage by doing a JNDI lookup for the standard JNDI name.

A small note on the second detector. This one was the most difficult to implement. The main reason for this is that the ServletContext isn't available when CDI bootstraps. Therefore I wasn't able to use the standard Servlet API to read the context parameter or get an InputStream for the web.xml. Instead I used a trick to read web.xml. I'm checking whether the context classloader is an URLClassLoader. If so, I try to find the URL of the {{/WEB-INF/classes/}} directory and then create a relative URL for web.xml by appending {{../web.xml}} to that URL. I know that is a horrible hack! :(

Unfortunately this way of finding web.xml doesn't work on all containers. I verified that it is working fine in:

 Glassfish 3.1.1
 Tomcat 7.0.x
 Jetty 8.x

But unfortunately it don't work in JBoss AS6 and AS7 as their ClassLoader implementations do not extend URLClassLoader. I know this is really bad, but I currently see no other way of solving the issue of accessing web.xml. Do you have any further ideas? 

However, I think that finding web.xml this way (working in some containers) is better than to don't support project stages specified in web.xml at all, as it is quite common to specify the project stage there.

You can find the current state of my work on GitHub:

https://github.com/chkal/seam-faces/tree/stages

It would be great if I could get some feedback from you guys. Do you like the annotation naming and the way I use a SPI for detecting the project stage? If you like it, I could start adding some more tests and adding a discription to the documentation.

Thanks :)


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