hi, not osgi bundles are off-topic. off-topic was the comment that osgi isn't useful at least in combination with the design of jsf. as i said - we already (have to) provide osgi bundles - we just switch the approach how we create them.
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 Leonardo Uribe <[email protected]> > 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 > >> > > > > > >
