[jira] Commented: (MYFACES-2140) Add annotation processing logic

["Leonardo Uribe (JIRA)" <de...@myfaces.apache.org>]

    [ https://issues.apache.org/jira/browse/MYFACES-2140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12683731#action_12683731 ] 

Leonardo Uribe commented on MYFACES-2140:
-----------------------------------------

 Checking the changes to add config ordering feature on myfaces core 2.0, the separation done in FacesConfigurator in this issue could cause problems in the long term. 

Before the change, FacesConfigurator class had several responsibilities:

1. "feed", some structure that holds all necessary information to configure the current environment (see FacesConfigDispenser).
2. "configure", traversing the structure and creating all required classes.
3. "update", implies purge all data and reconfigure, executing the steps 1 and 2 after a specified interval (by org.apache.myfaces.CONFIG_REFRESH_PERIOD). This is a myfaces specific feature.

The class FacesConfiguratorStrategy has two abstract methods that any strategy should implement:

    public abstract void feed() throws FacesException;

    public abstract void configure() throws FacesException;

It is supposed that any strategy implement both methods. The problem with this interface is that suggest that each ConfiguratorStrategy can "configure" ignoring what other ConfiguratorStrategy implementations does. If the intention is provide a pluggable mechanism to change between several strategies, FacesConfiguratorStrategy are doing things complex and does not decouple correctly the code. In few words, you can feed configuration data from several source but the configure process is unique or should be executed just once.

 The things get worse when comes into consideration the section 11.4.6 Ordering of Artifacts and 11.5.1 Requirements for scanning of classes for annotations. For example take these points:

- ".........If the <faces-config> element in the WEB-INF/faces-config.xml file contains metadata-complete attribute whose value is "true", the implementation must not perform annotation scanning......."

- "......If the runtime discovers a conflict between an entry in the Application Configuration Resources and an annotation, the entry in the Application Configuration Resources takes precedence....."

These points suggest that by definition the xml config strategy takes precedence over annotation strategy and defines how it behaves. In conclusion use a FacesConfiguratorStrategy class and make it parent for both xml and annotation strategy is not the best way to model it. It is better define an AnnotationStrategy (so we can define several annotation strategies), and not necessary define a ConfiguratorStrategy for give the option to use other ways to feed data and configure the runtime.

If no objections, I'll make the necessary architectural corrections to the related code.


> Add annotation processing logic
> -------------------------------
>
>                 Key: MYFACES-2140
>                 URL: https://issues.apache.org/jira/browse/MYFACES-2140
>             Project: MyFaces Core
>          Issue Type: New Feature
>          Components: JSR-314
>            Reporter: Jan-Kees van Andel
>         Attachments: ManagedBean.patch, ManagedBeanAnnotationProcessor.patch
>
>
> JSF 2.0 specifies the use of the following annotations for Managed Bean configuration:
> - ManagedBean
> - ManagedBeans
> - ManagedProperty
> - RequestScoped
> - SessionScoped
> - ViewScoped
> - ApplicationScoped
> - NoneScoped
> The annotations are already there, it now needs processing logic.
> I'm on it.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.