myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leonardo Uribe <lu4...@gmail.com>
Subject Re: MyFaces in OSGi environment
Date Tue, 26 Jul 2011 18:32:11 GMT
Hi

Ok, first of all you should already know a lot of work has been done
in OSGi and server integration area. Before start you should check:

http://myfaces.apache.org/core20/myfaces-impl/apidocs/index.html

specially the package org.apache.myfaces.spi. In that package you can
find a lot of interfaces designed to override the parts that requires
some special handling from server side point of view. Here is the list
of things that you can do with these interfaces:

- FactoryFinderProvider: override javax.faces.FactoryFinder default
algorithm, that depends on a specified classloader. I think you are
looking for this one.
- AnnotationProvider: override Annotation processing.
- FaceletConfigResourceProvider: locate facelets tag lib files.
- FacesConfigResourceProvider: locate faces-config files.
- FacesConfigurationMerger: externalize faces-config used to configure
an application.
- FacesConfigurationProvider: override faces-config default parser,
based on commons digester. Used to cache already parsed faces-config
files. It could be good to have a SAXParser for faces-config, because
the one based on commons digester has some dependencies over thread
context classloader. Donations here is most welcome.
- ServiceProviderFinder: override spi scanning algorithm
- WebConfigProvider: to find information required by MyFaces that
can't be found without parse web.xml, and that is required by MyFaces

Additonally take into account this class:

- org.apache.myfaces.config.annotation.LifecycleProvider2 :
@PostConstruct annotation handling.
- org.apache.myfaces.webapp.FacesInitializer : override initialization
code. See implementations like Jsp20FacesInitializer and
Jsp21FacesInitializer

If you have already checked the previous stuff and doesn't work for
you, write in a detailed way what do you want to solve, what have you
done and where are the problems. Send the message to dev list. Then
when things get clear, create issues here:

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

And propose as many patches as you want. People from myfaces community
will check it, discuss it and commit it for you. There is a lot of
interest to create spi interfaces to deal with this kind of scenarios.

regards,

Leonardo Uribe

2011/7/26 Kamil Soboń <iso.poczta@gmail.com>:
> How detailed our proposal should be ? We should point every place that we consider to
be changed ? Or it will be enough to write in detailed way, what we wanted to solve, what
we have done and where are the problems ?
>
> Pozdrawiam,
> Kamil Soboń
>
> iso.poczta(at)gmail.com
> sobon(at)student.agh.edu.pl
>
> Dnia 26-07-2011 o godz. 19:43 Mike Kienenberger <mkienenb@gmail.com> napisał(a):
>
>> This is the right place for your questions and proposals.
>>
>> We cannot tell you anything further until we see the proposals and details.
>>
>>
>> On Tue, Jul 26, 2011 at 1:35 PM, Kamil Soboń <iso.poczta@gmail.com> wrote:
>>> Hi all,
>>>
>>> Me and my friend are trying to create modular web application that will work
>>> in OSGi environment.
>>> We have chosen JSF (MyFaces implementation) for our web tier (In fact we
>>> have chosen this technology in first version of our application, where we
>>> have implemented own mechanism for plug-in management, now we want to use
>>> OSGi).
>>>
>>> We have few very important assumption for web tier: views (pages), resources
>>> and manageable beans can be provided, changed and taken away in run-time.
>>> This is a result of other assumption: our application should be modularized
>>> in plug-ins that can be installed, updated or uninstalled in run-time.
>>> There are few problems with MyFaces that we were trying to omit. Some we
>>> have managed to, some partially and some not. I am not going to tell about
>>> the details, but I can tell about them or provide web site urls where we
>>> have written down our cogitations.
>>>
>>> After some time we have reached a conclusion that it is pointless to make
>>> MyFaces working as we want to, without changing things in core
>>> implementation. Generally we know what should be reimplemented or redesigned
>>> in core implementation of MyFaces. We believe that some of changes should be
>>> done in API to make MyFaces more flexible. Once more I am not going to tell
>>> about the details here (but fell free to ask).
>>>
>>> My questions are
>>> Is it our proposal worth of consideration ? Maybe out assumptions break down
>>> some JavaServer Faces assumption and this technology cannot be used in such
>>> application ?
>>> Is it right place to ask about changes in MyFaces ?
>>> Can you/we make such changes in core implementation, or maybe MyFaces is
>>> simply implementation of JSF specification ? If it is, should we turn to
>>> people that are responsible for JSF specification ?
>>>
>>> --
>>> Pozdrawiam,
>>> Kamil Soboń
>>>
>>> iso.poczta(at)gmail.comturn to
>>> sobon(at)student.agh.edu.pl
>>>
>>>
>

Mime
View raw message