geronimo-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 Thu, 21 Oct 2010 22:12:41 GMT

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?

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?

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?


Leonardo Uribe

View raw message