Maybe we can use a dependency to Servlet API 3.0 which is compiled against JDK 5 instead of the javaee-web-api. Is there anything like that?
Regards, Jakob 2010/3/11 Jakob Korherr <[email protected]> > Hi, > > > "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." > > --> yeap! > > Of course this has to be documented and the mailing list (archive) is the > first place it already is, which, for sure, is great. In addition, I think > we should create a wiki-entry for this. > > Also and of course I think it is very important to have those discussions, > but they have to be constructive. Opening the same "problems" again and > again does not help anyone. Furthermore I openend this thread some days > before I committed anything and the response was very good. So I think I did > the right thing here. Nethertheless I know that it's not done with the > commit. This stuff has to be discussed further, but the commit was a way to > let everyone be able to test it for themselves. > > And your compilation error and your related concerns really do have to be > discussed. Really, thank's for pointing that out, because I did not run into > this error. However I _really_ can't imagine a scenario where this would > affect anything on MyFaces. I really don't. > > Regards, > Jakob > > > 2010/3/11 Leonardo Uribe <[email protected]> > >> Hi >> >> 2010/3/11 Jakob Korherr <[email protected]> >> >>> 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 <[email protected]> >>> >>>> 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 <[email protected]> >>>> >>>> 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 <[email protected]> >>>>> >>>>> 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 <[email protected]> >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> So I committed everything. Please feel free to test it - I am curious >>>>>>> about your opinions :) >>>>>>> >>>>>>> Regards, >>>>>>> Jakob >>>>>>> >>>>>>> 2010/3/8 Jakob Korherr <[email protected]> >>>>>>> >>>>>>> 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 <[email protected]> >>>>>>>> >>>>>>>> +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 <[email protected]> >>>>>>>>> >>>>>>>>> +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 <[email protected] >>>>>>>>>>> <mailto:[email protected]>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 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 <[email protected] >>>>>>>>>>> <mailto:[email protected]>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 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 <[email protected] >>>>>>>>>>> <mailto:[email protected]>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 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 <[email protected] >>>>>>>>>>> <mailto:[email protected]>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 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 < >>>>>>>>>>> [email protected] >>>>>>>>>>> <mailto:[email protected]>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 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 >>>>>>>>>>> <[email protected] >>>>>>>>>>> <mailto:[email protected]>> 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 >>>>>>>>>>> <[email protected] >>>>>>>>>>> <mailto:[email protected]>> >>>>>>>>>>> >>>>>>>>>>> >> >>>>>>>>>>> >> 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 >>>>>>>>>>> <[email protected] >>>>>>>>>>> <mailto:[email protected]>> >>>>>>>>>>> >>>>>>>>>>> >> 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 >>>>>>>>>>> <[email protected] >>>>>>>>>>> <mailto:[email protected]>> >>>>>>>>>>> >>>>>>>>>>> >> >> >>>>>>>>>>> >> >> 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 >>>>>>>>>>> <[email protected] >>>>>>>>>>> <mailto:[email protected]>> >>>>>>>>>>> >>>>>>>>>>> >> >>> >>>>>>>>>>> >> >>> 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 >>>>>>>>>>> >> >> >>>>>>>>>>> >> > >>>>>>>>>>> >> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
