geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan <xhh...@gmail.com>
Subject Fwd: Is it possible to make those xml digest class serializable ?
Date Thu, 21 Oct 2010 01:37:34 GMT
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

Mime
View raw message