geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leonardo Uribe <lu4...@gmail.com>
Subject Re: Is it possible to make those xml digest class serializable ?
Date Fri, 22 Oct 2010 20:57:37 GMT
Hi Ivan

2010/10/21 Ivan <xhhsld@gmail.com>

> Thanks, Leonardo, please help to check my comments below.
>
> 2010/10/22 Leonardo Uribe <lu4242@gmail.com>
>
>
>> 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
>> 11.2.6.1 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
> FacesConfigurator.
>
>

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

Ok, that makes things clearer. Give me some time, I'll think about it and
propose you a possible solution.



>
>>
>>>> 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
> commons-discovery.
>

The problem about do it in that way is that wrapping feature is lost. Right
now, it is possible to create wappers and add additional "steps" to the
current algorithm provided by the interface. I strongly suggest you to use
SPI way. In this issue:

https://issues.apache.org/jira/browse/MYFACES-2860

There is an attachment that shows how to do that (jboss-myfaces.zip
project). It is quite simple and if the user wants to provide additional
wrappers, he can do it easily. I know it could not fit very well in OSGi,
but it has the advantage that is a well know way to extend java.

My opinion is if we are forced to use SPI in JSF, why not take advantage of
that, use it and instead provide a way to configure SPI handling using this
time the servlet attribute map.

regards,

Leonardo Uribe


>> 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
>>
>>
>
>
> --
> Ivan
>

Mime
View raw message