geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Korherr <jakob.korh...@gmail.com>
Subject Re: Is it possible to make those xml digest class serializable ?
Date Thu, 21 Oct 2010 11:32:34 GMT
Hi Ivan,

Actually the ApplicationMap is only a "wrapper" of the ServletContext
attributes, thus you get the same Map from any Faces-/ExternalContext
(regardless if startup, shutdown or request).

Thus if you put your SPI instance(s) on the ServletContext attributes
Map, we can pick them up via the Application Map.

Regards,
Jakob

2010/10/21 Ivan <xhhsld@gmail.com>:
> Forgot to use reply all :-)
>
> Thanks, please help to check my comments below.
>
> 2010/10/20 Leonardo Uribe <lu4242@gmail.com>
>>
>> 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.
>>
>> 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 ?
>>
>> regards,
>>
>> Leonardo Uribe
>>
>>
>> 2010/10/20 Ivan <xhhsld@gmail.com>
>>>
>>> Hi, devs, I posted some initial ideas to MYFACES-2945, and very
>>> appriciated with any comment :-) Once we have final result, I will try to
>>> create a patch.
>>> thanks.
>>>
>>> 2010/10/19 Jakob Korherr <jakob.korherr@gmail.com>
>>>>
>>>> Hi Ivan,
>>>>
>>>> Great to hear from the Geronimo team :)
>>>>
>>>> If you need some more than the currently available SPIs, please just
>>>> create an issue in the JIRA and we'll take care of it!
>>>>
>>>> Regards,
>>>> Jakob
>>>>
>>>> 2010/10/18 Leonardo Uribe <lu4242@gmail.com>:
>>>> > Hi
>>>> >
>>>> > 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
>>>> > IOException;
>>>> >
>>>> > Suggestions are welcome.
>>>> >
>>>> > regards,
>>>> >
>>>> > Leonardo
>>>> >
>>>> > 2010/10/18 Ivan <xhhsld@gmail.com>
>>>> >>
>>>> >> 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 <werner.punz@gmail.com>
>>>> >>>
>>>> >>> 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
>>>> >
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> Jakob Korherr
>>>>
>>>> blog: http://www.jakobk.com
>>>> twitter: http://twitter.com/jakobkorherr
>>>> work: http://www.irian.at
>>>
>>>
>>>
>>> --
>>> Ivan
>>
>
>
>
> --
> Ivan
>
>
>
> --
> Ivan
>



-- 
Jakob Korherr

blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at

Mime
View raw message