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" 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=10600&version=12316153 >> >> <https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600&version=12316153> >> >> <https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600&version=12316153 >> >> <https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600&version=12316153>> >> >> >> >> >> > >
