myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leonardo Uribe <>
Subject Re: Is it possible to make those xml digest class serializable ?
Date Mon, 18 Oct 2010 19:58:50 GMT

Yes, please create an issue on myfaces issue tracker, so we can handle it
there. Maybe the solution is add some methods on
FaceletConfigResourceProvider, so you can provide the
org.apache.myfaces.config.impl.digester.elements.FacesConfig file from a
specified URL:

   public Object getFacesConfig(ExternalContext context, URL url) throws

Suggestions are welcome.



2010/10/18 Ivan <>

> Yes, I moved this thread to the dev mail list.
> Those classes I mention are in the package
> org.apache.myfaces.config.impl.digester.elements, e.g. FacesConfig. From the
> source codes, it seems that they just hold some collection variables. I
> think that adding the serializable interface should not break the spec
> rules. If I missed anythings, please help to figure out.
> I found that MyFaces does provide some SPI classes, like
> AnnotationProvider, but I might need more. I hope to scan the annotation and
> combine all the configuration resources in the deployment process of
> Geronimo, and finally I got a object instance FacesConfig. While the
> applicaation starts, I just need to deserialize the instance.
> thanks.
> 2010/10/18 Werner Punz <>
> Am 17.10.10 16:11, schrieb Ivan:
>>  Hi,
>>>    I am looking at the integration work between myfaces and Geronimo, I
>>> am
>>> thinking that is it possible to make those xml digest class serializable,
>>> like FacesConfig, etc. So that, MyFaces could just scan annotation and
>>> sort
>>> configuration files once, and de-serialize those classes on each startup.
>>> Seems that only adding the serializable interface is enough.
>>>    Thanks.
>> Hi I think since this is integration work between myfaces and geronimo
>> that it might be good to also post that in the developers list of myfaces.
>> You might also raise a ticket for this issue.
>> The main issue is simply that in the interface and API section we are
>> bound by what the spec allows in the implementatiom section we can do mostly
>> whatever we want as long as it does not break the API.
>> Werner
> --
> Ivan

View raw message