You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Ivan <xh...@gmail.com> on 2010/10/18 08:56:42 UTC
Re: Is it possible to make those xml digest class serializable ?
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 <we...@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
Re: Is it possible to make those xml digest class serializable ?
Posted by Jakob Korherr <ja...@gmail.com>.
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 <xh...@gmail.com>:
> Forgot to use reply all :-)
>
> Thanks, please help to check my comments below.
>
> 2010/10/20 Leonardo Uribe <lu...@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 <xh...@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 <ja...@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 <lu...@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 <xh...@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 <we...@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
Re: Is it possible to make those xml digest class serializable ?
Posted by Jakob Korherr <ja...@gmail.com>.
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 <xh...@gmail.com>:
> Forgot to use reply all :-)
>
> Thanks, please help to check my comments below.
>
> 2010/10/20 Leonardo Uribe <lu...@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 <xh...@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 <ja...@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 <lu...@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 <xh...@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 <we...@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
Fwd: Is it possible to make those xml digest class serializable ?
Posted by Ivan <xh...@gmail.com>.
Forgot to use reply all :-)
Thanks, please help to check my comments below.
2010/10/20 Leonardo Uribe <lu...@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 <xh...@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 <ja...@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 <lu...@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 <xh...@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 <we...@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
Re: Is it possible to make those xml digest class serializable ?
Posted by Ivan <xh...@gmail.com>.
2010/10/23 Leonardo Uribe <lu...@gmail.com>
> Hi Ivan
>
> 2010/10/21 Ivan <xh...@gmail.com>
>
> Thanks, Leonardo, please help to check my comments below.
>>
>> 2010/10/22 Leonardo Uribe <lu...@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.
>
I am looking forward to it, thanks.
>
>
>
>>
>>>
>>>>> 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.
>
It might not be proper for me to checking those codes ;-) I might
configure it according to current search strategy. Again, I did not object
to use the SPI, just want to make sure the expected provider is used as the
real server runtime environment is so complex.
Glad to discuss with you guys :-)
> 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
>>
>
>
--
Ivan
Re: Is it possible to make those xml digest class serializable ?
Posted by Ivan <xh...@gmail.com>.
2010/10/23 Leonardo Uribe <lu...@gmail.com>
> Hi Ivan
>
> 2010/10/21 Ivan <xh...@gmail.com>
>
> Thanks, Leonardo, please help to check my comments below.
>>
>> 2010/10/22 Leonardo Uribe <lu...@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.
>
I am looking forward to it, thanks.
>
>
>
>>
>>>
>>>>> 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.
>
It might not be proper for me to checking those codes ;-) I might
configure it according to current search strategy. Again, I did not object
to use the SPI, just want to make sure the expected provider is used as the
real server runtime environment is so complex.
Glad to discuss with you guys :-)
> 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
>>
>
>
--
Ivan
Re: Is it possible to make those xml digest class serializable ?
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi Ivan
2010/10/21 Ivan <xh...@gmail.com>
> Thanks, Leonardo, please help to check my comments below.
>
> 2010/10/22 Leonardo Uribe <lu...@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
>
Re: Is it possible to make those xml digest class serializable ?
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi Ivan
2010/10/21 Ivan <xh...@gmail.com>
> Thanks, Leonardo, please help to check my comments below.
>
> 2010/10/22 Leonardo Uribe <lu...@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
>
Re: Is it possible to make those xml digest class serializable ?
Posted by Ivan <xh...@gmail.com>.
Thanks, Leonardo, please help to check my comments below.
2010/10/22 Leonardo Uribe <lu...@gmail.com>
> Hi
>
> Here some answers:
>
> 2010/10/20 Ivan <xh...@gmail.com>
>
>> Thanks, please help to check my comments below.
>>
>>
>> 2010/10/20 Leonardo Uribe <lu...@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.
>>
>
> 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.
>
>
>>> 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 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
Re: Is it possible to make those xml digest class serializable ?
Posted by Ivan <xh...@gmail.com>.
Thanks, Leonardo, please help to check my comments below.
2010/10/22 Leonardo Uribe <lu...@gmail.com>
> Hi
>
> Here some answers:
>
> 2010/10/20 Ivan <xh...@gmail.com>
>
>> Thanks, please help to check my comments below.
>>
>>
>> 2010/10/20 Leonardo Uribe <lu...@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.
>>
>
> 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.
>
>
>>> 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 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
Re: Is it possible to make those xml digest class serializable ?
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi
Here some answers:
2010/10/20 Ivan <xh...@gmail.com>
> Thanks, please help to check my comments below.
>
> 2010/10/20 Leonardo Uribe <lu...@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.
>
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?
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?
regards,
Leonardo Uribe
Re: Is it possible to make those xml digest class serializable ?
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi
Here some answers:
2010/10/20 Ivan <xh...@gmail.com>
> Thanks, please help to check my comments below.
>
> 2010/10/20 Leonardo Uribe <lu...@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.
>
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?
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?
regards,
Leonardo Uribe
Fwd: Is it possible to make those xml digest class serializable ?
Posted by Ivan <xh...@gmail.com>.
Forgot to use reply all :-)
Thanks, please help to check my comments below.
2010/10/20 Leonardo Uribe <lu...@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 <xh...@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 <ja...@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 <lu...@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 <xh...@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 <we...@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
Re: Is it possible to make those xml digest class serializable ?
Posted by Leonardo Uribe <lu...@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.
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).
regards,
Leonardo Uribe
2010/10/20 Ivan <xh...@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 <ja...@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 <lu...@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 <xh...@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 <we...@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
>
Re: Is it possible to make those xml digest class serializable ?
Posted by Leonardo Uribe <lu...@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.
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).
regards,
Leonardo Uribe
2010/10/20 Ivan <xh...@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 <ja...@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 <lu...@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 <xh...@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 <we...@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
>
Re: Is it possible to make those xml digest class serializable ?
Posted by Ivan <xh...@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 <ja...@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 <lu...@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 <xh...@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 <we...@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
Re: Is it possible to make those xml digest class serializable ?
Posted by Ivan <xh...@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 <ja...@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 <lu...@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 <xh...@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 <we...@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
Re: Is it possible to make those xml digest class serializable ?
Posted by Jakob Korherr <ja...@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 <lu...@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 <xh...@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 <we...@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
Re: Is it possible to make those xml digest class serializable ?
Posted by Jakob Korherr <ja...@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 <lu...@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 <xh...@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 <we...@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
Re: Is it possible to make those xml digest class serializable ?
Posted by Leonardo Uribe <lu...@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 <xh...@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 <we...@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
>
Re: Is it possible to make those xml digest class serializable ?
Posted by Leonardo Uribe <lu...@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 <xh...@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 <we...@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
>