myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan <xhh...@gmail.com>
Subject Re: ordering tck failures in geronimo
Date Tue, 07 Dec 2010 01:36:42 GMT
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.
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.
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 ?
thanks.

2010/12/7 Leonardo Uribe <lu4242@gmail.com>

> Hi
>
> First of all, I want to note that if the default algorithm for
> FacesConfigResourceProvider is not able to find a.faces-config.xml and
> c.faces-config.xml, that means the Thread Context Class Loader needs to be
> fixed, because is not taking into account jar files under WEB-INF/lib.
>
> 2010/12/6 Ivan <xhhsld@gmail.com>
>
>>
>>
>> 2010/12/6 David Jencks <david_jencks@yahoo.com>
>>
>>>
>>> On Dec 5, 2010, at 7:44 PM, Ivan wrote:
>>>
>>> > I am wondering whether the myfaces bundle could also export the
>>> spi.impl package, I hope to take advantage of some codes there, e.g.
>>> DefaultFacesConfigurationProvider, it contains some sort algorithm.
>>> > thanks.
>>> >
>>>
>>>
> Why export spi.impl package? the idea to have an spi api and impl is allow
> impl package to change and let api stable to prevent break code later,
> right? If something should be exposed from DefaultFacesConfigurationProvider
> (for example adding some methods on FacesConfigurationProvider), it should
> be discussed first.
>
> I agree to expose this two:
>
>
> +
> org.apache.myfaces.config.impl.digester.elements;version="${project.version}",
> +
> org.apache.myfaces.config.impl.digester;version="${project.version}
>
> because theorically the code there will not change (only between different
> versions of JSF), but the other ones:
>
>
> +
> org.apache.myfaces.spi.impl;version="${project.version}",
> +
> org.apache.myfaces.config;version="${project.version}",
>
> needs some argumentation first.
>
>
>>  I'd say if you need to expose the default implementation of the spi then
>>> there is something wrong with the interface design.  If the sorting is
>>> universal then perhaps it should not be in a class implemented by a service
>>> provider?
>>>
>>
>>
> Ok, as long as I undersand there is no reason why expose sorting algorithm
> to the container. Also, allow a different parser for FacesConfig was
> discussed before. I remember on MYFACES-2945 that it was proposed an
> interface with this methods:
>
> public abstract class FacesConfigurationProvider
> {
>     public abstract FacesConfig getStandardFacesConfig(ExternalContext
> ectx);
>
>     public abstract FacesConfig
> getMetaInfServicesFacesConfig(ExternalContext ectx);
>
>     public abstract FacesConfig getAnnotationsFacesConfig(ExternalContext
> ectx, boolean metadataComplete);
>
>     public abstract List<FacesConfig>
> getClassloaderFacesConfig(ExternalContext ectx);
>
>     public abstract List<FacesConfig>
> getContextSpecifiedFacesConfig(ExternalContext ectx);
>
>     public abstract FacesConfig getWebAppFacesConfig(ExternalContext ectx);
>
>
> }
>
> But finally the final form was this:
>
> public abstract class FacesConfigurationProvider
> {
>
>     public abstract FacesConfigData getFacesConfigData(ExternalContext
> ectx);
>
> }
>
> And this comment was added:
>
> "...After some attempts, the structure of the solution is not too different
> from the previous patch, because after all in
> DefaultFacesConfigurationProvider it is necessary to put all previous code
> plus ordering and feeding of FacesConfig files...."
>
> Note the first form allows to define an custom parser, because to retrieve
> FacesConfig you should locate them first and then parse them, but the second
> one does not.
>
>    Yes, in Geronimo, we have a sepearted algorthim for sorting. Currently,
>> I still use the implementation from MyFaces to do it, maybe in the future I
>> could move them to Geronimo side or it will be abstracted from current
>> default spi provider. I also need to provide a mock external context to make
>> it work. or I might need to copy some codes from myfaces.
>>   Another thing is that, I use the digester xml parser from MyFaces to
>> parse all the faces configuration files, while we using jaxb tree in the
>> past. This could be avoid, just did not want to add some codes to convert
>> two FacesConfig objects.
>>
>
> The idea behind refactor org.apache.myfaces.config.element package is give
> some base classes from myfaces, to allow use a different parser. Those
> changes were committed, but to allow that it is still necessary to commit
> some methods on FacesConfigurationProvider to do the "bridge".
>
> regards,
>
> Leonardo Uribe
>
>   Thanks.
>>
>>
>>> thanks
>>> david jencks
>>>
>>> >
>>> > --
>>> > Ivan
>>>
>>>
>>
>>
>> --
>> Ivan
>>
>
>


-- 
Ivan

Mime
View raw message