myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leonardo Uribe <lu4...@gmail.com>
Subject Re: ordering tck failures in geronimo
Date Tue, 07 Dec 2010 02:33:44 GMT
Hi

2010/12/6 Ivan <xhhsld@gmail.com>

> Some detailed information :
> a. org.apache.myfaces.config.impl.digester ->
> DigesterFacesConfigUnmarshallerImpl
> b. org.apache.myfaces.config -> DefaultFacesConfigurationProvider
> c. org.apache.myfaces.spi.impl -> ServletMappingImpl
>
> For item c, I have removed the use of ServletMappingImpl, so no need to
> export the spi.impl package now.
>

Ok, the intention is use org.apache.myfaces.spi.ServletMapping instead.


> For item a, currently I use DigesterFacesConfigUnmarshallerImpl to parse
> the faces-config.xml codes in Geronimo's own codes, as I need to query some
> info from the parsed java objects. And currently, I do not see a strong
> requirement for a Geronimo parser.
>

This is a unknown requeriment until this moment. In theory, the preferred
way should be if Geronimo needs some info available on faces-config.xml
files then Geronimo should parse the files in its own way without rely on
myfaces internals.


> For item b, I created a sub classes of DefaultFacesConfigurationProvider,
> and just overrides those get*** methods, the class is look like :
> --->
> public class GeronimoFacesConfigurationProvider extends
> DefaultFacesConfigurationProvider {
>
>     private FacesConfig annotationsFacesConfig;
>
>     private List<FacesConfig> classloaderFacesConfigs;
>
>     private List<FacesConfig> contextSpecifiedFacesConfigs;
>
>     private FacesConfig webAppFacesConfig;
>
>     private FacesConfig standardFacesConfig;
>
>     public GeronimoFacesConfigurationProvider(FacesConfig
> standardFacesConfig, FacesConfig webAppFacesConfig, FacesConfig
> annotationsFacesConfig, List<FacesConfig> classloaderFacesConfigs,
>             List<FacesConfig> contextSpecifiedFacesConfigs) {
>         this.annotationsFacesConfig = annotationsFacesConfig;
>         this.classloaderFacesConfigs = classloaderFacesConfigs;
>         this.contextSpecifiedFacesConfigs = contextSpecifiedFacesConfigs;
>         this.webAppFacesConfig = webAppFacesConfig;
>         this.standardFacesConfig = standardFacesConfig;
>     }
>
>     @Override
>     protected FacesConfig getAnnotationsFacesConfig(ExternalContext ectx,
> boolean metadataComplete) {
>         return annotationsFacesConfig;
>     }
>
>     @Override
>     protected List<FacesConfig> getClassloaderFacesConfig(ExternalContext
> externalContext) {
>         return classloaderFacesConfigs;
>     }
>
>     @Override
>     protected List<FacesConfig>
> getContextSpecifiedFacesConfig(ExternalContext externalContext) {
>         return contextSpecifiedFacesConfigs;
>     }
>
>     @Override
>     protected FacesConfig getStandardFacesConfig(ExternalContext
> externalContext) {
>         return standardFacesConfig;
>     }
>
>     @Override
>     protected FacesConfig getWebAppFacesConfig(ExternalContext
> externalContext) {
>         return webAppFacesConfig;
>     }
>
> }
> <---
> Thoughts ?
>

Instead override those methods, it is better to add them to
FacesConfigurationProvider, as was proposed originally on MYFACES-2945.

I know this is work in progress, so I thing it is better to think more about
it and suggest the changes required by myfaces later. Tomorrow I'll start
the steps to release core 2.0.3, since there is nothing that could be a
blocker issue for that objective.

regards,

Leonardo Uribe


> thanks.
>

Mime
View raw message