+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 >> >> >> >> >> > >> >> > >> > >> > >> >> >> >> >> >> >> > >
