myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan <>
Subject Re: Is it possible to make those xml digest class serializable ?
Date Fri, 22 Oct 2010 02:09:48 GMT
Thanks, Leonardo, please help to check my comments below.

2010/10/22 Leonardo Uribe <>

> Hi
> Here some answers:
> 2010/10/20 Ivan <>
>> Thanks, please help to check my comments below.
>> 2010/10/20 Leonardo Uribe <>
>>> Hi
>>> Some answers to your post below:
>>> IV>> Just some ideas for the integration improvment, please help to give
>>> some comments.
>>> IV>> a. Create a new SPI provider and a provider factory, might name
>>> FacesConfigurationProvider/
>>> IV>> FacesConfigurationProviderFactory, which has a method
>>> IV>>  FacesConfig getFacesConfig(ExternalContext context);
>>> IV>>    This method is designed to get the final combined the FacesConfig
>>> instance, which including
>>> IV>> application resource configuration + annotation + default web
>>> application resource
>>> IV>>  And move those logic about merge/annotaiton scanning from
>>> FacesConfigurator and
>>> IV>> AnnotationConfigurator to the default implementation provider
>>> Yes, it could be good to have another SPI provider in this case, but I
>>> don't know how that interface should
>>> looks like. In theory, at some point we have a consolidate FacesConfig,
>>> but without the annotation information.
>>> The reason is not all information provided by annotations is on
>>> faces-config.xml format.
>>     The SPI name might not be proper, I am thinking that, for JSF core, it
>> might not care there is some information in the xml files, and others might
>> be from annotation. Guess she will say to the deployer : hey, just give me
>> the final application configuration files, I have no interest where it is
>> from ;-) So I hope to seperate those sort/combine logic from the
>> FacesConfigurator.
> Ok, well, it is true that SPI does not fit well with OSGi after all. We
> have to think about an alternate strategy to provide
> those hooks. I think at this point it is not clear how to put the
> integration points.
> JSF 2.0 spec uses SPI interface to configure some artifacts. In section
> FactoryFinder it says the following:
> ".... 4. If a META-INF/services/{factory-class-name} resource is visible to
> the web application class loader for
> the calling application (typically as a result of being present in the
> manifest of a JAR file), its first line is read and
> assumed to be the name of the factory implementation class to use....."
> Anyway, to ensure proper operation of JSF, SPI interfaces must work because
> by JSF spec, it is expected to use them.
> Now, going back to the point, we need to specify this part a little.
> What is the intention of such interface?

     I might not express the idea clearly. I did not object to use SPI,
actually it is popularly used in the Java EE environment. The idea here is,
just thinking have a provider interface, with it, other containers could
provide the final faces configurations to the JSF core ( including
faces-config.xml and annotations). From my view, the jsf core is just a
consumer for the configurations, she might not require to know where is the
configuration from. For other containers, as you said, they might just
parse, sort, scan and combine the configurations in the deployment time,
then store the result somewhere. While the applications start, those
configurations could be provided to jsf core quickly. In the default impl of
this interface ( or SPI ), think that we could place those existing logic of
parsing, scanning ... there. while those logic currently is in the

> Is the intention do not parse multiple times faces-config xml files and
> save webapp setup time?


> Is the intention do not parse annotations and save webapp setup time?


>>> IV>> b. Make some classes in the
>>> org.apache.myfaces.config.impl.digester.elements package serializable,
>>> IV>> this might be optional...
>>> IV>> From the integration side, the third-party container could implement
>>> their own
>>> IV>> FacesConfigurationProvider, they might return the FacesConfig object
>>> directly from their own structure.
>>> Yes, it could be good to provide a way to expose that configuration
>>> information.
>>> IV>> c. I saw some codes in the ***ProviderFactory is commented out,
>>> IV>>    //AnnotationProviderFactory instance =
>>> (AnnotationProviderFactory) ctx.getApplicationMap().get(FACTORY_KEY);
>>> IV>>        //if (instance != null)
>>> IV>>        //{
>>> IV>>        //    return instance;
>>> IV>>        //}
>>> IV>>   Did it cause any issue ? Or I hope to recover them, as it will be
>>> more easier to set other implemtations
>>> IV>> for other containers. The commons-discovery package might not work
>>> correctly in OSGI environment. as they
>>> IV>> will try to search META-INF/services folder, and this way sometimes
>>> might not work correctly in OSGi environment.
>>> IV>> thanks.
>>> I commented that code because AnnotationProviderFactory,
>>> FaceletConfigResourceProviderFactory
>>> and FacesConfigResourceProviderFactory are only used once in the
>>> application lifetime (during initialization)
>>> so it does not have sense to put them on application map.
>>> In theory, it should work even in OSGi. The reason is to JSF work
>>> correctly in OSGi, it should be provided a
>>> ThreadContextClassLoader (TCCL) that could find resources all bundles
>>> that the web application uses. That's necessary
>>> to make javax.faces.FactoryFinder class work correctly, and it is know
>>> that libraries like SpringDM, or containers like
>>> GlassFish do that to keep code working. Unfortunately, there is no other
>>> option because by the spec it is not possible to
>>> change the way FactoryFinder works (I can't add a BundleActivator on
>>> myfaces-api.jar because this class is public-api).
>>    Yes, I agree that it might work, and just need to place one
>> configuration file in a righ place. But I would prefer to set it
>> programically, and make sure it could be definitely configured, and no other
>> unexpected files would be found, e.g. If the users place some configuration
>> files in their own app etc.
>>    I looked at the codes in the AbstractFacesInitializer, some methods
>> like
>>        private FacesContext _createFacesContext(ServletContext
>> servletContext, boolean startup)
>>        public void destroyStartupFacesContext(FacesContext facesContext)
>>   Also in the StartupServletContextListener, I found the FacesContext for
>> startup is released. So seems that MyFaces will create FacesContext for
>> startup use only. Guess that it might be OK to put in the applicationMap of
>> startup externalContext ?
> Ok, I need more details about what are you doing. I suppose you are
> creating a class that extends from
> org.apache.myfaces.webapp.StartupServletContextListener, and the deployer or
> integration with MyFaces you are
> doing just set some params on servlet context attribute map. That's the
> reason why you need to uncomment the
> code that looks for factory instances on application map, right?

    I have not finished all the codes. Initially, I would like to configure
those spi via applicationMap(). While from the comments of Jakob, those
values in the servletcontext might also be found while looking them in the
applicationmap. So, yes, I would like to configure those provider or
provider factory in the servlet context attribute map, rather than use the

> The right thing to do is create a proper interface to override SPI
> algorithm, but expose that implementation through
> servlet context attribute map and allow users to configure it using web.xml
> params. In that way, before scan for
> META-INF/services, we can pass the control to that interface, and that one
> will be responsible to do that scanning in
> a OSGi friendly way, without depends from ThreadContextClassLoader. But
> anyway, factory classes will be loaded
> through that classloader, because we can't do anything to change how
> javax.faces.FactoryFinder works.
> What do you think about it?

   That might be a plus, and actually, we could see many guys to try to make
the SPI work in OSGI ( you might find some solutions from servicemix, Aries
and Geronimo), or proposed a better way to look up service implementation in
OSGI (mostly use OSGI service).  And I guess most memebers get pain while
making those java ee components work in OSGI environment ;-)
   If MyFaces could provide such interface,  that will be better. Anyway,
this should not be conflict with the idea 1.
   Thoughts ?


> regards,
> Leonardo Uribe


View raw message