Hi Try this one:
http://repo2.maven.org/maven2/org/mortbay/jetty/servlet-api/3.0.20100224/ It does not seem to have jdk 1.6 dependencies regards, Leonardo Uribe 2010/3/11 Jakob Korherr <jakob.korh...@gmail.com> > 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 <jakob.korh...@gmail.com> > > 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 <lu4...@gmail.com> >> >>> 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 >>>>>>>>>>>> >> >> >>>>>>>>>>>> >> > >>>>>>>>>>>> >> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
