Hi I don't think the OSGi mention is off-topic. In theory it is possible to setup myfaces-api and myfaces-impl jars in a OSGi container using SpringDM. The changes proposed just prevents that possible setup to work, but that one was the first known successful environment to use. Note in this case the are no problems with FactoryFinder, because Spring DM provide a thread context classloader (TCCL) that fix that.
The changes proposed impose the restriction that anyone who wants to use OSGi should use myfaces-bundle jar instead. But from other point of view it is clear that in such environment users could want to use mojarra api and myfaces impl, even if that is not really possible. Note the previous arguments are questionable of course, because in practice people will use myfaces-bundle jar, keeping things simple because you have to deal only with one bundle. So it does not suppose a problem, just a "side effect" to keep in mind. I think it is required to specify in more details which are the "side effects" of the changes proposed. Note on a previous mail i said "... I haven't look the code provided in deep ...", but I guess the patch proposed will prevent @JSFWebConfigParam annotations to be scanned for myfaces builder plugin and consequently break this generated site page: http://myfaces.apache.org/core20/myfaces-impl/webconfig.html http://myfaces.apache.org/core21/myfaces-impl/webconfig.html I don't see very clear the "benefits" of the change. I suppose it enhance debugging in some way, but is that true? can I do a change on shared, and do not have to recompile to see the change? If I set a break point on shared-core, the debugger will stop there? I would like to see a strong (and maybe heavier and tedious but necessary) argumentation before do the change. regards, Leonardo Uribe 2011/7/8 Gerhard Petracek <[email protected]>: > hi mark, > that's a bit off-topic ;) we already (have to) provide osgi bundles. we just > continue to do the same with the shade-plugin. > regards, > gerhard > > http://www.irian.at > > Your JSF powerhouse - > JSF Consulting, Development and > Courses in English and German > > Professional Support for Apache MyFaces > > > > 2011/7/8 Mark Struberg <[email protected]> >> >> Hi folks! >> >> There are 2 problems with JSF under OSGi >> >> a) OSGi is in reality a _big_ mess and not really worth the troubles ;) >> It _should_ make it possible to elegantly switch implementations, but in >> practice you need to import/export all packages explicitly, even those which >> are only used indirectly. >> >> b) the design of the JSF-api could be more clear with separation (hey, >> it's 10 years old!). It is not possible to use a MyFaces-impl with a >> mojarra-api and vice versa, because methods like >> FacesContext#getCurrentInstance() (and similar) access impl classes from the >> API package. This makes it pretty hard to work OSGi. >> >> LieGrue, >> strub >> >> --- On Fri, 7/8/11, Jakob Korherr <[email protected]> wrote: >> >> > From: Jakob Korherr <[email protected]> >> > Subject: Re: Use maven-shade-plugin to prevent duplicate code - >> > revisited >> > To: "MyFaces Development" <[email protected]> >> > Date: Friday, July 8, 2011, 1:09 PM >> > Hi Leo, >> > >> > Yes, I remember that you did some work related to this >> > stuff. Some >> > comments about your problems: >> > >> > 1) If you use myfaces-impl, the packages really are >> > *.shared_impl.* >> > (shade does the relocation on the classes). But a part of >> > this >> > statement is still true - we need to check config files >> > with >> > references to shared and shared_impl. >> > >> > 2) That's not true. We solved this problem in CODI, as >> > described. >> > Please take a look at the code ;) >> > >> > 3) We don't need to execute felix bundle plugin directly >> > in >> > myfaces-impl, b/c it won't work in an OSGi environment >> > anyway (see >> > e.g. FactoryFinder problems). We have myfaces-bundle for >> > this matter! >> > >> > Regards, >> > Jakob >> > >> > 2011/7/7 Leonardo Uribe <[email protected]>: >> > > Hi >> > > >> > > I haven't look the code provided in deep, but long >> > time ago I tried >> > > it. In that time I saw the following problems: >> > > >> > > 1. There are some classes on shared that are used >> > outside it. For >> > > example, see >> > org.apache.myfaces.shared.webapp.webxml.DelegatedFacesServlet. >> > > We need to detect all similar cases and move those >> > classes to >> > > myfaces-impl, but renaming shared with shared-impl, or >> > just create >> > > classes that extends from the ones in shared, to >> > preserve backward >> > > behavior. In theory, the affected packages are: >> > > >> > > org.apache.myfaces.shared_impl.webapp.webxml >> > > org.apache.myfaces.shared_impl.taglib >> > > org.apache.myfaces.shared_impl.taglib.core >> > > >> > > 2. Generated artifacts (-sources.jar, -javadoc.jar) >> > has problems. It >> > > is clear javadoc and source jars will not have >> > shared-impl. >> > > 3. shade plugin and felix maven bundle plugin does not >> > play well. By >> > > default bundle plugin is executed before shade plugin, >> > but what you >> > > want is the opposite, so the information on >> > MANIFEST.MF could be >> > > generated taking into account all classes. Note if we >> > solve 1, this >> > > should not be a problem, because classes inside shared >> > are myfaces >> > > internals (remember why spi interfaces are on impl >> > package and not in >> > > shared). >> > > >> > > I'll keep an eye on the resulting work. >> > > >> > > regards, >> > > >> > > Leonardo Uribe >> > > >> > > 2011/7/7 Gerhard Petracek <[email protected]>: >> > >> hi jakob, >> > >> great - thx! >> > >> regards, >> > >> gerhard >> > >> >> > >> http://www.irian.at >> > >> >> > >> Your JSF powerhouse - >> > >> JSF Consulting, Development and >> > >> Courses in English and German >> > >> >> > >> Professional Support for Apache MyFaces >> > >> >> > >> >> > >> >> > >> 2011/7/7 Jakob Korherr <[email protected]> >> > >>> >> > >>> Hi guys, >> > >>> >> > >>> I committed a working draft to the branch at >> > [1]. However, there are >> > >>> some issues with the javadoc-plugin (see [2]) >> > that must be fixed first >> > >>> in order to get the expected javadoc. The >> > other stuff (shading of >> > >>> shared and impl-ee6) already works as >> > expected! >> > >>> >> > >>> Feel free to try it out yourself. Comments and >> > suggestions are welcome! >> > >>> >> > >>> Regards, >> > >>> Jakob >> > >>> >> > >>> [1] >> > >>> >> > >>> https://svn.apache.org/repos/asf/myfaces/core/branches/2.0.8_shade_prototype/ >> > >>> [2] https://jira.codehaus.org/browse/MJAVADOC-320 >> > >>> >> > >>> 2011/7/7 Werner Punz <[email protected]>: >> > >>> > Excellent news ++1, the shared as we have >> > it is a bad design decision I >> > >>> > hope >> > >>> > shade will get rid of our debugging >> > issues we have with our current >> > >>> > shared. >> > >>> > >> > >>> > >> > >>> > Werner >> > >>> > >> > >>> > >> > >>> > Am 07.07.11 11:04, schrieb Jakob >> > Korherr: >> > >>> >> >> > >>> >> Hi Gerhard, >> > >>> >> >> > >>> >> Thx for (re-)opening this thread. I >> > already created a jira issue [1] >> > >>> >> and a core-branch [2] for >> > prototyping. >> > >>> >> >> > >>> >> Currently I am struggling a little >> > bit with the javadoc-plugin, but >> > >>> >> this stuff should be fixed soon >> > (maybe even today). >> > >>> >> >> > >>> >> I'll let you guys know when I am done >> > with the configuration, so that >> > >>> >> you can try it out yourselves! >> > >>> >> >> > >>> >> Regards, >> > >>> >> Jakob >> > >>> >> >> > >>> >> [1] https://issues.apache.org/jira/browse/MYFACES-3205 >> > >>> >> [2] >> > >>> >> >> > >>> >> >> > >>> >> https://svn.apache.org/repos/asf/myfaces/core/branches/2.0.8_shade_prototype/ >> > >>> >> >> > >>> >> 2011/7/7 Gerhard Petracek<[email protected]>: >> > >>> >>> >> > >>> >>> hi @ all, >> > >>> >>> the goal (as we discussed before) >> > is to get rid of the shared-impl >> > >>> >>> module >> > >>> >>> and move to the shade-plugin for >> > maven. >> > >>> >>> issues with javadoc and osgi >> > bundles prevented us from doing this >> > >>> >>> step. >> > >>> >>> however, with codi v1 we have a >> > project(-configuration) which fixes >> > >>> >>> all >> > >>> >>> the >> > >>> >>> issues we had with the >> > shade-plugin. >> > >>> >>> -> imo we can (and should) >> > use it also for myfaces-core. >> > >>> >>> regards, >> > >>> >>> gerhard >> > >>> >> >> > >>> >> >> > >>> >> >> > >>> > >> > >>> > >> > >>> > >> > >>> >> > >>> >> > >>> >> > >>> -- >> > >>> Jakob Korherr >> > >>> >> > >>> blog: http://www.jakobk.com >> > >>> twitter: http://twitter.com/jakobkorherr >> > >>> work: http://www.irian.at >> > >> >> > >> >> > > >> > >> > >> > >> > -- >> > Jakob Korherr >> > >> > blog: http://www.jakobk.com >> > twitter: http://twitter.com/jakobkorherr >> > work: http://www.irian.at >> > > >
