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