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