Re: Issue 2995 - Leo please read
Hi
I thought a lot about FactoryFinder and how we can extend it. I'll do a
resume, describing the problem in detail and providing some alternatives.
This could be a little bit redundant, but it is necessary to gain a better
understanding about what's going on and the direction to take.
FactoryFinder is a class with three methods:
public final class FactoryFinder
{
public static Object getFactory(String factoryName) throws
FacesException {...}
public static void setFactory(String factoryName, String implName) {...}
public static void releaseFactories() throws FacesException {...}
}
The javadoc describe the intention of FactoryFinder class:
... FactoryFinder implements the standard discovery algorithm for all
factory objects specified in the JavaServer Faces APIs. For a given factory
class name, a corresponding implementation class is searched for based on
the following algorithm
On the javadoc there is more information from the point of view of the
author (classloading stuff and so on), but just ignore it for a moment,
because it only makes things confusing.
In few words, this class allows to find JSF factory classes. The necessary
information to create factory instances is loaded on initialization time,
but which locations contains such information (for more information see JSF
2.0 spec section 11.4.2) (we are only interested in jsf factories
initialization information) ?
- Look factories on META-INF/services/[factoryClassName]
- Look META-INF/faces-config.xml or META-INF/[prefix].faces-config.xml
- Look the files pointed by javax.faces.CONFIG_FILES web config param (note
WEB-INF/web.xml is taken into consideration)
- Look the applicationFacesConfig on WEB-INF/faces-config.xml
Based on the previous facts, the first conclusion to take into account
arise: Configuration information is gathered per web context. What is a
web context? In simple terms, is the space where a web application is
deployed. Let's suppose an EAR file with two WAR files: a.war and b.war.
Both contains different web applications and when are deployed has
different web context, so both can provide different factory
configuration, because both has different WEB-INF/web.xml and
WEB-INF/faces-config.xml files.
Now, given a request, how the web container identify a web context? At
start, it receives the request information and based on that it decides
which web application should process it. After that, it assign to a thread
from is thread pool to be processed and the control is passed to the proper
filters/servlets.
So, if we don't have a servlet context/portlet context/whatever context, how
to identify a web context? The answer is using the thread, but the one who
knows how to do that is the web container, not the jsf implementation.
The existing problem is caused by a shortcut taken to make things easier.
Instead use the current thread, it is taken as advantage the fact that
each web application deployed has a different classloader. That is true for
a lot of application servers, so the current implementation of FactoryFinder
is based on that fact too and has worked well since the beginning.
Now let's examine in detail how a single classloader per EAR option could
work. If the EAR has two WAR files (a.war and b.war), we have two web
context, and the initialization code is executed twice. When all
FactoryFinder methods are called?
- FactoryFinder.setFactory is called on initialization
- FactoryFinder.releaseFactories is called on shutdown
- FactoryFinder.getFactory is called after initialization configuration is
done but before shutdown call to FactoryFinder.setFactory .
Remember all methods of FactoryFinder are static.
One possible solution could be:
1. Create a class called FactoryFinderProvider, that has the same three
method but in a non static version.
2. A singleton component is provided that holds the information of the
FactoryFinderProviderFactory. This one works per classloader, so the
singleton is implemented using an static variable. To configure it, the
static method should be called when the classloader realm is initialized,
before any web context is started (the WAR is deployed). Usually the EAR is
started as a single entity, so this should occur when the EAR starts, but
before the WAR files are started (or the web context are created). The
singleton will be responsible to decide which
FactoryFinderProvider should be used, based on the current thread
information.
3. Add utility methods to retrieve the required objects and call the methods
using reflection from javax.faces.FactoryFinder
I provided a patch a patch for this one
(MYFACES-2995-FactoryFinderProvider-1.patch)
This patch has the following advantages:
1. No additional module is required
2. The default code works if no FactoryFinderProviderFactory is set, so the
spec javadoc is respected.
3. Code that is used as service provider interface (SPI) is where it should
be (on myfaces-impl class org.apache.myfaces.spi).
4. Solution is
Re: Issue 2995 - Leo please read
On Feb 10, 2011, at 9:39 PM, Leonardo Uribe wrote: Hi David There are some points to take into consideration for myfaces-api jar 1. It is preferred that myfaces-api have the less amount of compile or runtime dependencies to work. Right now, myfaces 2.0.x api and impl only require: commons-beanutils-1.8.3.jar commons-codec-1.4.jar commons-collections-3.2.1.jar commons-digester-1.8.jar commons-logging-1.1.1.jar (transitive from commons packages) jstl-1.2.jar The idea is simple: few dependencies means few things to think about when someone configures its custom webapp. The patch provided adds a new dependency, so additionally with myfaces-api and myfaces-impl it is required to include myfaces-api-spi in every webapp that uses future versions myfaces. Of course,a new module is required because the code cannot be on myfaces-impl (circular dependency). I would think that anyone who is concerned with how many myfaces jars they use would use the osgi bundle which is only one artifact rather than 2 (current) or 3 (proposed). 2. In some situations, a myfaces-api jar is used to only provide classes under javax.faces package, but it is not wanted to include classes under org.apache.myfaces package in that jar, to prevent users to import org.apache.myfaces packages and classes when they don't want. 3. It is wanted to keep coherence with the javadoc provided by the spec. That means, myfaces default behavior should do what the spec javadoc says, but it is not wanted web applications that runs only with myfaces and not with other jsf implementations, because after all that is the intention of take a lot of time and effort to do a specification. The patch proposed could be seen as an unofficial extension for FactoryFinder. I'm not saying we can't do that, just we need to take our time before do some change. IMO the jsf spec and reference implementation make the assumption that there is one classloader per war, probably because all existing containers do that, despite the explicit statememts in the ee spec that this is not required. So to me this is a spec defect. I don't think there's any chance of fixing this in the spec but it is possible to fix it with this extension. Now, let's review the previous response: DJ This is NOT for osgi. The ee classloading model does not require a separate DJ classloader for each war in an ear, whereas currently the myfaces api implementation DJ assumes that web apps can be distinguished by the thread context classloader. But this new feature is for geronimo, right? It is true the ee classloading model does not require a separate classloader ( well, is questionable, because only if something is not explicit mentioned does not means the opposite is true ) , but the truth is almost every ee container uses a different classloader for each war in an ear (maybe all). If that so, why bother us to put this stuff on myfaces api if this will be used by geronimo? if other container in the future wants to use this feature, I think it is a good bet they surely will use myfaces osgi bundle. This is not an osgi specific feature. Are you suggesting that geronimo provide its own FacesFactory implementation and pack up our own myfaces osgi bundle including this code? IMO if myfaces includes this code at all it should not be in a specifically osgi related form. Other option i can imagine is do something using java reflection api. In this way, the code could live in myfaces-impl (where all our spi interfaces are), but I have not dedicated too much time about it. I can write this so the spi-api is optional and is only used if the spi-api interface is available, but this would be significantly more complicated which is why I didn't suggest it at first. Let me know if you'd like to see this. I also think that putting it in myfaces impl is not a good idea because theoretically myfaces-api can be used with another jsf implementation. thanks david jencks regards, Leonardo Uribe
Re: Issue 2995 - Leo please read
Imo myfaces-api is pretty much bound to myfaces-impl. Like el-api is bound to the el-impl most of the times. (sadly) LieGrue, strub --- On Fri, 2/11/11, David Jencks david_jen...@yahoo.com wrote: From: David Jencks david_jen...@yahoo.com Subject: Re: Issue 2995 - Leo please read To: MyFaces Development dev@myfaces.apache.org, Leonardo Uribe lu4...@gmail.com Date: Friday, February 11, 2011, 6:23 PM On Feb 10, 2011, at 9:39 PM, Leonardo Uribe wrote: Hi David There are some points to take into consideration for myfaces-api jar 1. It is preferred that myfaces-api have the less amount of compile or runtime dependencies to work. Right now, myfaces 2.0.x api and impl only require: commons-beanutils-1.8.3.jar commons-codec-1.4.jar commons-collections-3.2.1.jar commons-digester-1.8.jar commons-logging-1.1.1.jar (transitive from commons packages) jstl-1.2.jar The idea is simple: few dependencies means few things to think about when someone configures its custom webapp. The patch provided adds a new dependency, so additionally with myfaces-api and myfaces-impl it is required to include myfaces-api-spi in every webapp that uses future versions myfaces. Of course,a new module is required because the code cannot be on myfaces-impl (circular dependency). I would think that anyone who is concerned with how many myfaces jars they use would use the osgi bundle which is only one artifact rather than 2 (current) or 3 (proposed). 2. In some situations, a myfaces-api jar is used to only provide classes under javax.faces package, but it is not wanted to include classes under org.apache.myfaces package in that jar, to prevent users to import org.apache.myfaces packages and classes when they don't want. 3. It is wanted to keep coherence with the javadoc provided by the spec. That means, myfaces default behavior should do what the spec javadoc says, but it is not wanted web applications that runs only with myfaces and not with other jsf implementations, because after all that is the intention of take a lot of time and effort to do a specification. The patch proposed could be seen as an unofficial extension for FactoryFinder. I'm not saying we can't do that, just we need to take our time before do some change. IMO the jsf spec and reference implementation make the assumption that there is one classloader per war, probably because all existing containers do that, despite the explicit statememts in the ee spec that this is not required. So to me this is a spec defect. I don't think there's any chance of fixing this in the spec but it is possible to fix it with this extension. Now, let's review the previous response: DJ This is NOT for osgi. The ee classloading model does not require a separate DJ classloader for each war in an ear, whereas currently the myfaces api implementation DJ assumes that web apps can be distinguished by the thread context classloader. But this new feature is for geronimo, right? It is true the ee classloading model does not require a separate classloader ( well, is questionable, because only if something is not explicit mentioned does not means the opposite is true ) , but the truth is almost every ee container uses a different classloader for each war in an ear (maybe all). If that so, why bother us to put this stuff on myfaces api if this will be used by geronimo? if other container in the future wants to use this feature, I think it is a good bet they surely will use myfaces osgi bundle. This is not an osgi specific feature. Are you suggesting that geronimo provide its own FacesFactory implementation and pack up our own myfaces osgi bundle including this code? IMO if myfaces includes this code at all it should not be in a specifically osgi related form. Other option i can imagine is do something using java reflection api. In this way, the code could live in myfaces-impl (where all our spi interfaces are), but I have not dedicated too much time about it. I can write this so the spi-api is optional and is only used if the spi-api interface is available, but this would be significantly more complicated which is why I didn't suggest it at first. Let me know if you'd like to see this. I also think that putting it in myfaces impl is not a good idea because theoretically myfaces-api can be used with another jsf implementation. thanks david jencks regards, Leonardo Uribe
Re: Issue 2995 - Leo please read
I agree with this, so long as the circular dependencies for compile time are not used. I also agree with many of tue others, the MyFaces API should be available at compile time and be BINARY compatible with the RI, and even though the impl only need be present at runtime, I don't think anyone expects to be able to run, say, a mojarra impl with a MyFaces API. On Feb 11, 2011, at 11:48 AM, Mark Struberg strub...@yahoo.de wrote: Imo myfaces-api is pretty much bound to myfaces-impl. Like el-api is bound to the el-impl most of the times. (sadly) LieGrue, strub --- On Fri, 2/11/11, David Jencks david_jen...@yahoo.com wrote: From: David Jencks david_jen...@yahoo.com Subject: Re: Issue 2995 - Leo please read To: MyFaces Development dev@myfaces.apache.org, Leonardo Uribe lu4...@gmail.com Date: Friday, February 11, 2011, 6:23 PM On Feb 10, 2011, at 9:39 PM, Leonardo Uribe wrote: Hi David There are some points to take into consideration for myfaces-api jar 1. It is preferred that myfaces-api have the less amount of compile or runtime dependencies to work. Right now, myfaces 2.0.x api and impl only require: commons-beanutils-1.8.3.jar commons-codec-1.4.jar commons-collections-3.2.1.jar commons-digester-1.8.jar commons-logging-1.1.1.jar (transitive from commons packages) jstl-1.2.jar The idea is simple: few dependencies means few things to think about when someone configures its custom webapp. The patch provided adds a new dependency, so additionally with myfaces-api and myfaces-impl it is required to include myfaces-api-spi in every webapp that uses future versions myfaces. Of course,a new module is required because the code cannot be on myfaces-impl (circular dependency). I would think that anyone who is concerned with how many myfaces jars they use would use the osgi bundle which is only one artifact rather than 2 (current) or 3 (proposed). 2. In some situations, a myfaces-api jar is used to only provide classes under javax.faces package, but it is not wanted to include classes under org.apache.myfaces package in that jar, to prevent users to import org.apache.myfaces packages and classes when they don't want. 3. It is wanted to keep coherence with the javadoc provided by the spec. That means, myfaces default behavior should do what the spec javadoc says, but it is not wanted web applications that runs only with myfaces and not with other jsf implementations, because after all that is the intention of take a lot of time and effort to do a specification. The patch proposed could be seen as an unofficial extension for FactoryFinder. I'm not saying we can't do that, just we need to take our time before do some change. IMO the jsf spec and reference implementation make the assumption that there is one classloader per war, probably because all existing containers do that, despite the explicit statememts in the ee spec that this is not required. So to me this is a spec defect. I don't think there's any chance of fixing this in the spec but it is possible to fix it with this extension. Now, let's review the previous response: DJ This is NOT for osgi. The ee classloading model does not require a separate DJ classloader for each war in an ear, whereas currently the myfaces api implementation DJ assumes that web apps can be distinguished by the thread context classloader. But this new feature is for geronimo, right? It is true the ee classloading model does not require a separate classloader ( well, is questionable, because only if something is not explicit mentioned does not means the opposite is true ) , but the truth is almost every ee container uses a different classloader for each war in an ear (maybe all). If that so, why bother us to put this stuff on myfaces api if this will be used by geronimo? if other container in the future wants to use this feature, I think it is a good bet they surely will use myfaces osgi bundle. This is not an osgi specific feature. Are you suggesting that geronimo provide its own FacesFactory implementation and pack up our own myfaces osgi bundle including this code? IMO if myfaces includes this code at all it should not be in a specifically osgi related form. Other option i can imagine is do something using java reflection api. In this way, the code could live in myfaces-impl (where all our spi interfaces are), but I have not dedicated too much time about it. I can write this so the spi-api is optional and is only used if the spi-api interface is available, but this would be significantly more complicated which is why I didn't suggest it at first. Let me know if you'd like to see this. I also think that putting it in myfaces impl is not a good idea because theoretically myfaces-api can be used with another jsf implementation. thanks david jencks regards, Leonardo Uribe
Re: Issue 2995 - Leo please read
Hi David There are some points to take into consideration for myfaces-api jar 1. It is preferred that myfaces-api have the less amount of compile or runtime dependencies to work. Right now, myfaces 2.0.x api and impl only require: commons-beanutils-1.8.3.jar commons-codec-1.4.jar commons-collections-3.2.1.jar commons-digester-1.8.jar commons-logging-1.1.1.jar (transitive from commons packages) jstl-1.2.jar The idea is simple: few dependencies means few things to think about when someone configures its custom webapp. The patch provided adds a new dependency, so additionally with myfaces-api and myfaces-impl it is required to include myfaces-api-spi in every webapp that uses future versions myfaces. Of course,a new module is required because the code cannot be on myfaces-impl (circular dependency). 2. In some situations, a myfaces-api jar is used to only provide classes under javax.faces package, but it is not wanted to include classes under org.apache.myfaces package in that jar, to prevent users to import org.apache.myfaces packages and classes when they don't want. 3. It is wanted to keep coherence with the javadoc provided by the spec. That means, myfaces default behavior should do what the spec javadoc says, but it is not wanted web applications that runs only with myfaces and not with other jsf implementations, because after all that is the intention of take a lot of time and effort to do a specification. The patch proposed could be seen as an unofficial extension for FactoryFinder. I'm not saying we can't do that, just we need to take our time before do some change. Now, let's review the previous response: DJ This is NOT for osgi. The ee classloading model does not require a separate DJ classloader for each war in an ear, whereas currently the myfaces api implementation DJ assumes that web apps can be distinguished by the thread context classloader. But this new feature is for geronimo, right? It is true the ee classloading model does not require a separate classloader ( well, is questionable, because only if something is not explicit mentioned does not means the opposite is true ) , but the truth is almost every ee container uses a different classloader for each war in an ear (maybe all). If that so, why bother us to put this stuff on myfaces api if this will be used by geronimo? if other container in the future wants to use this feature, I think it is a good bet they surely will use myfaces osgi bundle. Other option i can imagine is do something using java reflection api. In this way, the code could live in myfaces-impl (where all our spi interfaces are), but I have not dedicated too much time about it. regards, Leonardo Uribe
Re: Issue 2995 - Leo please read
Hi I already saw the patch, but I forget to do some comments about it. First of all, 2.0.4 is a quick fix release, so new features or improvements are not being considered for this one. The patch provided on MYFACES-2995 cannot be applied it its current form. The reason is it suggest a new module should be created but it adds a dependency of myfaces-api to this module. Any module creation should be discussed and voted on dev list first. I don't know if this feature is required only for OSGi case. If that so, I think it is preferred to use myfaces-bundle and add the required stuff there, overriding the initial FactoryFinder. It has sense to provide an alternate one there, because after all, OSGi by nature or definition requires more fine grained control over this stuff. Long time ago, some voices mentioned on this list that an alternate FactoryFinder implementation was not acceptable, that's the reason why I stop working on that idea, but maybe we should reconsider. I have found the same problem every time I tried to make myfaces more compatible with OSGi, and the only option to overcome those limitations is override FactoryFinder in one way or another. regards, Leonardo Uribe 2011/2/9 Werner Punz werner.p...@gmail.com Hi seems this went a little bit under, I only can apologize for this, and I assume everyone else is my opinion also, given the importance of this bug I guess Leo should have a serious look at it and integrate it Asap, I cannot really since this is not my domain, but more Leos who has worked on the integration issues recently. Sometimes you have to ping a little bit more stubbornly. Sorry again Werner Am 09.02.11 09:00, schrieb David Jencks: On December 6 2010 I opened MYFACES-2995 and was promptly informed that it could not be considered for 2.0.3 due to lack of time for review. On January 11 I asked whether it would be possible to consider it then and received no reply. Is there any chance any committers could actually review this suggestion? Out of curiosity, how are myfaces releases scheduled? I didn't see any notice or warning on the dev list that this vote was imminent. thanks david jencks On Feb 8, 2011, at 10:07 PM, Leonardo Uribe wrote: Hi, I was running the needed tasks to get the 2.0.4 release of Apache MyFaces core out. The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.0.5 [1] 2. Maven artifact group org.apache.myfaces.core v2.0.4 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [3] for binary and source packages. The release notes could be found at [4]. Also the clirr test does not show binary incompatibilities with myfaces-api. Please take a look at the 2.0.4 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] https://repository.apache.org/content/repositories/orgapachemyfaces-044/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces204binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12316153 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12316153
Re: Issue 2995 - Leo please read
If it is for OSGI only I think the bundle only is fine with me If not I dont have any problem to add an integration module, where all the container specfic integration stuff can move into if it is not hostable in our core. Might be worthwhile to add such a module anyway so that we can isolate some OSGI specific stuff in there as well. How about it. I personally dont have any problem with another module. I have more issues with our shared stuff, because it makes debugging a pain. So +1 from me for either solution, not that we have a vote on this issue yet :-) Werner Am 09.02.11 14:52, schrieb Leonardo Uribe: Hi I already saw the patch, but I forget to do some comments about it. First of all, 2.0.4 is a quick fix release, so new features or improvements are not being considered for this one. The patch provided on MYFACES-2995 cannot be applied it its current form. The reason is it suggest a new module should be created but it adds a dependency of myfaces-api to this module. Any module creation should be discussed and voted on dev list first. I don't know if this feature is required only for OSGi case. If that so, I think it is preferred to use myfaces-bundle and add the required stuff there, overriding the initial FactoryFinder. It has sense to provide an alternate one there, because after all, OSGi by nature or definition requires more fine grained control over this stuff. Long time ago, some voices mentioned on this list that an alternate FactoryFinder implementation was not acceptable, that's the reason why I stop working on that idea, but maybe we should reconsider. I have found the same problem every time I tried to make myfaces more compatible with OSGi, and the only option to overcome those limitations is override FactoryFinder in one way or another. regards, Leonardo Uribe 2011/2/9 Werner Punz werner.p...@gmail.com mailto:werner.p...@gmail.com Hi seems this went a little bit under, I only can apologize for this, and I assume everyone else is my opinion also, given the importance of this bug I guess Leo should have a serious look at it and integrate it Asap, I cannot really since this is not my domain, but more Leos who has worked on the integration issues recently. Sometimes you have to ping a little bit more stubbornly. Sorry again Werner Am 09.02.11 09:00, schrieb David Jencks: On December 6 2010 I opened MYFACES-2995 and was promptly informed that it could not be considered for 2.0.3 due to lack of time for review. On January 11 I asked whether it would be possible to consider it then and received no reply. Is there any chance any committers could actually review this suggestion? Out of curiosity, how are myfaces releases scheduled? I didn't see any notice or warning on the dev list that this vote was imminent. thanks david jencks On Feb 8, 2011, at 10:07 PM, Leonardo Uribe wrote: Hi, I was running the needed tasks to get the 2.0.4 release of Apache MyFaces core out. The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.0.5 [1] 2. Maven artifact group org.apache.myfaces.core v2.0.4 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [3] for binary and source packages. The release notes could be found at [4]. Also the clirr test does not show binary incompatibilities with myfaces-api. Please take a look at the 2.0.4 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] https://repository.apache.org/content/repositories/orgapachemyfaces-044/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces204binsrc http://people.apache.org/%7Elu4242/myfaces204binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12316153 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12316153 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12316153
Re: Issue 2995 - Leo please read
This is NOT for osgi. The ee classloading model does not require a separate classloader for each war in an ear, whereas currently the myfaces api implementation assumes that web apps can be distinguished by the thread context classloader. So the idea behind the patch is to provide a way to plug in a way for the environment to supply the correct myfaces context depending on which web app is active on the thread. Most of the time (tomcat, jetty, plain wars, app servers that do provide distinct classloaders for wars in an ear) the existing implementation will work fine. I didn't see a reasonable way to do this without another module, and since it's for modifying the behavior of the api classes, I don't think it will fit into a module used for any other purposes. We haven't found any problems running myfaces in geronimo 3 web profile under osgi (after creating the single api + impl bundle), so I'd be interested to know what problems Leonardo has run into. And, sorry for sounding disgruntled I didn't realize 2.0.4 was a kind of emergency bug fix release. thanks david jencks On Feb 9, 2011, at 6:44 AM, Werner Punz wrote: If it is for OSGI only I think the bundle only is fine with me If not I dont have any problem to add an integration module, where all the container specfic integration stuff can move into if it is not hostable in our core. Might be worthwhile to add such a module anyway so that we can isolate some OSGI specific stuff in there as well. How about it. I personally dont have any problem with another module. I have more issues with our shared stuff, because it makes debugging a pain. So +1 from me for either solution, not that we have a vote on this issue yet :-) Werner Am 09.02.11 14:52, schrieb Leonardo Uribe: Hi I already saw the patch, but I forget to do some comments about it. First of all, 2.0.4 is a quick fix release, so new features or improvements are not being considered for this one. The patch provided on MYFACES-2995 cannot be applied it its current form. The reason is it suggest a new module should be created but it adds a dependency of myfaces-api to this module. Any module creation should be discussed and voted on dev list first. I don't know if this feature is required only for OSGi case. If that so, I think it is preferred to use myfaces-bundle and add the required stuff there, overriding the initial FactoryFinder. It has sense to provide an alternate one there, because after all, OSGi by nature or definition requires more fine grained control over this stuff. Long time ago, some voices mentioned on this list that an alternate FactoryFinder implementation was not acceptable, that's the reason why I stop working on that idea, but maybe we should reconsider. I have found the same problem every time I tried to make myfaces more compatible with OSGi, and the only option to overcome those limitations is override FactoryFinder in one way or another. regards, Leonardo Uribe 2011/2/9 Werner Punz werner.p...@gmail.com mailto:werner.p...@gmail.com Hi seems this went a little bit under, I only can apologize for this, and I assume everyone else is my opinion also, given the importance of this bug I guess Leo should have a serious look at it and integrate it Asap, I cannot really since this is not my domain, but more Leos who has worked on the integration issues recently. Sometimes you have to ping a little bit more stubbornly. Sorry again Werner Am 09.02.11 09:00, schrieb David Jencks: On December 6 2010 I opened MYFACES-2995 and was promptly informed that it could not be considered for 2.0.3 due to lack of time for review. On January 11 I asked whether it would be possible to consider it then and received no reply. Is there any chance any committers could actually review this suggestion? Out of curiosity, how are myfaces releases scheduled? I didn't see any notice or warning on the dev list that this vote was imminent. thanks david jencks On Feb 8, 2011, at 10:07 PM, Leonardo Uribe wrote: Hi, I was running the needed tasks to get the 2.0.4 release of Apache MyFaces core out. The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.0.5 [1] 2. Maven artifact group org.apache.myfaces.core v2.0.4 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [3] for binary and source packages. The release notes could be found at [4]. Also the clirr test does not show binary incompatibilities with myfaces-api. Please take a look at the 2.0.4
