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