Since there don't seem to be any big concerns about this, I will now commit the new submodule "implee6".


2010/3/8 Gerhard Petracek <gerhard.petracek@gmail.com>



Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

2010/3/8 Werner Punz <werner.punz@gmail.com>

+1 for that idea, the less configuration the better.


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!


2010/3/7 Jan-Kees van Andel <jankeesvanandel@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

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


   2010/3/7 Jakob Korherr <jakob.korherr@gmail.com


       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.


       2010/3/7 Jan-Kees van Andel <jankeesvanandel@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...


           2010/3/7 Jakob Korherr <jakob.korherr@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.


               2010/3/6 Bernd Bohmann <bernd.bohmann@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?



                   On Sat, Mar 6, 2010 at 4:48 PM, Jakob Korherr
                   <mailto:jakob.korherr@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

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

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

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

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