I agree with Leonardo that changes which affect our base requirements (jdk 6 instead of jdk 5) and which could compromise our certification warrant discussion rather than a "commit-and-hope-no-one-complains" attitude.
Otherwise, without discussion, how would we know that Mojarra allows it? On Thu, Mar 11, 2010 at 4:24 PM, Leonardo Uribe <lu4...@gmail.com> wrote: > Hi > > 2010/3/11 Jakob Korherr <jakob.korh...@gmail.com> >> >> Hi, >> >> I totally agree with Jan-Kees. Just override the compiler plugin in >> implee6 to use jdk 6! >> >> Also I really don't see why you think it is such a big problem to have a >> class in the jar file which has other dependencies and another version when >> no other class has any relations to it. It's like a website with no link >> referring to it: you will never find it unless you know the real address of >> it! >> >> Furthermore if we put it into myfaces commons we can also drop it, because >> then it makes no sence. The user will rather continue to use the web.xml >> configuration than bundling some jar, which he maybe does not know that it >> even exists.. >> > > So the change has no sense outside myfaces impl jar. That means we only have > two options: do it like this or remove the code. > >> >> And last but not least: Mojarra also has a similar JDK6 compiled class >> with Java EE 6 dependencies in their jsf-impl.jar. So why would it be a >> problem for MyFaces? >> > > The position from jsr-314-open mail list is as long as TCK test pass we > could do it, and if mojarra has something similar, we could do the same. If > something happens we could remove it and that's all (that means if something > happens we'll be forced to remove this feature from myfaces and that is > risky), since this is not part of the standard, but users should be aware of > that implication. Note from this change, myfaces requires JDK 1.6 to be > compiled, but the classes inside api and impl modules requires JDK 1.5. > >> >> Please don't make this problem bigger as it is... >> > > I believe it is important to discuss the possible implications of a change > before commit it and make it clear to people (that's one idea about > opensource, give the people the power to know what's happening behind > courtains and the tools to change it). Just put some code because you like > it, or it is cool not always is enough. That's common sense, right?. Also > you have to keep into account this is a standard of some spec, not just a > custom library, so a lot of care is required before add a new feature > outside the spec. So, the idea is not make a problem bigger or start a > bizantine war that leads to nowhere, just benefit the community throught > constructive discussion, but for a discussion it is necessary a clear and > rational position, possible courses of action before start and a "open" > mind, that means, give yourself the possibility of change of opinion > anytime. Please note the benefit of this exercise, if someone wants to check > why this stuff is done in this or that way, there is a source of knowledge > through the mailing list. Please think carefully about what "opensource" > word means. > > regards, > > Leonardo Uribe > >> >> Regards, >> Jakob >> >> >> 2010/3/11 Leonardo Uribe <lu4...@gmail.com> >>> >>> Hi >>> >>> I have sended an email to jsr-314-open mail list just to confirm if it is >>> valid or not to do this kind of stuff. The problem is the class involved on >>> implee6 has dependencies with classes that needs JDK 6 to be compiled, so in >>> a JDK 1.5 environment it will crash if the classes are loaded. It is true >>> ease of development will suffer, but I think prevent bugs like this takes >>> precedence. >>> >>> regards, >>> >>> Leonardo Uribe >>> >>> 2010/3/11 Jan-Kees van Andel <jankeesvanan...@gmail.com> >>>> >>>> Why not override the compiler plugin in the module to use JDK 6? >>>> >>>> I think the whole point about the module is ease of development and this >>>> will suffer when putting it in a separate jar. >>>> >>>> About the manual classpath scanning or other runtime stuff. This should >>>> not break because of JDK 6 stuff, since the bytecode should be backwards >>>> compatible. >>>> >>>> My 2 cents... >>>> >>>> /JK >>>> >>>> >>>> 2010/3/11 Leonardo Uribe <lu4...@gmail.com> >>>>> >>>>> Hi >>>>> >>>>> I'm working with jdk 1.5 and when I tried to compile current20 branch I >>>>> have an error. This means to create myfaces jars it should be compiled >>>>> with >>>>> jdk 1.6, because implee6 has dependencies with jars with java 1.6 specific >>>>> code: >>>>> >>>>> [INFO] >>>>> ------------------------------------------------------------------------ >>>>> [ERROR] BUILD FAILURE >>>>> [INFO] >>>>> ------------------------------------------------------------------------ >>>>> [INFO] Compilation failure >>>>> >>>>> D:\workspace\myfaces\current20\core\implee6\src\main\java\org\apache\myfaces\ee6 >>>>> \MyFacesContainerInitializer.java:[47,-1] cannot access >>>>> javax.servlet.ServletCon >>>>> tainerInitializer >>>>> bad class file: C:\Documents and >>>>> Settings\lu4242\.m2\repository\javax\javaee-web >>>>> >>>>> -api\6.0\javaee-web-api-6.0.jar(javax/servlet/ServletContainerInitializer.class) >>>>> >>>>> class file has wrong version 50.0, should be 49.0 >>>>> >>>>> In theory, we can't do this, because if we do, myfaces-impl has one >>>>> class jdk 1.6 specific, and jsf 2.0 is jdk 1.5 compatible. Now, in the >>>>> practice this class is not loaded by any part of myfaces, but maybe some >>>>> program that tries to scan the classpath and load this class into the >>>>> classpath will see the problem. >>>>> >>>>> My personal opinion is implee6 should have its own separate jar with >>>>> some OSGi specific stuff, so if someone wants to use it it should put >>>>> three >>>>> jars on the classpath: myfaces-api, myfaces-impl, myfaces-implee6. We >>>>> have a >>>>> lot of precedences for that kind of stuff (orchestra core and core15 for >>>>> example, tomahawk sandbox and sandbox15). >>>>> >>>>> I also think this code should be moved to myfaces commons, because keep >>>>> it as a module in core project means we have to use jdk 1.6 to compile all >>>>> artifacts and we have a plugin that checks for jdk 1.5 compatibility that >>>>> will fail (see checkJDK profile on myfaces impl pom). >>>>> >>>>> Suggestions are welcome. >>>>> >>>>> regards, >>>>> >>>>> Leonardo Uribe >>>>> >>>>> 2010/3/8 Jakob Korherr <jakob.korh...@gmail.com> >>>>>> >>>>>> Hi, >>>>>> >>>>>> So I committed everything. Please feel free to test it - I am curious >>>>>> about your opinions :) >>>>>> >>>>>> Regards, >>>>>> Jakob >>>>>> >>>>>> 2010/3/8 Jakob Korherr <jakob.korh...@gmail.com> >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Since there don't seem to be any big concerns about this, I will now >>>>>>> commit the new submodule "implee6". >>>>>>> >>>>>>> Regards, >>>>>>> Jakob >>>>>>> >>>>>>> 2010/3/8 Gerhard Petracek <gerhard.petra...@gmail.com> >>>>>>>> >>>>>>>> +1 >>>>>>>> regards, >>>>>>>> gerhard >>>>>>>> >>>>>>>> http://www.irian.at >>>>>>>> >>>>>>>> Your JSF powerhouse - >>>>>>>> JSF Consulting, Development and >>>>>>>> Courses in English and German >>>>>>>> >>>>>>>> Professional Support for Apache MyFaces >>>>>>>> >>>>>>>> >>>>>>>> 2010/3/8 Werner Punz <werner.p...@gmail.com> >>>>>>>>> >>>>>>>>> +1 for that idea, the less configuration the better. >>>>>>>>> >>>>>>>>> Werner >>>>>>>>> >>>>>>>>> >>>>>>>>> Am 07.03.10 15:44, schrieb Jakob Korherr: >>>>>>>>>> >>>>>>>>>> I think we don't even need such a parameter, because the idea is >>>>>>>>>> that >>>>>>>>>> the listener just does nothing if there are already entries for >>>>>>>>>> the >>>>>>>>>> FacesServlet in web.xml! >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Jakob >>>>>>>>>> >>>>>>>>>> 2010/3/7 Jan-Kees van Andel <jankeesvanan...@gmail.com >>>>>>>>>> <mailto:jankeesvanan...@gmail.com>> >>>>>>>>>> >>>>>>>>>> Agreed, I was only thinking of one parameter: A parameter to >>>>>>>>>> turn >>>>>>>>>> the entire StartupListener off. >>>>>>>>>> >>>>>>>>>> I look at it as a binary thing. Either the developer chooses to >>>>>>>>>> go >>>>>>>>>> with the flow with no custimization, OR he chooses to customize >>>>>>>>>> everything. >>>>>>>>>> >>>>>>>>>> I.e. org.apache.myfaces.DISABLE_FACES_SERVLET_AUTODEPLOY = true >>>>>>>>>> (default false) >>>>>>>>>> >>>>>>>>>> I think this will cover all use cases, where some may require a >>>>>>>>>> bit >>>>>>>>>> more configuration, but still work... >>>>>>>>>> >>>>>>>>>> /JK >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2010/3/7 Jakob Korherr <jakob.korh...@gmail.com >>>>>>>>>> <mailto:jakob.korh...@gmail.com>> >>>>>>>>>> >>>>>>>>>> Yep! >>>>>>>>>> >>>>>>>>>> We can discuss this stuff when the submodule is in place. >>>>>>>>>> Such >>>>>>>>>> things are very easy to change/configure in the >>>>>>>>>> StartupListener. >>>>>>>>>> >>>>>>>>>> However, I think we should come up with a very standard >>>>>>>>>> default >>>>>>>>>> configuration. If the user wants something different, he >>>>>>>>>> will >>>>>>>>>> have to configure the mapping himself in the web.xml just >>>>>>>>>> as it >>>>>>>>>> is now. I am not a fan of too many configuration parameters >>>>>>>>>> which interfere with other configuration methods. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Jakob >>>>>>>>>> >>>>>>>>>> 2010/3/7 Jan-Kees van Andel <jankeesvanan...@gmail.com >>>>>>>>>> <mailto:jankeesvanan...@gmail.com>> >>>>>>>>>> >>>>>>>>>> In other words: Convention over configuration ;-) >>>>>>>>>> >>>>>>>>>> I just think it's important to pick sensible defaults >>>>>>>>>> and to >>>>>>>>>> be able to turn it off, for example using a >>>>>>>>>> context-param. >>>>>>>>>> >>>>>>>>>> For example, I think the mapping *.xhtml should also be >>>>>>>>>> default, but a developer must be able to turn *.xhtml >>>>>>>>>> off, >>>>>>>>>> since it's a widely used extension also outside of >>>>>>>>>> JSF... >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Jan-Kees >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2010/3/7 Jakob Korherr <jakob.korh...@gmail.com >>>>>>>>>> <mailto:jakob.korh...@gmail.com>> >>>>>>>>>> >>>>>>>>>> Hi Bernd, >>>>>>>>>> >>>>>>>>>> For some users it may be so ;) :D >>>>>>>>>> >>>>>>>>>> Look Bernd, it's not that big thing. It's just a >>>>>>>>>> class >>>>>>>>>> and a text file. So it is by no means a problem to >>>>>>>>>> ship >>>>>>>>>> this with MyFaces Core 2. Also Mojarra does >>>>>>>>>> something >>>>>>>>>> similar too! >>>>>>>>>> >>>>>>>>>> To your question: Nope! I just add the FacesServlet >>>>>>>>>> and >>>>>>>>>> the standard mappings /faces/*, *.jsf and maybe >>>>>>>>>> also >>>>>>>>>> *.faces, if there are no entries for the >>>>>>>>>> FacesServlet in >>>>>>>>>> the web.xml. If a user wants something special, he >>>>>>>>>> do >>>>>>>>>> will have to configure it in his web.xml. In this >>>>>>>>>> scenario my StartupListener will just do nothing. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Jakob >>>>>>>>>> >>>>>>>>>> 2010/3/6 Bernd Bohmann >>>>>>>>>> <bernd.bohm...@googlemail.com >>>>>>>>>> <mailto:bernd.bohm...@googlemail.com>> >>>>>>>>>> >>>>>>>>>> Hello Jakob, >>>>>>>>>> >>>>>>>>>> do you really think adding an other dependency >>>>>>>>>> is a >>>>>>>>>> real problem? >>>>>>>>>> How do you configure prefix or suffix mapping? >>>>>>>>>> For >>>>>>>>>> each possible >>>>>>>>>> configuration option an own impl version? >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> >>>>>>>>>> Bernd >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Sat, Mar 6, 2010 at 4:48 PM, Jakob Korherr >>>>>>>>>> <jakob.korh...@gmail.com >>>>>>>>>> <mailto:jakob.korh...@gmail.com>> wrote: >>>>>>>>>> > Hi Bernd, >>>>>>>>>> > >>>>>>>>>> > If this module wouldn't be a part of myfaces >>>>>>>>>> core, the users still would >>>>>>>>>> > have to configure something to run their >>>>>>>>>> MyFaces-2 apps in a EE6 container >>>>>>>>>> > (e.g. they'd have to include myfaces >>>>>>>>>> commons), >>>>>>>>>> which is not the target. The >>>>>>>>>> > target is to get rid of any unnecessary >>>>>>>>>> configuration to make the >>>>>>>>>> > development process easier! >>>>>>>>>> > >>>>>>>>>> > Regards, >>>>>>>>>> > Jakob >>>>>>>>>> > >>>>>>>>>> > 2010/3/6 Bernd Bohmann >>>>>>>>>> <bernd.bohm...@googlemail.com >>>>>>>>>> <mailto:bernd.bohm...@googlemail.com>> >>>>>>>>>> >> >>>>>>>>>> >> Hello Jakob, >>>>>>>>>> >> >>>>>>>>>> >> I'm not really sure that this feature >>>>>>>>>> should be >>>>>>>>>> part of myfaces-core. >>>>>>>>>> >> Maybe myfaces-commons would be a better >>>>>>>>>> place. >>>>>>>>>> But we can change this >>>>>>>>>> >> later. >>>>>>>>>> >> >>>>>>>>>> >> +1 on commiting the module. >>>>>>>>>> >> >>>>>>>>>> >> Regards >>>>>>>>>> >> >>>>>>>>>> >> Bernd >>>>>>>>>> >> >>>>>>>>>> >> On Sat, Mar 6, 2010 at 4:32 PM, Jakob >>>>>>>>>> Korherr >>>>>>>>>> <jakob.korh...@gmail.com >>>>>>>>>> <mailto:jakob.korh...@gmail.com>> >>>>>>>>>> >> wrote: >>>>>>>>>> >> > Hi Jan-Kees, >>>>>>>>>> >> > >>>>>>>>>> >> > Great :) >>>>>>>>>> >> > >>>>>>>>>> >> > I am currently testing on Tomcat, Jetty, >>>>>>>>>> GlassFish v3 and JBoss 6! >>>>>>>>>> >> > >>>>>>>>>> >> > Regards, >>>>>>>>>> >> > Jakob >>>>>>>>>> >> > >>>>>>>>>> >> > 2010/3/6 Jan-Kees van Andel >>>>>>>>>> <jankeesvanan...@gmail.com >>>>>>>>>> <mailto:jankeesvanan...@gmail.com>> >>>>>>>>>> >> >> >>>>>>>>>> >> >> Hey, >>>>>>>>>> >> >> >>>>>>>>>> >> >> If it works on Jetty and Tomcat, I'd say >>>>>>>>>> +1 >>>>>>>>>> on committing the module. >>>>>>>>>> >> >> >>>>>>>>>> >> >> I can't think of big issues with >>>>>>>>>> committing >>>>>>>>>> it as a separate module. >>>>>>>>>> >> >> And >>>>>>>>>> >> >> we can always revert if we have to. >>>>>>>>>> >> >> >>>>>>>>>> >> >> Cool, can't wait to check it out! On >>>>>>>>>> what >>>>>>>>>> appserver are you testing >>>>>>>>>> >> >> this >>>>>>>>>> >> >> stuff Jakob? >>>>>>>>>> >> >> >>>>>>>>>> >> >> Regards, >>>>>>>>>> >> >> Jan-Kees >>>>>>>>>> >> >> >>>>>>>>>> >> >> >>>>>>>>>> >> >> 2010/3/6 Jakob Korherr >>>>>>>>>> <jakob.korh...@gmail.com >>>>>>>>>> <mailto:jakob.korh...@gmail.com>> >>>>>>>>>> >> >>> >>>>>>>>>> >> >>> Hi guys, >>>>>>>>>> >> >>> >>>>>>>>>> >> >>> I managed to introduce the core >>>>>>>>>> submodule >>>>>>>>>> "implee6" on my local >>>>>>>>>> >> >>> machine. >>>>>>>>>> >> >>> This new submodule includes Java EE 6 >>>>>>>>>> dependencies and thus you can >>>>>>>>>> >> >>> use >>>>>>>>>> >> >>> Servlet API 3.0 and other new things in >>>>>>>>>> it. >>>>>>>>>> >> >>> >>>>>>>>>> >> >>> When building MyFaces, this new >>>>>>>>>> submodule is >>>>>>>>>> built before the normal >>>>>>>>>> >> >>> impl >>>>>>>>>> >> >>> submodule. Then the .class and the >>>>>>>>>> .java >>>>>>>>>> files are "injected" into the >>>>>>>>>> >> >>> impl-build. This is very similar to how >>>>>>>>>> shared_impl is included in the >>>>>>>>>> >> >>> myfaces-impl build at the moment, but >>>>>>>>>> without recompilation. >>>>>>>>>> >> >>> >>>>>>>>>> >> >>> In this way we are able to use the new >>>>>>>>>> services approach of Java EE 6 >>>>>>>>>> >> >>> to >>>>>>>>>> >> >>> get rid of the Faces Servlet entries in >>>>>>>>>> web.xml, because in any Java >>>>>>>>>> >> >>> EE 6 >>>>>>>>>> >> >>> container we can configure this >>>>>>>>>> dynamically >>>>>>>>>> at startup (see >>>>>>>>>> >> >>> MYFACES-2579 for >>>>>>>>>> >> >>> details). This also works fantastically >>>>>>>>>> on >>>>>>>>>> my local machine - it's >>>>>>>>>> >> >>> really >>>>>>>>>> >> >>> cool! >>>>>>>>>> >> >>> >>>>>>>>>> >> >>> Also with this method we are still Java >>>>>>>>>> EE 5 >>>>>>>>>> complaint, because the EE >>>>>>>>>> >> >>> 6 >>>>>>>>>> >> >>> classes just won't get loaded in a non >>>>>>>>>> EE 6 >>>>>>>>>> environment, because there >>>>>>>>>> >> >>> are >>>>>>>>>> >> >>> no dependencies from impl or shared to >>>>>>>>>> them. >>>>>>>>>> They are only called (and >>>>>>>>>> >> >>> loaded) by a Java EE 6 container via >>>>>>>>>> the >>>>>>>>>> services definition. >>>>>>>>>> >> >>> >>>>>>>>>> >> >>> Furthermore I noticed that the Mojarra >>>>>>>>>> guys >>>>>>>>>> also include a similar >>>>>>>>>> >> >>> solution to this in their newest build! >>>>>>>>>> >> >>> >>>>>>>>>> >> >>> Now, before I commit something of this, >>>>>>>>>> I >>>>>>>>>> wanted to ask if there are >>>>>>>>>> >> >>> any >>>>>>>>>> >> >>> objections with this proposal. If so, >>>>>>>>>> please >>>>>>>>>> tell me your concerns! >>>>>>>>>> >> >>> >>>>>>>>>> >> >>> Regards, >>>>>>>>>> >> >>> Jakob >>>>>>>>>> >> >> >>>>>>>>>> >> > >>>>>>>>>> >> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > >
