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