You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Jakob Korherr <ja...@gmail.com> on 2010/03/06 15:33:52 UTC
[core] Introducing implee6 - MYFACES-2579
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
Re: [core] Introducing implee6 - MYFACES-2579
Posted by Jan-Kees van Andel <ja...@gmail.com>.
Interesting discussion. I agree with Jakob about the plug-and-play
requirement. The module doesn't make much sense without this. Also the point
about Mojarra sounds valid.
But on the other hand, Leonardo is right that Prio #1 should always be a
valid implementation. Also, removing stuff from a library is more difficult
than adding stuff.
I personally can imagine only one issue: When users use some annotation
scanner like ASM to load several classes from the classpath and this class
gets loaded accidentally, they may end up with a problem. But I don't think
this is an issue we should take responsibility for. For example, Spring also
uses JDK 6 classes, but is still usable with JDK 5. You just can't take
advantage of some new features, but it is backwards compatible.
Maybe a slightly different option might be to release two versions: A
Servlet 3 version (with JDK 6 dependency) and a normal version without the
implee6 module.
I see lots of projects doing similar stuff, but I don't know how it works
for a project that implements an official spec.
/JK
2010/3/12 Leonardo Uribe <lu...@gmail.com>
> Hi
>
> It seems the problem is that servlet 3.0 api requires jdk 1.6 to compile,
> and the classes we are using on implee6 has dependencies. That means, the
> classes on implee6 has version 49 but the ones in servlet 3.0 has version
> 50. The ones here:
>
>
> http://repo2.maven.org/maven2/org/mortbay/jetty/servlet-api/3.0.PFD20090525/
>
> compiles against JDK 1.5 but does not contains the required classes used on
> implee6. We have to let it as is.
>
>
> regards,
>
> Leonardo Uribe
>
> 2010/3/11 Jakob Korherr <ja...@gmail.com>
>
>> Hi,
>>
>> Thanks Leonardo! I just tried this out locally and it worked fine. So I'll
>> commit this for now!
>>
>>
>> Regards,
>> Jakob
>>
>> 2010/3/11 Leonardo Uribe <lu...@gmail.com>
>>
>>> Hi
>>>
>>> Try this one:
>>>
>>> http://repo2.maven.org/maven2/org/mortbay/jetty/servlet-api/3.0.20100224/
>>>
>>> It does not seem to have jdk 1.6 dependencies
>>>
>>> regards,
>>>
>>> Leonardo Uribe
>>>
>>>
>>> 2010/3/11 Jakob Korherr <ja...@gmail.com>
>>>
>>>> Maybe we can use a dependency to Servlet API 3.0 which is compiled
>>>> against JDK 5 instead of the javaee-web-api. Is there anything like that?
>>>>
>>>> Regards,
>>>> Jakob
>>>>
>>>> 2010/3/11 Jakob Korherr <ja...@gmail.com>
>>>>
>>>> Hi,
>>>>>
>>>>>
>>>>> "So the change has no sense outside myfaces impl jar. That means we
>>>>> only have two options: do it like this or remove the code."
>>>>>
>>>>> --> yeap!
>>>>>
>>>>> Of course this has to be documented and the mailing list (archive) is
>>>>> the first place it already is, which, for sure, is great. In addition, I
>>>>> think we should create a wiki-entry for this.
>>>>>
>>>>> Also and of course I think it is very important to have those
>>>>> discussions, but they have to be constructive. Opening the same "problems"
>>>>> again and again does not help anyone. Furthermore I openend this thread some
>>>>> days before I committed anything and the response was very good. So I think
>>>>> I did the right thing here. Nethertheless I know that it's not done with the
>>>>> commit. This stuff has to be discussed further, but the commit was a way to
>>>>> let everyone be able to test it for themselves.
>>>>>
>>>>> And your compilation error and your related concerns really do have to
>>>>> be discussed. Really, thank's for pointing that out, because I did not run
>>>>> into this error. However I _really_ can't imagine a scenario where this
>>>>> would affect anything on MyFaces. I really don't.
>>>>>
>>>>> Regards,
>>>>> Jakob
>>>>>
>>>>>
>>>>> 2010/3/11 Leonardo Uribe <lu...@gmail.com>
>>>>>
>>>>>> Hi
>>>>>>
>>>>>> 2010/3/11 Jakob Korherr <ja...@gmail.com>
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I totally agree with Jan-Kees. Just override the compiler plugin in
>>>>>>> implee6 to use jdk 6!
>>>>>>>
>>>>>>> Also I really don't see why you think it is such a big problem to
>>>>>>> have a class in the jar file which has other dependencies and another
>>>>>>> version when no other class has any relations to it. It's like a website
>>>>>>> with no link referring to it: you will never find it unless you know the
>>>>>>> real address of it!
>>>>>>>
>>>>>>> Furthermore if we put it into myfaces commons we can also drop it,
>>>>>>> because then it makes no sence. The user will rather continue to use the
>>>>>>> web.xml configuration than bundling some jar, which he maybe does not know
>>>>>>> that it even exists..
>>>>>>>
>>>>>>>
>>>>>> So the change has no sense outside myfaces impl jar. That means we
>>>>>> only have two options: do it like this or remove the code.
>>>>>>
>>>>>>
>>>>>>> And last but not least: Mojarra also has a similar JDK6 compiled
>>>>>>> class with Java EE 6 dependencies in their jsf-impl.jar. So why would it be
>>>>>>> a problem for MyFaces?
>>>>>>>
>>>>>>>
>>>>>> The position from jsr-314-open mail list is as long as TCK test pass
>>>>>> we could do it, and if mojarra has something similar, we could do the same.
>>>>>> If something happens we could remove it and that's all (that means if
>>>>>> something happens we'll be forced to remove this feature from myfaces and
>>>>>> that is risky), since this is not part of the standard, but users should be
>>>>>> aware of that implication. Note from this change, myfaces requires JDK 1.6
>>>>>> to be compiled, but the classes inside api and impl modules requires JDK
>>>>>> 1.5.
>>>>>>
>>>>>>
>>>>>>> Please don't make this problem bigger as it is...
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> I believe it is important to discuss the possible implications of a
>>>>>> change before commit it and make it clear to people (that's one idea about
>>>>>> opensource, give the people the power to know what's happening behind
>>>>>> courtains and the tools to change it). Just put some code because you like
>>>>>> it, or it is cool not always is enough. That's common sense, right?. Also
>>>>>> you have to keep into account this is a standard of some spec, not just a
>>>>>> custom library, so a lot of care is required before add a new feature
>>>>>> outside the spec. So, the idea is not make a problem bigger or start a
>>>>>> bizantine war that leads to nowhere, just benefit the community throught
>>>>>> constructive discussion, but for a discussion it is necessary a clear and
>>>>>> rational position, possible courses of action before start and a "open"
>>>>>> mind, that means, give yourself the possibility of change of opinion
>>>>>> anytime. Please note the benefit of this exercise, if someone wants to check
>>>>>> why this stuff is done in this or that way, there is a source of knowledge
>>>>>> through the mailing list. Please think carefully about what "opensource"
>>>>>> word means.
>>>>>>
>>>>>> regards,
>>>>>>
>>>>>> Leonardo Uribe
>>>>>>
>>>>>>
>>>>>>> Regards,
>>>>>>> Jakob
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2010/3/11 Leonardo Uribe <lu...@gmail.com>
>>>>>>>
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> I have sended an email to jsr-314-open mail list just to confirm if
>>>>>>>> it is valid or not to do this kind of stuff. The problem is the class
>>>>>>>> involved on implee6 has dependencies with classes that needs JDK 6 to be
>>>>>>>> compiled, so in a JDK 1.5 environment it will crash if the classes are
>>>>>>>> loaded. It is true ease of development will suffer, but I think prevent bugs
>>>>>>>> like this takes precedence.
>>>>>>>>
>>>>>>>> regards,
>>>>>>>>
>>>>>>>> Leonardo Uribe
>>>>>>>>
>>>>>>>> 2010/3/11 Jan-Kees van Andel <ja...@gmail.com>
>>>>>>>>
>>>>>>>> Why not override the compiler plugin in the module to use JDK 6?
>>>>>>>>>
>>>>>>>>> I think the whole point about the module is ease of development and
>>>>>>>>> this will suffer when putting it in a separate jar.
>>>>>>>>>
>>>>>>>>> About the manual classpath scanning or other runtime stuff. This
>>>>>>>>> should not break because of JDK 6 stuff, since the bytecode should be
>>>>>>>>> backwards compatible.
>>>>>>>>>
>>>>>>>>> My 2 cents...
>>>>>>>>>
>>>>>>>>> /JK
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2010/3/11 Leonardo Uribe <lu...@gmail.com>
>>>>>>>>>
>>>>>>>>> Hi
>>>>>>>>>>
>>>>>>>>>> I'm working with jdk 1.5 and when I tried to compile current20
>>>>>>>>>> branch I have an error. This means to create myfaces jars it should be
>>>>>>>>>> compiled with jdk 1.6, because implee6 has dependencies with jars with java
>>>>>>>>>> 1.6 specific code:
>>>>>>>>>>
>>>>>>>>>> [INFO]
>>>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>>> [ERROR] BUILD FAILURE
>>>>>>>>>> [INFO]
>>>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>>> [INFO] Compilation failure
>>>>>>>>>>
>>>>>>>>>> D:\workspace\myfaces\current20\core\implee6\src\main\java\org\apache\myfaces\ee6
>>>>>>>>>> \MyFacesContainerInitializer.java:[47,-1] cannot access
>>>>>>>>>> javax.servlet.ServletCon
>>>>>>>>>> tainerInitializer
>>>>>>>>>> bad class file: C:\Documents and
>>>>>>>>>> Settings\lu4242\.m2\repository\javax\javaee-web
>>>>>>>>>>
>>>>>>>>>> -api\6.0\javaee-web-api-6.0.jar(javax/servlet/ServletContainerInitializer.class)
>>>>>>>>>>
>>>>>>>>>> class file has wrong version 50.0, should be 49.0
>>>>>>>>>>
>>>>>>>>>> In theory, we can't do this, because if we do, myfaces-impl has
>>>>>>>>>> one class jdk 1.6 specific, and jsf 2.0 is jdk 1.5 compatible. Now, in the
>>>>>>>>>> practice this class is not loaded by any part of myfaces, but maybe some
>>>>>>>>>> program that tries to scan the classpath and load this class into the
>>>>>>>>>> classpath will see the problem.
>>>>>>>>>>
>>>>>>>>>> My personal opinion is implee6 should have its own separate jar
>>>>>>>>>> with some OSGi specific stuff, so if someone wants to use it it should put
>>>>>>>>>> three jars on the classpath: myfaces-api, myfaces-impl, myfaces-implee6. We
>>>>>>>>>> have a lot of precedences for that kind of stuff (orchestra core and core15
>>>>>>>>>> for example, tomahawk sandbox and sandbox15).
>>>>>>>>>>
>>>>>>>>>> I also think this code should be moved to myfaces commons, because
>>>>>>>>>> keep it as a module in core project means we have to use jdk 1.6 to compile
>>>>>>>>>> all artifacts and we have a plugin that checks for jdk 1.5 compatibility
>>>>>>>>>> that will fail (see checkJDK profile on myfaces impl pom).
>>>>>>>>>>
>>>>>>>>>> Suggestions are welcome.
>>>>>>>>>>
>>>>>>>>>> regards,
>>>>>>>>>>
>>>>>>>>>> Leonardo Uribe
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2010/3/8 Jakob Korherr <ja...@gmail.com>
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> So I committed everything. Please feel free to test it - I am
>>>>>>>>>>> curious about your opinions :)
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Jakob
>>>>>>>>>>>
>>>>>>>>>>> 2010/3/8 Jakob Korherr <ja...@gmail.com>
>>>>>>>>>>>
>>>>>>>>>>> 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 <ge...@gmail.com>
>>>>>>>>>>>>
>>>>>>>>>>>> +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 <we...@gmail.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>> +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 <jankeesvanandel@gmail.com
>>>>>>>>>>>>>>> <ma...@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.korherr@gmail.com
>>>>>>>>>>>>>>> <ma...@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 <
>>>>>>>>>>>>>>> jankeesvanandel@gmail.com
>>>>>>>>>>>>>>> <ma...@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.korherr@gmail.com
>>>>>>>>>>>>>>> <ma...@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.bohmann@googlemail.com
>>>>>>>>>>>>>>> <ma...@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.korherr@gmail.com
>>>>>>>>>>>>>>> <ma...@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.bohmann@googlemail.com
>>>>>>>>>>>>>>> <ma...@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.korherr@gmail.com
>>>>>>>>>>>>>>> <ma...@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
>>>>>>>>>>>>>>> <jankeesvanandel@gmail.com
>>>>>>>>>>>>>>> <ma...@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.korherr@gmail.com
>>>>>>>>>>>>>>> <ma...@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
>>>>>>>>>>>>>>> >> >>
>>>>>>>>>>>>>>> >> >
>>>>>>>>>>>>>>> >> >
>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: [core] Introducing implee6 - MYFACES-2579
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi
It seems the problem is that servlet 3.0 api requires jdk 1.6 to compile,
and the classes we are using on implee6 has dependencies. That means, the
classes on implee6 has version 49 but the ones in servlet 3.0 has version
50. The ones here:
http://repo2.maven.org/maven2/org/mortbay/jetty/servlet-api/3.0.PFD20090525/
compiles against JDK 1.5 but does not contains the required classes used on
implee6. We have to let it as is.
regards,
Leonardo Uribe
2010/3/11 Jakob Korherr <ja...@gmail.com>
> Hi,
>
> Thanks Leonardo! I just tried this out locally and it worked fine. So I'll
> commit this for now!
>
>
> Regards,
> Jakob
>
> 2010/3/11 Leonardo Uribe <lu...@gmail.com>
>
>> Hi
>>
>> Try this one:
>>
>> http://repo2.maven.org/maven2/org/mortbay/jetty/servlet-api/3.0.20100224/
>>
>> It does not seem to have jdk 1.6 dependencies
>>
>> regards,
>>
>> Leonardo Uribe
>>
>>
>> 2010/3/11 Jakob Korherr <ja...@gmail.com>
>>
>>> Maybe we can use a dependency to Servlet API 3.0 which is compiled
>>> against JDK 5 instead of the javaee-web-api. Is there anything like that?
>>>
>>> Regards,
>>> Jakob
>>>
>>> 2010/3/11 Jakob Korherr <ja...@gmail.com>
>>>
>>> Hi,
>>>>
>>>>
>>>> "So the change has no sense outside myfaces impl jar. That means we only
>>>> have two options: do it like this or remove the code."
>>>>
>>>> --> yeap!
>>>>
>>>> Of course this has to be documented and the mailing list (archive) is
>>>> the first place it already is, which, for sure, is great. In addition, I
>>>> think we should create a wiki-entry for this.
>>>>
>>>> Also and of course I think it is very important to have those
>>>> discussions, but they have to be constructive. Opening the same "problems"
>>>> again and again does not help anyone. Furthermore I openend this thread some
>>>> days before I committed anything and the response was very good. So I think
>>>> I did the right thing here. Nethertheless I know that it's not done with the
>>>> commit. This stuff has to be discussed further, but the commit was a way to
>>>> let everyone be able to test it for themselves.
>>>>
>>>> And your compilation error and your related concerns really do have to
>>>> be discussed. Really, thank's for pointing that out, because I did not run
>>>> into this error. However I _really_ can't imagine a scenario where this
>>>> would affect anything on MyFaces. I really don't.
>>>>
>>>> Regards,
>>>> Jakob
>>>>
>>>>
>>>> 2010/3/11 Leonardo Uribe <lu...@gmail.com>
>>>>
>>>>> Hi
>>>>>
>>>>> 2010/3/11 Jakob Korherr <ja...@gmail.com>
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I totally agree with Jan-Kees. Just override the compiler plugin in
>>>>>> implee6 to use jdk 6!
>>>>>>
>>>>>> Also I really don't see why you think it is such a big problem to have
>>>>>> a class in the jar file which has other dependencies and another version
>>>>>> when no other class has any relations to it. It's like a website with no
>>>>>> link referring to it: you will never find it unless you know the real
>>>>>> address of it!
>>>>>>
>>>>>> Furthermore if we put it into myfaces commons we can also drop it,
>>>>>> because then it makes no sence. The user will rather continue to use the
>>>>>> web.xml configuration than bundling some jar, which he maybe does not know
>>>>>> that it even exists..
>>>>>>
>>>>>>
>>>>> So the change has no sense outside myfaces impl jar. That means we only
>>>>> have two options: do it like this or remove the code.
>>>>>
>>>>>
>>>>>> And last but not least: Mojarra also has a similar JDK6 compiled class
>>>>>> with Java EE 6 dependencies in their jsf-impl.jar. So why would it be a
>>>>>> problem for MyFaces?
>>>>>>
>>>>>>
>>>>> The position from jsr-314-open mail list is as long as TCK test pass we
>>>>> could do it, and if mojarra has something similar, we could do the same. If
>>>>> something happens we could remove it and that's all (that means if something
>>>>> happens we'll be forced to remove this feature from myfaces and that is
>>>>> risky), since this is not part of the standard, but users should be aware of
>>>>> that implication. Note from this change, myfaces requires JDK 1.6 to be
>>>>> compiled, but the classes inside api and impl modules requires JDK 1.5.
>>>>>
>>>>>
>>>>>> Please don't make this problem bigger as it is...
>>>>>>
>>>>>>
>>>>>
>>>>> I believe it is important to discuss the possible implications of a
>>>>> change before commit it and make it clear to people (that's one idea about
>>>>> opensource, give the people the power to know what's happening behind
>>>>> courtains and the tools to change it). Just put some code because you like
>>>>> it, or it is cool not always is enough. That's common sense, right?. Also
>>>>> you have to keep into account this is a standard of some spec, not just a
>>>>> custom library, so a lot of care is required before add a new feature
>>>>> outside the spec. So, the idea is not make a problem bigger or start a
>>>>> bizantine war that leads to nowhere, just benefit the community throught
>>>>> constructive discussion, but for a discussion it is necessary a clear and
>>>>> rational position, possible courses of action before start and a "open"
>>>>> mind, that means, give yourself the possibility of change of opinion
>>>>> anytime. Please note the benefit of this exercise, if someone wants to check
>>>>> why this stuff is done in this or that way, there is a source of knowledge
>>>>> through the mailing list. Please think carefully about what "opensource"
>>>>> word means.
>>>>>
>>>>> regards,
>>>>>
>>>>> Leonardo Uribe
>>>>>
>>>>>
>>>>>> Regards,
>>>>>> Jakob
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2010/3/11 Leonardo Uribe <lu...@gmail.com>
>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> I have sended an email to jsr-314-open mail list just to confirm if
>>>>>>> it is valid or not to do this kind of stuff. The problem is the class
>>>>>>> involved on implee6 has dependencies with classes that needs JDK 6 to be
>>>>>>> compiled, so in a JDK 1.5 environment it will crash if the classes are
>>>>>>> loaded. It is true ease of development will suffer, but I think prevent bugs
>>>>>>> like this takes precedence.
>>>>>>>
>>>>>>> regards,
>>>>>>>
>>>>>>> Leonardo Uribe
>>>>>>>
>>>>>>> 2010/3/11 Jan-Kees van Andel <ja...@gmail.com>
>>>>>>>
>>>>>>> Why not override the compiler plugin in the module to use JDK 6?
>>>>>>>>
>>>>>>>> I think the whole point about the module is ease of development and
>>>>>>>> this will suffer when putting it in a separate jar.
>>>>>>>>
>>>>>>>> About the manual classpath scanning or other runtime stuff. This
>>>>>>>> should not break because of JDK 6 stuff, since the bytecode should be
>>>>>>>> backwards compatible.
>>>>>>>>
>>>>>>>> My 2 cents...
>>>>>>>>
>>>>>>>> /JK
>>>>>>>>
>>>>>>>>
>>>>>>>> 2010/3/11 Leonardo Uribe <lu...@gmail.com>
>>>>>>>>
>>>>>>>> Hi
>>>>>>>>>
>>>>>>>>> I'm working with jdk 1.5 and when I tried to compile current20
>>>>>>>>> branch I have an error. This means to create myfaces jars it should be
>>>>>>>>> compiled with jdk 1.6, because implee6 has dependencies with jars with java
>>>>>>>>> 1.6 specific code:
>>>>>>>>>
>>>>>>>>> [INFO]
>>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>> [ERROR] BUILD FAILURE
>>>>>>>>> [INFO]
>>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>> [INFO] Compilation failure
>>>>>>>>>
>>>>>>>>> D:\workspace\myfaces\current20\core\implee6\src\main\java\org\apache\myfaces\ee6
>>>>>>>>> \MyFacesContainerInitializer.java:[47,-1] cannot access
>>>>>>>>> javax.servlet.ServletCon
>>>>>>>>> tainerInitializer
>>>>>>>>> bad class file: C:\Documents and
>>>>>>>>> Settings\lu4242\.m2\repository\javax\javaee-web
>>>>>>>>>
>>>>>>>>> -api\6.0\javaee-web-api-6.0.jar(javax/servlet/ServletContainerInitializer.class)
>>>>>>>>>
>>>>>>>>> class file has wrong version 50.0, should be 49.0
>>>>>>>>>
>>>>>>>>> In theory, we can't do this, because if we do, myfaces-impl has one
>>>>>>>>> class jdk 1.6 specific, and jsf 2.0 is jdk 1.5 compatible. Now, in the
>>>>>>>>> practice this class is not loaded by any part of myfaces, but maybe some
>>>>>>>>> program that tries to scan the classpath and load this class into the
>>>>>>>>> classpath will see the problem.
>>>>>>>>>
>>>>>>>>> My personal opinion is implee6 should have its own separate jar
>>>>>>>>> with some OSGi specific stuff, so if someone wants to use it it should put
>>>>>>>>> three jars on the classpath: myfaces-api, myfaces-impl, myfaces-implee6. We
>>>>>>>>> have a lot of precedences for that kind of stuff (orchestra core and core15
>>>>>>>>> for example, tomahawk sandbox and sandbox15).
>>>>>>>>>
>>>>>>>>> I also think this code should be moved to myfaces commons, because
>>>>>>>>> keep it as a module in core project means we have to use jdk 1.6 to compile
>>>>>>>>> all artifacts and we have a plugin that checks for jdk 1.5 compatibility
>>>>>>>>> that will fail (see checkJDK profile on myfaces impl pom).
>>>>>>>>>
>>>>>>>>> Suggestions are welcome.
>>>>>>>>>
>>>>>>>>> regards,
>>>>>>>>>
>>>>>>>>> Leonardo Uribe
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2010/3/8 Jakob Korherr <ja...@gmail.com>
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> So I committed everything. Please feel free to test it - I am
>>>>>>>>>> curious about your opinions :)
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Jakob
>>>>>>>>>>
>>>>>>>>>> 2010/3/8 Jakob Korherr <ja...@gmail.com>
>>>>>>>>>>
>>>>>>>>>> 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 <ge...@gmail.com>
>>>>>>>>>>>
>>>>>>>>>>> +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 <we...@gmail.com>
>>>>>>>>>>>>
>>>>>>>>>>>> +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 <jankeesvanandel@gmail.com
>>>>>>>>>>>>>> <ma...@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.korherr@gmail.com
>>>>>>>>>>>>>> <ma...@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 <jankeesvanandel@gmail.com
>>>>>>>>>>>>>> <ma...@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.korherr@gmail.com
>>>>>>>>>>>>>> <ma...@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.bohmann@googlemail.com
>>>>>>>>>>>>>> <ma...@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.korherr@gmail.com
>>>>>>>>>>>>>> <ma...@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.bohmann@googlemail.com
>>>>>>>>>>>>>> <ma...@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.korherr@gmail.com
>>>>>>>>>>>>>> <ma...@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
>>>>>>>>>>>>>> <jankeesvanandel@gmail.com
>>>>>>>>>>>>>> <ma...@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.korherr@gmail.com
>>>>>>>>>>>>>> <ma...@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
>>>>>>>>>>>>>> >> >>
>>>>>>>>>>>>>> >> >
>>>>>>>>>>>>>> >> >
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: [core] Introducing implee6 - MYFACES-2579
Posted by Jakob Korherr <ja...@gmail.com>.
Hi,
Thanks Leonardo! I just tried this out locally and it worked fine. So I'll
commit this for now!
Regards,
Jakob
2010/3/11 Leonardo Uribe <lu...@gmail.com>
> Hi
>
> Try this one:
>
> http://repo2.maven.org/maven2/org/mortbay/jetty/servlet-api/3.0.20100224/
>
> It does not seem to have jdk 1.6 dependencies
>
> regards,
>
> Leonardo Uribe
>
>
> 2010/3/11 Jakob Korherr <ja...@gmail.com>
>
>> Maybe we can use a dependency to Servlet API 3.0 which is compiled against
>> JDK 5 instead of the javaee-web-api. Is there anything like that?
>>
>> Regards,
>> Jakob
>>
>> 2010/3/11 Jakob Korherr <ja...@gmail.com>
>>
>> Hi,
>>>
>>>
>>> "So the change has no sense outside myfaces impl jar. That means we only
>>> have two options: do it like this or remove the code."
>>>
>>> --> yeap!
>>>
>>> Of course this has to be documented and the mailing list (archive) is the
>>> first place it already is, which, for sure, is great. In addition, I think
>>> we should create a wiki-entry for this.
>>>
>>> Also and of course I think it is very important to have those
>>> discussions, but they have to be constructive. Opening the same "problems"
>>> again and again does not help anyone. Furthermore I openend this thread some
>>> days before I committed anything and the response was very good. So I think
>>> I did the right thing here. Nethertheless I know that it's not done with the
>>> commit. This stuff has to be discussed further, but the commit was a way to
>>> let everyone be able to test it for themselves.
>>>
>>> And your compilation error and your related concerns really do have to be
>>> discussed. Really, thank's for pointing that out, because I did not run into
>>> this error. However I _really_ can't imagine a scenario where this would
>>> affect anything on MyFaces. I really don't.
>>>
>>> Regards,
>>> Jakob
>>>
>>>
>>> 2010/3/11 Leonardo Uribe <lu...@gmail.com>
>>>
>>>> Hi
>>>>
>>>> 2010/3/11 Jakob Korherr <ja...@gmail.com>
>>>>
>>>>> Hi,
>>>>>
>>>>> I totally agree with Jan-Kees. Just override the compiler plugin in
>>>>> implee6 to use jdk 6!
>>>>>
>>>>> Also I really don't see why you think it is such a big problem to have
>>>>> a class in the jar file which has other dependencies and another version
>>>>> when no other class has any relations to it. It's like a website with no
>>>>> link referring to it: you will never find it unless you know the real
>>>>> address of it!
>>>>>
>>>>> Furthermore if we put it into myfaces commons we can also drop it,
>>>>> because then it makes no sence. The user will rather continue to use the
>>>>> web.xml configuration than bundling some jar, which he maybe does not know
>>>>> that it even exists..
>>>>>
>>>>>
>>>> So the change has no sense outside myfaces impl jar. That means we only
>>>> have two options: do it like this or remove the code.
>>>>
>>>>
>>>>> And last but not least: Mojarra also has a similar JDK6 compiled class
>>>>> with Java EE 6 dependencies in their jsf-impl.jar. So why would it be a
>>>>> problem for MyFaces?
>>>>>
>>>>>
>>>> The position from jsr-314-open mail list is as long as TCK test pass we
>>>> could do it, and if mojarra has something similar, we could do the same. If
>>>> something happens we could remove it and that's all (that means if something
>>>> happens we'll be forced to remove this feature from myfaces and that is
>>>> risky), since this is not part of the standard, but users should be aware of
>>>> that implication. Note from this change, myfaces requires JDK 1.6 to be
>>>> compiled, but the classes inside api and impl modules requires JDK 1.5.
>>>>
>>>>
>>>>> Please don't make this problem bigger as it is...
>>>>>
>>>>>
>>>>
>>>> I believe it is important to discuss the possible implications of a
>>>> change before commit it and make it clear to people (that's one idea about
>>>> opensource, give the people the power to know what's happening behind
>>>> courtains and the tools to change it). Just put some code because you like
>>>> it, or it is cool not always is enough. That's common sense, right?. Also
>>>> you have to keep into account this is a standard of some spec, not just a
>>>> custom library, so a lot of care is required before add a new feature
>>>> outside the spec. So, the idea is not make a problem bigger or start a
>>>> bizantine war that leads to nowhere, just benefit the community throught
>>>> constructive discussion, but for a discussion it is necessary a clear and
>>>> rational position, possible courses of action before start and a "open"
>>>> mind, that means, give yourself the possibility of change of opinion
>>>> anytime. Please note the benefit of this exercise, if someone wants to check
>>>> why this stuff is done in this or that way, there is a source of knowledge
>>>> through the mailing list. Please think carefully about what "opensource"
>>>> word means.
>>>>
>>>> regards,
>>>>
>>>> Leonardo Uribe
>>>>
>>>>
>>>>> Regards,
>>>>> Jakob
>>>>>
>>>>>
>>>>>
>>>>> 2010/3/11 Leonardo Uribe <lu...@gmail.com>
>>>>>
>>>>>> Hi
>>>>>>
>>>>>> I have sended an email to jsr-314-open mail list just to confirm if it
>>>>>> is valid or not to do this kind of stuff. The problem is the class involved
>>>>>> on implee6 has dependencies with classes that needs JDK 6 to be compiled, so
>>>>>> in a JDK 1.5 environment it will crash if the classes are loaded. It is true
>>>>>> ease of development will suffer, but I think prevent bugs like this takes
>>>>>> precedence.
>>>>>>
>>>>>> regards,
>>>>>>
>>>>>> Leonardo Uribe
>>>>>>
>>>>>> 2010/3/11 Jan-Kees van Andel <ja...@gmail.com>
>>>>>>
>>>>>> Why not override the compiler plugin in the module to use JDK 6?
>>>>>>>
>>>>>>> I think the whole point about the module is ease of development and
>>>>>>> this will suffer when putting it in a separate jar.
>>>>>>>
>>>>>>> About the manual classpath scanning or other runtime stuff. This
>>>>>>> should not break because of JDK 6 stuff, since the bytecode should be
>>>>>>> backwards compatible.
>>>>>>>
>>>>>>> My 2 cents...
>>>>>>>
>>>>>>> /JK
>>>>>>>
>>>>>>>
>>>>>>> 2010/3/11 Leonardo Uribe <lu...@gmail.com>
>>>>>>>
>>>>>>> Hi
>>>>>>>>
>>>>>>>> I'm working with jdk 1.5 and when I tried to compile current20
>>>>>>>> branch I have an error. This means to create myfaces jars it should be
>>>>>>>> compiled with jdk 1.6, because implee6 has dependencies with jars with java
>>>>>>>> 1.6 specific code:
>>>>>>>>
>>>>>>>> [INFO]
>>>>>>>> ------------------------------------------------------------------------
>>>>>>>> [ERROR] BUILD FAILURE
>>>>>>>> [INFO]
>>>>>>>> ------------------------------------------------------------------------
>>>>>>>> [INFO] Compilation failure
>>>>>>>>
>>>>>>>> D:\workspace\myfaces\current20\core\implee6\src\main\java\org\apache\myfaces\ee6
>>>>>>>> \MyFacesContainerInitializer.java:[47,-1] cannot access
>>>>>>>> javax.servlet.ServletCon
>>>>>>>> tainerInitializer
>>>>>>>> bad class file: C:\Documents and
>>>>>>>> Settings\lu4242\.m2\repository\javax\javaee-web
>>>>>>>>
>>>>>>>> -api\6.0\javaee-web-api-6.0.jar(javax/servlet/ServletContainerInitializer.class)
>>>>>>>>
>>>>>>>> class file has wrong version 50.0, should be 49.0
>>>>>>>>
>>>>>>>> In theory, we can't do this, because if we do, myfaces-impl has one
>>>>>>>> class jdk 1.6 specific, and jsf 2.0 is jdk 1.5 compatible. Now, in the
>>>>>>>> practice this class is not loaded by any part of myfaces, but maybe some
>>>>>>>> program that tries to scan the classpath and load this class into the
>>>>>>>> classpath will see the problem.
>>>>>>>>
>>>>>>>> My personal opinion is implee6 should have its own separate jar with
>>>>>>>> some OSGi specific stuff, so if someone wants to use it it should put three
>>>>>>>> jars on the classpath: myfaces-api, myfaces-impl, myfaces-implee6. We have a
>>>>>>>> lot of precedences for that kind of stuff (orchestra core and core15 for
>>>>>>>> example, tomahawk sandbox and sandbox15).
>>>>>>>>
>>>>>>>> I also think this code should be moved to myfaces commons, because
>>>>>>>> keep it as a module in core project means we have to use jdk 1.6 to compile
>>>>>>>> all artifacts and we have a plugin that checks for jdk 1.5 compatibility
>>>>>>>> that will fail (see checkJDK profile on myfaces impl pom).
>>>>>>>>
>>>>>>>> Suggestions are welcome.
>>>>>>>>
>>>>>>>> regards,
>>>>>>>>
>>>>>>>> Leonardo Uribe
>>>>>>>>
>>>>>>>>
>>>>>>>> 2010/3/8 Jakob Korherr <ja...@gmail.com>
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> So I committed everything. Please feel free to test it - I am
>>>>>>>>> curious about your opinions :)
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Jakob
>>>>>>>>>
>>>>>>>>> 2010/3/8 Jakob Korherr <ja...@gmail.com>
>>>>>>>>>
>>>>>>>>> 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 <ge...@gmail.com>
>>>>>>>>>>
>>>>>>>>>> +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 <we...@gmail.com>
>>>>>>>>>>>
>>>>>>>>>>> +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 <jankeesvanandel@gmail.com
>>>>>>>>>>>>> <ma...@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.korherr@gmail.com
>>>>>>>>>>>>> <ma...@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 <jankeesvanandel@gmail.com
>>>>>>>>>>>>> <ma...@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.korherr@gmail.com
>>>>>>>>>>>>> <ma...@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.bohmann@googlemail.com
>>>>>>>>>>>>> <ma...@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.korherr@gmail.com
>>>>>>>>>>>>> <ma...@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.bohmann@googlemail.com
>>>>>>>>>>>>> <ma...@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.korherr@gmail.com
>>>>>>>>>>>>> <ma...@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
>>>>>>>>>>>>> <jankeesvanandel@gmail.com
>>>>>>>>>>>>> <ma...@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.korherr@gmail.com
>>>>>>>>>>>>> <ma...@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
>>>>>>>>>>>>> >> >>
>>>>>>>>>>>>> >> >
>>>>>>>>>>>>> >> >
>>>>>>>>>>>>> >
>>>>>>>>>>>>> >
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: [core] Introducing implee6 - MYFACES-2579
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi
Try this one:
http://repo2.maven.org/maven2/org/mortbay/jetty/servlet-api/3.0.20100224/
It does not seem to have jdk 1.6 dependencies
regards,
Leonardo Uribe
2010/3/11 Jakob Korherr <ja...@gmail.com>
> Maybe we can use a dependency to Servlet API 3.0 which is compiled against
> JDK 5 instead of the javaee-web-api. Is there anything like that?
>
> Regards,
> Jakob
>
> 2010/3/11 Jakob Korherr <ja...@gmail.com>
>
> Hi,
>>
>>
>> "So the change has no sense outside myfaces impl jar. That means we only
>> have two options: do it like this or remove the code."
>>
>> --> yeap!
>>
>> Of course this has to be documented and the mailing list (archive) is the
>> first place it already is, which, for sure, is great. In addition, I think
>> we should create a wiki-entry for this.
>>
>> Also and of course I think it is very important to have those discussions,
>> but they have to be constructive. Opening the same "problems" again and
>> again does not help anyone. Furthermore I openend this thread some days
>> before I committed anything and the response was very good. So I think I did
>> the right thing here. Nethertheless I know that it's not done with the
>> commit. This stuff has to be discussed further, but the commit was a way to
>> let everyone be able to test it for themselves.
>>
>> And your compilation error and your related concerns really do have to be
>> discussed. Really, thank's for pointing that out, because I did not run into
>> this error. However I _really_ can't imagine a scenario where this would
>> affect anything on MyFaces. I really don't.
>>
>> Regards,
>> Jakob
>>
>>
>> 2010/3/11 Leonardo Uribe <lu...@gmail.com>
>>
>>> Hi
>>>
>>> 2010/3/11 Jakob Korherr <ja...@gmail.com>
>>>
>>>> Hi,
>>>>
>>>> I totally agree with Jan-Kees. Just override the compiler plugin in
>>>> implee6 to use jdk 6!
>>>>
>>>> Also I really don't see why you think it is such a big problem to have a
>>>> class in the jar file which has other dependencies and another version when
>>>> no other class has any relations to it. It's like a website with no link
>>>> referring to it: you will never find it unless you know the real address of
>>>> it!
>>>>
>>>> Furthermore if we put it into myfaces commons we can also drop it,
>>>> because then it makes no sence. The user will rather continue to use the
>>>> web.xml configuration than bundling some jar, which he maybe does not know
>>>> that it even exists..
>>>>
>>>>
>>> So the change has no sense outside myfaces impl jar. That means we only
>>> have two options: do it like this or remove the code.
>>>
>>>
>>>> And last but not least: Mojarra also has a similar JDK6 compiled class
>>>> with Java EE 6 dependencies in their jsf-impl.jar. So why would it be a
>>>> problem for MyFaces?
>>>>
>>>>
>>> The position from jsr-314-open mail list is as long as TCK test pass we
>>> could do it, and if mojarra has something similar, we could do the same. If
>>> something happens we could remove it and that's all (that means if something
>>> happens we'll be forced to remove this feature from myfaces and that is
>>> risky), since this is not part of the standard, but users should be aware of
>>> that implication. Note from this change, myfaces requires JDK 1.6 to be
>>> compiled, but the classes inside api and impl modules requires JDK 1.5.
>>>
>>>
>>>> Please don't make this problem bigger as it is...
>>>>
>>>>
>>>
>>> I believe it is important to discuss the possible implications of a
>>> change before commit it and make it clear to people (that's one idea about
>>> opensource, give the people the power to know what's happening behind
>>> courtains and the tools to change it). Just put some code because you like
>>> it, or it is cool not always is enough. That's common sense, right?. Also
>>> you have to keep into account this is a standard of some spec, not just a
>>> custom library, so a lot of care is required before add a new feature
>>> outside the spec. So, the idea is not make a problem bigger or start a
>>> bizantine war that leads to nowhere, just benefit the community throught
>>> constructive discussion, but for a discussion it is necessary a clear and
>>> rational position, possible courses of action before start and a "open"
>>> mind, that means, give yourself the possibility of change of opinion
>>> anytime. Please note the benefit of this exercise, if someone wants to check
>>> why this stuff is done in this or that way, there is a source of knowledge
>>> through the mailing list. Please think carefully about what "opensource"
>>> word means.
>>>
>>> regards,
>>>
>>> Leonardo Uribe
>>>
>>>
>>>> Regards,
>>>> Jakob
>>>>
>>>>
>>>>
>>>> 2010/3/11 Leonardo Uribe <lu...@gmail.com>
>>>>
>>>>> Hi
>>>>>
>>>>> I have sended an email to jsr-314-open mail list just to confirm if it
>>>>> is valid or not to do this kind of stuff. The problem is the class involved
>>>>> on implee6 has dependencies with classes that needs JDK 6 to be compiled, so
>>>>> in a JDK 1.5 environment it will crash if the classes are loaded. It is true
>>>>> ease of development will suffer, but I think prevent bugs like this takes
>>>>> precedence.
>>>>>
>>>>> regards,
>>>>>
>>>>> Leonardo Uribe
>>>>>
>>>>> 2010/3/11 Jan-Kees van Andel <ja...@gmail.com>
>>>>>
>>>>> Why not override the compiler plugin in the module to use JDK 6?
>>>>>>
>>>>>> I think the whole point about the module is ease of development and
>>>>>> this will suffer when putting it in a separate jar.
>>>>>>
>>>>>> About the manual classpath scanning or other runtime stuff. This
>>>>>> should not break because of JDK 6 stuff, since the bytecode should be
>>>>>> backwards compatible.
>>>>>>
>>>>>> My 2 cents...
>>>>>>
>>>>>> /JK
>>>>>>
>>>>>>
>>>>>> 2010/3/11 Leonardo Uribe <lu...@gmail.com>
>>>>>>
>>>>>> Hi
>>>>>>>
>>>>>>> I'm working with jdk 1.5 and when I tried to compile current20 branch
>>>>>>> I have an error. This means to create myfaces jars it should be compiled
>>>>>>> with jdk 1.6, because implee6 has dependencies with jars with java 1.6
>>>>>>> specific code:
>>>>>>>
>>>>>>> [INFO]
>>>>>>> ------------------------------------------------------------------------
>>>>>>> [ERROR] BUILD FAILURE
>>>>>>> [INFO]
>>>>>>> ------------------------------------------------------------------------
>>>>>>> [INFO] Compilation failure
>>>>>>>
>>>>>>> D:\workspace\myfaces\current20\core\implee6\src\main\java\org\apache\myfaces\ee6
>>>>>>> \MyFacesContainerInitializer.java:[47,-1] cannot access
>>>>>>> javax.servlet.ServletCon
>>>>>>> tainerInitializer
>>>>>>> bad class file: C:\Documents and
>>>>>>> Settings\lu4242\.m2\repository\javax\javaee-web
>>>>>>>
>>>>>>> -api\6.0\javaee-web-api-6.0.jar(javax/servlet/ServletContainerInitializer.class)
>>>>>>>
>>>>>>> class file has wrong version 50.0, should be 49.0
>>>>>>>
>>>>>>> In theory, we can't do this, because if we do, myfaces-impl has one
>>>>>>> class jdk 1.6 specific, and jsf 2.0 is jdk 1.5 compatible. Now, in the
>>>>>>> practice this class is not loaded by any part of myfaces, but maybe some
>>>>>>> program that tries to scan the classpath and load this class into the
>>>>>>> classpath will see the problem.
>>>>>>>
>>>>>>> My personal opinion is implee6 should have its own separate jar with
>>>>>>> some OSGi specific stuff, so if someone wants to use it it should put three
>>>>>>> jars on the classpath: myfaces-api, myfaces-impl, myfaces-implee6. We have a
>>>>>>> lot of precedences for that kind of stuff (orchestra core and core15 for
>>>>>>> example, tomahawk sandbox and sandbox15).
>>>>>>>
>>>>>>> I also think this code should be moved to myfaces commons, because
>>>>>>> keep it as a module in core project means we have to use jdk 1.6 to compile
>>>>>>> all artifacts and we have a plugin that checks for jdk 1.5 compatibility
>>>>>>> that will fail (see checkJDK profile on myfaces impl pom).
>>>>>>>
>>>>>>> Suggestions are welcome.
>>>>>>>
>>>>>>> regards,
>>>>>>>
>>>>>>> Leonardo Uribe
>>>>>>>
>>>>>>>
>>>>>>> 2010/3/8 Jakob Korherr <ja...@gmail.com>
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> So I committed everything. Please feel free to test it - I am
>>>>>>>> curious about your opinions :)
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Jakob
>>>>>>>>
>>>>>>>> 2010/3/8 Jakob Korherr <ja...@gmail.com>
>>>>>>>>
>>>>>>>> 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 <ge...@gmail.com>
>>>>>>>>>
>>>>>>>>> +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 <we...@gmail.com>
>>>>>>>>>>
>>>>>>>>>> +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 <jankeesvanandel@gmail.com
>>>>>>>>>>>> <ma...@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.korherr@gmail.com
>>>>>>>>>>>> <ma...@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 <jankeesvanandel@gmail.com
>>>>>>>>>>>> <ma...@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.korherr@gmail.com
>>>>>>>>>>>> <ma...@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.bohmann@googlemail.com
>>>>>>>>>>>> <ma...@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.korherr@gmail.com
>>>>>>>>>>>> <ma...@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.bohmann@googlemail.com
>>>>>>>>>>>> <ma...@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.korherr@gmail.com
>>>>>>>>>>>> <ma...@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
>>>>>>>>>>>> <jankeesvanandel@gmail.com
>>>>>>>>>>>> <ma...@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.korherr@gmail.com
>>>>>>>>>>>> <ma...@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
>>>>>>>>>>>> >> >>
>>>>>>>>>>>> >> >
>>>>>>>>>>>> >> >
>>>>>>>>>>>> >
>>>>>>>>>>>> >
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: [core] Introducing implee6 - MYFACES-2579
Posted by Jakob Korherr <ja...@gmail.com>.
Maybe we can use a dependency to Servlet API 3.0 which is compiled against
JDK 5 instead of the javaee-web-api. Is there anything like that?
Regards,
Jakob
2010/3/11 Jakob Korherr <ja...@gmail.com>
> Hi,
>
>
> "So the change has no sense outside myfaces impl jar. That means we only
> have two options: do it like this or remove the code."
>
> --> yeap!
>
> Of course this has to be documented and the mailing list (archive) is the
> first place it already is, which, for sure, is great. In addition, I think
> we should create a wiki-entry for this.
>
> Also and of course I think it is very important to have those discussions,
> but they have to be constructive. Opening the same "problems" again and
> again does not help anyone. Furthermore I openend this thread some days
> before I committed anything and the response was very good. So I think I did
> the right thing here. Nethertheless I know that it's not done with the
> commit. This stuff has to be discussed further, but the commit was a way to
> let everyone be able to test it for themselves.
>
> And your compilation error and your related concerns really do have to be
> discussed. Really, thank's for pointing that out, because I did not run into
> this error. However I _really_ can't imagine a scenario where this would
> affect anything on MyFaces. I really don't.
>
> Regards,
> Jakob
>
>
> 2010/3/11 Leonardo Uribe <lu...@gmail.com>
>
>> Hi
>>
>> 2010/3/11 Jakob Korherr <ja...@gmail.com>
>>
>>> Hi,
>>>
>>> I totally agree with Jan-Kees. Just override the compiler plugin in
>>> implee6 to use jdk 6!
>>>
>>> Also I really don't see why you think it is such a big problem to have a
>>> class in the jar file which has other dependencies and another version when
>>> no other class has any relations to it. It's like a website with no link
>>> referring to it: you will never find it unless you know the real address of
>>> it!
>>>
>>> Furthermore if we put it into myfaces commons we can also drop it,
>>> because then it makes no sence. The user will rather continue to use the
>>> web.xml configuration than bundling some jar, which he maybe does not know
>>> that it even exists..
>>>
>>>
>> So the change has no sense outside myfaces impl jar. That means we only
>> have two options: do it like this or remove the code.
>>
>>
>>> And last but not least: Mojarra also has a similar JDK6 compiled class
>>> with Java EE 6 dependencies in their jsf-impl.jar. So why would it be a
>>> problem for MyFaces?
>>>
>>>
>> The position from jsr-314-open mail list is as long as TCK test pass we
>> could do it, and if mojarra has something similar, we could do the same. If
>> something happens we could remove it and that's all (that means if something
>> happens we'll be forced to remove this feature from myfaces and that is
>> risky), since this is not part of the standard, but users should be aware of
>> that implication. Note from this change, myfaces requires JDK 1.6 to be
>> compiled, but the classes inside api and impl modules requires JDK 1.5.
>>
>>
>>> Please don't make this problem bigger as it is...
>>>
>>>
>>
>> I believe it is important to discuss the possible implications of a change
>> before commit it and make it clear to people (that's one idea about
>> opensource, give the people the power to know what's happening behind
>> courtains and the tools to change it). Just put some code because you like
>> it, or it is cool not always is enough. That's common sense, right?. Also
>> you have to keep into account this is a standard of some spec, not just a
>> custom library, so a lot of care is required before add a new feature
>> outside the spec. So, the idea is not make a problem bigger or start a
>> bizantine war that leads to nowhere, just benefit the community throught
>> constructive discussion, but for a discussion it is necessary a clear and
>> rational position, possible courses of action before start and a "open"
>> mind, that means, give yourself the possibility of change of opinion
>> anytime. Please note the benefit of this exercise, if someone wants to check
>> why this stuff is done in this or that way, there is a source of knowledge
>> through the mailing list. Please think carefully about what "opensource"
>> word means.
>>
>> regards,
>>
>> Leonardo Uribe
>>
>>
>>> Regards,
>>> Jakob
>>>
>>>
>>>
>>> 2010/3/11 Leonardo Uribe <lu...@gmail.com>
>>>
>>>> Hi
>>>>
>>>> I have sended an email to jsr-314-open mail list just to confirm if it
>>>> is valid or not to do this kind of stuff. The problem is the class involved
>>>> on implee6 has dependencies with classes that needs JDK 6 to be compiled, so
>>>> in a JDK 1.5 environment it will crash if the classes are loaded. It is true
>>>> ease of development will suffer, but I think prevent bugs like this takes
>>>> precedence.
>>>>
>>>> regards,
>>>>
>>>> Leonardo Uribe
>>>>
>>>> 2010/3/11 Jan-Kees van Andel <ja...@gmail.com>
>>>>
>>>> Why not override the compiler plugin in the module to use JDK 6?
>>>>>
>>>>> I think the whole point about the module is ease of development and
>>>>> this will suffer when putting it in a separate jar.
>>>>>
>>>>> About the manual classpath scanning or other runtime stuff. This should
>>>>> not break because of JDK 6 stuff, since the bytecode should be backwards
>>>>> compatible.
>>>>>
>>>>> My 2 cents...
>>>>>
>>>>> /JK
>>>>>
>>>>>
>>>>> 2010/3/11 Leonardo Uribe <lu...@gmail.com>
>>>>>
>>>>> Hi
>>>>>>
>>>>>> I'm working with jdk 1.5 and when I tried to compile current20 branch
>>>>>> I have an error. This means to create myfaces jars it should be compiled
>>>>>> with jdk 1.6, because implee6 has dependencies with jars with java 1.6
>>>>>> specific code:
>>>>>>
>>>>>> [INFO]
>>>>>> ------------------------------------------------------------------------
>>>>>> [ERROR] BUILD FAILURE
>>>>>> [INFO]
>>>>>> ------------------------------------------------------------------------
>>>>>> [INFO] Compilation failure
>>>>>>
>>>>>> D:\workspace\myfaces\current20\core\implee6\src\main\java\org\apache\myfaces\ee6
>>>>>> \MyFacesContainerInitializer.java:[47,-1] cannot access
>>>>>> javax.servlet.ServletCon
>>>>>> tainerInitializer
>>>>>> bad class file: C:\Documents and
>>>>>> Settings\lu4242\.m2\repository\javax\javaee-web
>>>>>>
>>>>>> -api\6.0\javaee-web-api-6.0.jar(javax/servlet/ServletContainerInitializer.class)
>>>>>>
>>>>>> class file has wrong version 50.0, should be 49.0
>>>>>>
>>>>>> In theory, we can't do this, because if we do, myfaces-impl has one
>>>>>> class jdk 1.6 specific, and jsf 2.0 is jdk 1.5 compatible. Now, in the
>>>>>> practice this class is not loaded by any part of myfaces, but maybe some
>>>>>> program that tries to scan the classpath and load this class into the
>>>>>> classpath will see the problem.
>>>>>>
>>>>>> My personal opinion is implee6 should have its own separate jar with
>>>>>> some OSGi specific stuff, so if someone wants to use it it should put three
>>>>>> jars on the classpath: myfaces-api, myfaces-impl, myfaces-implee6. We have a
>>>>>> lot of precedences for that kind of stuff (orchestra core and core15 for
>>>>>> example, tomahawk sandbox and sandbox15).
>>>>>>
>>>>>> I also think this code should be moved to myfaces commons, because
>>>>>> keep it as a module in core project means we have to use jdk 1.6 to compile
>>>>>> all artifacts and we have a plugin that checks for jdk 1.5 compatibility
>>>>>> that will fail (see checkJDK profile on myfaces impl pom).
>>>>>>
>>>>>> Suggestions are welcome.
>>>>>>
>>>>>> regards,
>>>>>>
>>>>>> Leonardo Uribe
>>>>>>
>>>>>>
>>>>>> 2010/3/8 Jakob Korherr <ja...@gmail.com>
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> So I committed everything. Please feel free to test it - I am curious
>>>>>>> about your opinions :)
>>>>>>>
>>>>>>> Regards,
>>>>>>> Jakob
>>>>>>>
>>>>>>> 2010/3/8 Jakob Korherr <ja...@gmail.com>
>>>>>>>
>>>>>>> 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 <ge...@gmail.com>
>>>>>>>>
>>>>>>>> +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 <we...@gmail.com>
>>>>>>>>>
>>>>>>>>> +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 <jankeesvanandel@gmail.com
>>>>>>>>>>> <ma...@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.korherr@gmail.com
>>>>>>>>>>> <ma...@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 <jankeesvanandel@gmail.com
>>>>>>>>>>> <ma...@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.korherr@gmail.com
>>>>>>>>>>> <ma...@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.bohmann@googlemail.com
>>>>>>>>>>> <ma...@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.korherr@gmail.com
>>>>>>>>>>> <ma...@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.bohmann@googlemail.com
>>>>>>>>>>> <ma...@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.korherr@gmail.com
>>>>>>>>>>> <ma...@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
>>>>>>>>>>> <jankeesvanandel@gmail.com
>>>>>>>>>>> <ma...@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.korherr@gmail.com
>>>>>>>>>>> <ma...@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
>>>>>>>>>>> >> >>
>>>>>>>>>>> >> >
>>>>>>>>>>> >> >
>>>>>>>>>>> >
>>>>>>>>>>> >
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: [core] Introducing implee6 - MYFACES-2579
Posted by Jakob Korherr <ja...@gmail.com>.
Hi,
"So the change has no sense outside myfaces impl jar. That means we only
have two options: do it like this or remove the code."
--> yeap!
Of course this has to be documented and the mailing list (archive) is the
first place it already is, which, for sure, is great. In addition, I think
we should create a wiki-entry for this.
Also and of course I think it is very important to have those discussions,
but they have to be constructive. Opening the same "problems" again and
again does not help anyone. Furthermore I openend this thread some days
before I committed anything and the response was very good. So I think I did
the right thing here. Nethertheless I know that it's not done with the
commit. This stuff has to be discussed further, but the commit was a way to
let everyone be able to test it for themselves.
And your compilation error and your related concerns really do have to be
discussed. Really, thank's for pointing that out, because I did not run into
this error. However I _really_ can't imagine a scenario where this would
affect anything on MyFaces. I really don't.
Regards,
Jakob
2010/3/11 Leonardo Uribe <lu...@gmail.com>
> Hi
>
> 2010/3/11 Jakob Korherr <ja...@gmail.com>
>
>> Hi,
>>
>> I totally agree with Jan-Kees. Just override the compiler plugin in
>> implee6 to use jdk 6!
>>
>> Also I really don't see why you think it is such a big problem to have a
>> class in the jar file which has other dependencies and another version when
>> no other class has any relations to it. It's like a website with no link
>> referring to it: you will never find it unless you know the real address of
>> it!
>>
>> Furthermore if we put it into myfaces commons we can also drop it, because
>> then it makes no sence. The user will rather continue to use the web.xml
>> configuration than bundling some jar, which he maybe does not know that it
>> even exists..
>>
>>
> So the change has no sense outside myfaces impl jar. That means we only
> have two options: do it like this or remove the code.
>
>
>> And last but not least: Mojarra also has a similar JDK6 compiled class
>> with Java EE 6 dependencies in their jsf-impl.jar. So why would it be a
>> problem for MyFaces?
>>
>>
> The position from jsr-314-open mail list is as long as TCK test pass we
> could do it, and if mojarra has something similar, we could do the same. If
> something happens we could remove it and that's all (that means if something
> happens we'll be forced to remove this feature from myfaces and that is
> risky), since this is not part of the standard, but users should be aware of
> that implication. Note from this change, myfaces requires JDK 1.6 to be
> compiled, but the classes inside api and impl modules requires JDK 1.5.
>
>
>> Please don't make this problem bigger as it is...
>>
>>
>
> I believe it is important to discuss the possible implications of a change
> before commit it and make it clear to people (that's one idea about
> opensource, give the people the power to know what's happening behind
> courtains and the tools to change it). Just put some code because you like
> it, or it is cool not always is enough. That's common sense, right?. Also
> you have to keep into account this is a standard of some spec, not just a
> custom library, so a lot of care is required before add a new feature
> outside the spec. So, the idea is not make a problem bigger or start a
> bizantine war that leads to nowhere, just benefit the community throught
> constructive discussion, but for a discussion it is necessary a clear and
> rational position, possible courses of action before start and a "open"
> mind, that means, give yourself the possibility of change of opinion
> anytime. Please note the benefit of this exercise, if someone wants to check
> why this stuff is done in this or that way, there is a source of knowledge
> through the mailing list. Please think carefully about what "opensource"
> word means.
>
> regards,
>
> Leonardo Uribe
>
>
>> Regards,
>> Jakob
>>
>>
>>
>> 2010/3/11 Leonardo Uribe <lu...@gmail.com>
>>
>>> Hi
>>>
>>> I have sended an email to jsr-314-open mail list just to confirm if it is
>>> valid or not to do this kind of stuff. The problem is the class involved on
>>> implee6 has dependencies with classes that needs JDK 6 to be compiled, so in
>>> a JDK 1.5 environment it will crash if the classes are loaded. It is true
>>> ease of development will suffer, but I think prevent bugs like this takes
>>> precedence.
>>>
>>> regards,
>>>
>>> Leonardo Uribe
>>>
>>> 2010/3/11 Jan-Kees van Andel <ja...@gmail.com>
>>>
>>> Why not override the compiler plugin in the module to use JDK 6?
>>>>
>>>> I think the whole point about the module is ease of development and this
>>>> will suffer when putting it in a separate jar.
>>>>
>>>> About the manual classpath scanning or other runtime stuff. This should
>>>> not break because of JDK 6 stuff, since the bytecode should be backwards
>>>> compatible.
>>>>
>>>> My 2 cents...
>>>>
>>>> /JK
>>>>
>>>>
>>>> 2010/3/11 Leonardo Uribe <lu...@gmail.com>
>>>>
>>>> Hi
>>>>>
>>>>> I'm working with jdk 1.5 and when I tried to compile current20 branch I
>>>>> have an error. This means to create myfaces jars it should be compiled with
>>>>> jdk 1.6, because implee6 has dependencies with jars with java 1.6 specific
>>>>> code:
>>>>>
>>>>> [INFO]
>>>>> ------------------------------------------------------------------------
>>>>> [ERROR] BUILD FAILURE
>>>>> [INFO]
>>>>> ------------------------------------------------------------------------
>>>>> [INFO] Compilation failure
>>>>>
>>>>> D:\workspace\myfaces\current20\core\implee6\src\main\java\org\apache\myfaces\ee6
>>>>> \MyFacesContainerInitializer.java:[47,-1] cannot access
>>>>> javax.servlet.ServletCon
>>>>> tainerInitializer
>>>>> bad class file: C:\Documents and
>>>>> Settings\lu4242\.m2\repository\javax\javaee-web
>>>>>
>>>>> -api\6.0\javaee-web-api-6.0.jar(javax/servlet/ServletContainerInitializer.class)
>>>>>
>>>>> class file has wrong version 50.0, should be 49.0
>>>>>
>>>>> In theory, we can't do this, because if we do, myfaces-impl has one
>>>>> class jdk 1.6 specific, and jsf 2.0 is jdk 1.5 compatible. Now, in the
>>>>> practice this class is not loaded by any part of myfaces, but maybe some
>>>>> program that tries to scan the classpath and load this class into the
>>>>> classpath will see the problem.
>>>>>
>>>>> My personal opinion is implee6 should have its own separate jar with
>>>>> some OSGi specific stuff, so if someone wants to use it it should put three
>>>>> jars on the classpath: myfaces-api, myfaces-impl, myfaces-implee6. We have a
>>>>> lot of precedences for that kind of stuff (orchestra core and core15 for
>>>>> example, tomahawk sandbox and sandbox15).
>>>>>
>>>>> I also think this code should be moved to myfaces commons, because keep
>>>>> it as a module in core project means we have to use jdk 1.6 to compile all
>>>>> artifacts and we have a plugin that checks for jdk 1.5 compatibility that
>>>>> will fail (see checkJDK profile on myfaces impl pom).
>>>>>
>>>>> Suggestions are welcome.
>>>>>
>>>>> regards,
>>>>>
>>>>> Leonardo Uribe
>>>>>
>>>>>
>>>>> 2010/3/8 Jakob Korherr <ja...@gmail.com>
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> So I committed everything. Please feel free to test it - I am curious
>>>>>> about your opinions :)
>>>>>>
>>>>>> Regards,
>>>>>> Jakob
>>>>>>
>>>>>> 2010/3/8 Jakob Korherr <ja...@gmail.com>
>>>>>>
>>>>>> 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 <ge...@gmail.com>
>>>>>>>
>>>>>>> +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 <we...@gmail.com>
>>>>>>>>
>>>>>>>> +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 <jankeesvanandel@gmail.com
>>>>>>>>>> <ma...@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.korherr@gmail.com
>>>>>>>>>> <ma...@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 <jankeesvanandel@gmail.com
>>>>>>>>>> <ma...@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.korherr@gmail.com
>>>>>>>>>> <ma...@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.bohmann@googlemail.com
>>>>>>>>>> <ma...@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.korherr@gmail.com
>>>>>>>>>> <ma...@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.bohmann@googlemail.com
>>>>>>>>>> <ma...@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.korherr@gmail.com
>>>>>>>>>> <ma...@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
>>>>>>>>>> <jankeesvanandel@gmail.com
>>>>>>>>>> <ma...@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.korherr@gmail.com
>>>>>>>>>> <ma...@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
>>>>>>>>>> >> >>
>>>>>>>>>> >> >
>>>>>>>>>> >> >
>>>>>>>>>> >
>>>>>>>>>> >
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: [core] Introducing implee6 - MYFACES-2579
Posted by Mike Kienenberger <mk...@gmail.com>.
I agree with Leonardo that changes which affect our base requirements
(jdk 6 instead of jdk 5) and which could compromise our certification
warrant discussion rather than a "commit-and-hope-no-one-complains"
attitude.
Otherwise, without discussion, how would we know that Mojarra allows it?
On Thu, Mar 11, 2010 at 4:24 PM, Leonardo Uribe <lu...@gmail.com> wrote:
> Hi
>
> 2010/3/11 Jakob Korherr <ja...@gmail.com>
>>
>> Hi,
>>
>> I totally agree with Jan-Kees. Just override the compiler plugin in
>> implee6 to use jdk 6!
>>
>> Also I really don't see why you think it is such a big problem to have a
>> class in the jar file which has other dependencies and another version when
>> no other class has any relations to it. It's like a website with no link
>> referring to it: you will never find it unless you know the real address of
>> it!
>>
>> Furthermore if we put it into myfaces commons we can also drop it, because
>> then it makes no sence. The user will rather continue to use the web.xml
>> configuration than bundling some jar, which he maybe does not know that it
>> even exists..
>>
>
> So the change has no sense outside myfaces impl jar. That means we only have
> two options: do it like this or remove the code.
>
>>
>> And last but not least: Mojarra also has a similar JDK6 compiled class
>> with Java EE 6 dependencies in their jsf-impl.jar. So why would it be a
>> problem for MyFaces?
>>
>
> The position from jsr-314-open mail list is as long as TCK test pass we
> could do it, and if mojarra has something similar, we could do the same. If
> something happens we could remove it and that's all (that means if something
> happens we'll be forced to remove this feature from myfaces and that is
> risky), since this is not part of the standard, but users should be aware of
> that implication. Note from this change, myfaces requires JDK 1.6 to be
> compiled, but the classes inside api and impl modules requires JDK 1.5.
>
>>
>> Please don't make this problem bigger as it is...
>>
>
> I believe it is important to discuss the possible implications of a change
> before commit it and make it clear to people (that's one idea about
> opensource, give the people the power to know what's happening behind
> courtains and the tools to change it). Just put some code because you like
> it, or it is cool not always is enough. That's common sense, right?. Also
> you have to keep into account this is a standard of some spec, not just a
> custom library, so a lot of care is required before add a new feature
> outside the spec. So, the idea is not make a problem bigger or start a
> bizantine war that leads to nowhere, just benefit the community throught
> constructive discussion, but for a discussion it is necessary a clear and
> rational position, possible courses of action before start and a "open"
> mind, that means, give yourself the possibility of change of opinion
> anytime. Please note the benefit of this exercise, if someone wants to check
> why this stuff is done in this or that way, there is a source of knowledge
> through the mailing list. Please think carefully about what "opensource"
> word means.
>
> regards,
>
> Leonardo Uribe
>
>>
>> Regards,
>> Jakob
>>
>>
>> 2010/3/11 Leonardo Uribe <lu...@gmail.com>
>>>
>>> Hi
>>>
>>> I have sended an email to jsr-314-open mail list just to confirm if it is
>>> valid or not to do this kind of stuff. The problem is the class involved on
>>> implee6 has dependencies with classes that needs JDK 6 to be compiled, so in
>>> a JDK 1.5 environment it will crash if the classes are loaded. It is true
>>> ease of development will suffer, but I think prevent bugs like this takes
>>> precedence.
>>>
>>> regards,
>>>
>>> Leonardo Uribe
>>>
>>> 2010/3/11 Jan-Kees van Andel <ja...@gmail.com>
>>>>
>>>> Why not override the compiler plugin in the module to use JDK 6?
>>>>
>>>> I think the whole point about the module is ease of development and this
>>>> will suffer when putting it in a separate jar.
>>>>
>>>> About the manual classpath scanning or other runtime stuff. This should
>>>> not break because of JDK 6 stuff, since the bytecode should be backwards
>>>> compatible.
>>>>
>>>> My 2 cents...
>>>>
>>>> /JK
>>>>
>>>>
>>>> 2010/3/11 Leonardo Uribe <lu...@gmail.com>
>>>>>
>>>>> Hi
>>>>>
>>>>> I'm working with jdk 1.5 and when I tried to compile current20 branch I
>>>>> have an error. This means to create myfaces jars it should be compiled with
>>>>> jdk 1.6, because implee6 has dependencies with jars with java 1.6 specific
>>>>> code:
>>>>>
>>>>> [INFO]
>>>>> ------------------------------------------------------------------------
>>>>> [ERROR] BUILD FAILURE
>>>>> [INFO]
>>>>> ------------------------------------------------------------------------
>>>>> [INFO] Compilation failure
>>>>>
>>>>> D:\workspace\myfaces\current20\core\implee6\src\main\java\org\apache\myfaces\ee6
>>>>> \MyFacesContainerInitializer.java:[47,-1] cannot access
>>>>> javax.servlet.ServletCon
>>>>> tainerInitializer
>>>>> bad class file: C:\Documents and
>>>>> Settings\lu4242\.m2\repository\javax\javaee-web
>>>>>
>>>>> -api\6.0\javaee-web-api-6.0.jar(javax/servlet/ServletContainerInitializer.class)
>>>>>
>>>>> class file has wrong version 50.0, should be 49.0
>>>>>
>>>>> In theory, we can't do this, because if we do, myfaces-impl has one
>>>>> class jdk 1.6 specific, and jsf 2.0 is jdk 1.5 compatible. Now, in the
>>>>> practice this class is not loaded by any part of myfaces, but maybe some
>>>>> program that tries to scan the classpath and load this class into the
>>>>> classpath will see the problem.
>>>>>
>>>>> My personal opinion is implee6 should have its own separate jar with
>>>>> some OSGi specific stuff, so if someone wants to use it it should put three
>>>>> jars on the classpath: myfaces-api, myfaces-impl, myfaces-implee6. We have a
>>>>> lot of precedences for that kind of stuff (orchestra core and core15 for
>>>>> example, tomahawk sandbox and sandbox15).
>>>>>
>>>>> I also think this code should be moved to myfaces commons, because keep
>>>>> it as a module in core project means we have to use jdk 1.6 to compile all
>>>>> artifacts and we have a plugin that checks for jdk 1.5 compatibility that
>>>>> will fail (see checkJDK profile on myfaces impl pom).
>>>>>
>>>>> Suggestions are welcome.
>>>>>
>>>>> regards,
>>>>>
>>>>> Leonardo Uribe
>>>>>
>>>>> 2010/3/8 Jakob Korherr <ja...@gmail.com>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> So I committed everything. Please feel free to test it - I am curious
>>>>>> about your opinions :)
>>>>>>
>>>>>> Regards,
>>>>>> Jakob
>>>>>>
>>>>>> 2010/3/8 Jakob Korherr <ja...@gmail.com>
>>>>>>>
>>>>>>> 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 <ge...@gmail.com>
>>>>>>>>
>>>>>>>> +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 <we...@gmail.com>
>>>>>>>>>
>>>>>>>>> +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 <jankeesvanandel@gmail.com
>>>>>>>>>> <ma...@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.korherr@gmail.com
>>>>>>>>>> Â Â <ma...@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 <jankeesvanandel@gmail.com
>>>>>>>>>> Â Â Â Â <ma...@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.korherr@gmail.com
>>>>>>>>>> Â Â Â Â Â Â <ma...@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.bohmann@googlemail.com
>>>>>>>>>> Â Â Â Â Â Â Â Â <ma...@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.korherr@gmail.com
>>>>>>>>>> Â Â Â Â Â Â Â Â Â Â <ma...@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.bohmann@googlemail.com
>>>>>>>>>> Â Â Â Â Â Â Â Â Â Â <ma...@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.korherr@gmail.com
>>>>>>>>>> Â Â Â Â Â Â Â Â Â Â <ma...@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
>>>>>>>>>> Â Â Â Â Â Â Â Â Â Â <jankeesvanandel@gmail.com
>>>>>>>>>> Â Â Â Â Â Â Â Â Â Â <ma...@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.korherr@gmail.com
>>>>>>>>>> Â Â Â Â Â Â Â Â Â Â <ma...@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
>>>>>>>>>> Â Â Â Â Â Â Â Â Â Â >> >>
>>>>>>>>>> Â Â Â Â Â Â Â Â Â Â >> >
>>>>>>>>>> Â Â Â Â Â Â Â Â Â Â >> >
>>>>>>>>>> Â Â Â Â Â Â Â Â Â Â >
>>>>>>>>>> Â Â Â Â Â Â Â Â Â Â >
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>
Re: [core] Introducing implee6 - MYFACES-2579
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi
2010/3/11 Jakob Korherr <ja...@gmail.com>
> Hi,
>
> I totally agree with Jan-Kees. Just override the compiler plugin in implee6
> to use jdk 6!
>
> Also I really don't see why you think it is such a big problem to have a
> class in the jar file which has other dependencies and another version when
> no other class has any relations to it. It's like a website with no link
> referring to it: you will never find it unless you know the real address of
> it!
>
> Furthermore if we put it into myfaces commons we can also drop it, because
> then it makes no sence. The user will rather continue to use the web.xml
> configuration than bundling some jar, which he maybe does not know that it
> even exists..
>
>
So the change has no sense outside myfaces impl jar. That means we only have
two options: do it like this or remove the code.
> And last but not least: Mojarra also has a similar JDK6 compiled class with
> Java EE 6 dependencies in their jsf-impl.jar. So why would it be a problem
> for MyFaces?
>
>
The position from jsr-314-open mail list is as long as TCK test pass we
could do it, and if mojarra has something similar, we could do the same. If
something happens we could remove it and that's all (that means if something
happens we'll be forced to remove this feature from myfaces and that is
risky), since this is not part of the standard, but users should be aware of
that implication. Note from this change, myfaces requires JDK 1.6 to be
compiled, but the classes inside api and impl modules requires JDK 1.5.
> Please don't make this problem bigger as it is...
>
>
I believe it is important to discuss the possible implications of a change
before commit it and make it clear to people (that's one idea about
opensource, give the people the power to know what's happening behind
courtains and the tools to change it). Just put some code because you like
it, or it is cool not always is enough. That's common sense, right?. Also
you have to keep into account this is a standard of some spec, not just a
custom library, so a lot of care is required before add a new feature
outside the spec. So, the idea is not make a problem bigger or start a
bizantine war that leads to nowhere, just benefit the community throught
constructive discussion, but for a discussion it is necessary a clear and
rational position, possible courses of action before start and a "open"
mind, that means, give yourself the possibility of change of opinion
anytime. Please note the benefit of this exercise, if someone wants to check
why this stuff is done in this or that way, there is a source of knowledge
through the mailing list. Please think carefully about what "opensource"
word means.
regards,
Leonardo Uribe
> Regards,
> Jakob
>
>
>
> 2010/3/11 Leonardo Uribe <lu...@gmail.com>
>
>> Hi
>>
>> I have sended an email to jsr-314-open mail list just to confirm if it is
>> valid or not to do this kind of stuff. The problem is the class involved on
>> implee6 has dependencies with classes that needs JDK 6 to be compiled, so in
>> a JDK 1.5 environment it will crash if the classes are loaded. It is true
>> ease of development will suffer, but I think prevent bugs like this takes
>> precedence.
>>
>> regards,
>>
>> Leonardo Uribe
>>
>> 2010/3/11 Jan-Kees van Andel <ja...@gmail.com>
>>
>> Why not override the compiler plugin in the module to use JDK 6?
>>>
>>> I think the whole point about the module is ease of development and this
>>> will suffer when putting it in a separate jar.
>>>
>>> About the manual classpath scanning or other runtime stuff. This should
>>> not break because of JDK 6 stuff, since the bytecode should be backwards
>>> compatible.
>>>
>>> My 2 cents...
>>>
>>> /JK
>>>
>>>
>>> 2010/3/11 Leonardo Uribe <lu...@gmail.com>
>>>
>>> Hi
>>>>
>>>> I'm working with jdk 1.5 and when I tried to compile current20 branch I
>>>> have an error. This means to create myfaces jars it should be compiled with
>>>> jdk 1.6, because implee6 has dependencies with jars with java 1.6 specific
>>>> code:
>>>>
>>>> [INFO]
>>>> ------------------------------------------------------------------------
>>>> [ERROR] BUILD FAILURE
>>>> [INFO]
>>>> ------------------------------------------------------------------------
>>>> [INFO] Compilation failure
>>>>
>>>> D:\workspace\myfaces\current20\core\implee6\src\main\java\org\apache\myfaces\ee6
>>>> \MyFacesContainerInitializer.java:[47,-1] cannot access
>>>> javax.servlet.ServletCon
>>>> tainerInitializer
>>>> bad class file: C:\Documents and
>>>> Settings\lu4242\.m2\repository\javax\javaee-web
>>>>
>>>> -api\6.0\javaee-web-api-6.0.jar(javax/servlet/ServletContainerInitializer.class)
>>>>
>>>> class file has wrong version 50.0, should be 49.0
>>>>
>>>> In theory, we can't do this, because if we do, myfaces-impl has one
>>>> class jdk 1.6 specific, and jsf 2.0 is jdk 1.5 compatible. Now, in the
>>>> practice this class is not loaded by any part of myfaces, but maybe some
>>>> program that tries to scan the classpath and load this class into the
>>>> classpath will see the problem.
>>>>
>>>> My personal opinion is implee6 should have its own separate jar with
>>>> some OSGi specific stuff, so if someone wants to use it it should put three
>>>> jars on the classpath: myfaces-api, myfaces-impl, myfaces-implee6. We have a
>>>> lot of precedences for that kind of stuff (orchestra core and core15 for
>>>> example, tomahawk sandbox and sandbox15).
>>>>
>>>> I also think this code should be moved to myfaces commons, because keep
>>>> it as a module in core project means we have to use jdk 1.6 to compile all
>>>> artifacts and we have a plugin that checks for jdk 1.5 compatibility that
>>>> will fail (see checkJDK profile on myfaces impl pom).
>>>>
>>>> Suggestions are welcome.
>>>>
>>>> regards,
>>>>
>>>> Leonardo Uribe
>>>>
>>>>
>>>> 2010/3/8 Jakob Korherr <ja...@gmail.com>
>>>>
>>>>> Hi,
>>>>>
>>>>> So I committed everything. Please feel free to test it - I am curious
>>>>> about your opinions :)
>>>>>
>>>>> Regards,
>>>>> Jakob
>>>>>
>>>>> 2010/3/8 Jakob Korherr <ja...@gmail.com>
>>>>>
>>>>> 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 <ge...@gmail.com>
>>>>>>
>>>>>> +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 <we...@gmail.com>
>>>>>>>
>>>>>>> +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 <jankeesvanandel@gmail.com
>>>>>>>>> <ma...@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.korherr@gmail.com
>>>>>>>>> <ma...@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 <jankeesvanandel@gmail.com
>>>>>>>>> <ma...@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.korherr@gmail.com
>>>>>>>>> <ma...@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.bohmann@googlemail.com
>>>>>>>>> <ma...@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.korherr@gmail.com
>>>>>>>>> <ma...@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.bohmann@googlemail.com
>>>>>>>>> <ma...@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.korherr@gmail.com
>>>>>>>>> <ma...@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
>>>>>>>>> <jankeesvanandel@gmail.com
>>>>>>>>> <ma...@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.korherr@gmail.com
>>>>>>>>> <ma...@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
>>>>>>>>> >> >>
>>>>>>>>> >> >
>>>>>>>>> >> >
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: [core] Introducing implee6 - MYFACES-2579
Posted by Jakob Korherr <ja...@gmail.com>.
Hi,
I totally agree with Jan-Kees. Just override the compiler plugin in implee6
to use jdk 6!
Also I really don't see why you think it is such a big problem to have a
class in the jar file which has other dependencies and another version when
no other class has any relations to it. It's like a website with no link
referring to it: you will never find it unless you know the real address of
it!
Furthermore if we put it into myfaces commons we can also drop it, because
then it makes no sence. The user will rather continue to use the web.xml
configuration than bundling some jar, which he maybe does not know that it
even exists..
And last but not least: Mojarra also has a similar JDK6 compiled class with
Java EE 6 dependencies in their jsf-impl.jar. So why would it be a problem
for MyFaces?
Please don't make this problem bigger as it is...
Regards,
Jakob
2010/3/11 Leonardo Uribe <lu...@gmail.com>
> Hi
>
> I have sended an email to jsr-314-open mail list just to confirm if it is
> valid or not to do this kind of stuff. The problem is the class involved on
> implee6 has dependencies with classes that needs JDK 6 to be compiled, so in
> a JDK 1.5 environment it will crash if the classes are loaded. It is true
> ease of development will suffer, but I think prevent bugs like this takes
> precedence.
>
> regards,
>
> Leonardo Uribe
>
> 2010/3/11 Jan-Kees van Andel <ja...@gmail.com>
>
> Why not override the compiler plugin in the module to use JDK 6?
>>
>> I think the whole point about the module is ease of development and this
>> will suffer when putting it in a separate jar.
>>
>> About the manual classpath scanning or other runtime stuff. This should
>> not break because of JDK 6 stuff, since the bytecode should be backwards
>> compatible.
>>
>> My 2 cents...
>>
>> /JK
>>
>>
>> 2010/3/11 Leonardo Uribe <lu...@gmail.com>
>>
>> Hi
>>>
>>> I'm working with jdk 1.5 and when I tried to compile current20 branch I
>>> have an error. This means to create myfaces jars it should be compiled with
>>> jdk 1.6, because implee6 has dependencies with jars with java 1.6 specific
>>> code:
>>>
>>> [INFO]
>>> ------------------------------------------------------------------------
>>> [ERROR] BUILD FAILURE
>>> [INFO]
>>> ------------------------------------------------------------------------
>>> [INFO] Compilation failure
>>>
>>> D:\workspace\myfaces\current20\core\implee6\src\main\java\org\apache\myfaces\ee6
>>> \MyFacesContainerInitializer.java:[47,-1] cannot access
>>> javax.servlet.ServletCon
>>> tainerInitializer
>>> bad class file: C:\Documents and
>>> Settings\lu4242\.m2\repository\javax\javaee-web
>>>
>>> -api\6.0\javaee-web-api-6.0.jar(javax/servlet/ServletContainerInitializer.class)
>>>
>>> class file has wrong version 50.0, should be 49.0
>>>
>>> In theory, we can't do this, because if we do, myfaces-impl has one class
>>> jdk 1.6 specific, and jsf 2.0 is jdk 1.5 compatible. Now, in the practice
>>> this class is not loaded by any part of myfaces, but maybe some program that
>>> tries to scan the classpath and load this class into the classpath will see
>>> the problem.
>>>
>>> My personal opinion is implee6 should have its own separate jar with some
>>> OSGi specific stuff, so if someone wants to use it it should put three jars
>>> on the classpath: myfaces-api, myfaces-impl, myfaces-implee6. We have a lot
>>> of precedences for that kind of stuff (orchestra core and core15 for
>>> example, tomahawk sandbox and sandbox15).
>>>
>>> I also think this code should be moved to myfaces commons, because keep
>>> it as a module in core project means we have to use jdk 1.6 to compile all
>>> artifacts and we have a plugin that checks for jdk 1.5 compatibility that
>>> will fail (see checkJDK profile on myfaces impl pom).
>>>
>>> Suggestions are welcome.
>>>
>>> regards,
>>>
>>> Leonardo Uribe
>>>
>>>
>>> 2010/3/8 Jakob Korherr <ja...@gmail.com>
>>>
>>>> Hi,
>>>>
>>>> So I committed everything. Please feel free to test it - I am curious
>>>> about your opinions :)
>>>>
>>>> Regards,
>>>> Jakob
>>>>
>>>> 2010/3/8 Jakob Korherr <ja...@gmail.com>
>>>>
>>>> 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 <ge...@gmail.com>
>>>>>
>>>>> +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 <we...@gmail.com>
>>>>>>
>>>>>> +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 <jankeesvanandel@gmail.com
>>>>>>>> <ma...@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.korherr@gmail.com
>>>>>>>> <ma...@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 <jankeesvanandel@gmail.com
>>>>>>>> <ma...@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.korherr@gmail.com
>>>>>>>> <ma...@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.bohmann@googlemail.com
>>>>>>>> <ma...@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.korherr@gmail.com
>>>>>>>> <ma...@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.bohmann@googlemail.com
>>>>>>>> <ma...@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.korherr@gmail.com
>>>>>>>> <ma...@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
>>>>>>>> <jankeesvanandel@gmail.com
>>>>>>>> <ma...@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.korherr@gmail.com
>>>>>>>> <ma...@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
>>>>>>>> >> >>
>>>>>>>> >> >
>>>>>>>> >> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: [core] Introducing implee6 - MYFACES-2579
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi
I have sended an email to jsr-314-open mail list just to confirm if it is
valid or not to do this kind of stuff. The problem is the class involved on
implee6 has dependencies with classes that needs JDK 6 to be compiled, so in
a JDK 1.5 environment it will crash if the classes are loaded. It is true
ease of development will suffer, but I think prevent bugs like this takes
precedence.
regards,
Leonardo Uribe
2010/3/11 Jan-Kees van Andel <ja...@gmail.com>
> Why not override the compiler plugin in the module to use JDK 6?
>
> I think the whole point about the module is ease of development and this
> will suffer when putting it in a separate jar.
>
> About the manual classpath scanning or other runtime stuff. This should not
> break because of JDK 6 stuff, since the bytecode should be backwards
> compatible.
>
> My 2 cents...
>
> /JK
>
>
> 2010/3/11 Leonardo Uribe <lu...@gmail.com>
>
> Hi
>>
>> I'm working with jdk 1.5 and when I tried to compile current20 branch I
>> have an error. This means to create myfaces jars it should be compiled with
>> jdk 1.6, because implee6 has dependencies with jars with java 1.6 specific
>> code:
>>
>> [INFO]
>> ------------------------------------------------------------------------
>> [ERROR] BUILD FAILURE
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] Compilation failure
>>
>> D:\workspace\myfaces\current20\core\implee6\src\main\java\org\apache\myfaces\ee6
>> \MyFacesContainerInitializer.java:[47,-1] cannot access
>> javax.servlet.ServletCon
>> tainerInitializer
>> bad class file: C:\Documents and
>> Settings\lu4242\.m2\repository\javax\javaee-web
>>
>> -api\6.0\javaee-web-api-6.0.jar(javax/servlet/ServletContainerInitializer.class)
>>
>> class file has wrong version 50.0, should be 49.0
>>
>> In theory, we can't do this, because if we do, myfaces-impl has one class
>> jdk 1.6 specific, and jsf 2.0 is jdk 1.5 compatible. Now, in the practice
>> this class is not loaded by any part of myfaces, but maybe some program that
>> tries to scan the classpath and load this class into the classpath will see
>> the problem.
>>
>> My personal opinion is implee6 should have its own separate jar with some
>> OSGi specific stuff, so if someone wants to use it it should put three jars
>> on the classpath: myfaces-api, myfaces-impl, myfaces-implee6. We have a lot
>> of precedences for that kind of stuff (orchestra core and core15 for
>> example, tomahawk sandbox and sandbox15).
>>
>> I also think this code should be moved to myfaces commons, because keep it
>> as a module in core project means we have to use jdk 1.6 to compile all
>> artifacts and we have a plugin that checks for jdk 1.5 compatibility that
>> will fail (see checkJDK profile on myfaces impl pom).
>>
>> Suggestions are welcome.
>>
>> regards,
>>
>> Leonardo Uribe
>>
>>
>> 2010/3/8 Jakob Korherr <ja...@gmail.com>
>>
>>> Hi,
>>>
>>> So I committed everything. Please feel free to test it - I am curious
>>> about your opinions :)
>>>
>>> Regards,
>>> Jakob
>>>
>>> 2010/3/8 Jakob Korherr <ja...@gmail.com>
>>>
>>> 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 <ge...@gmail.com>
>>>>
>>>> +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 <we...@gmail.com>
>>>>>
>>>>> +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 <jankeesvanandel@gmail.com
>>>>>>> <ma...@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.korherr@gmail.com
>>>>>>> <ma...@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 <jankeesvanandel@gmail.com
>>>>>>> <ma...@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.korherr@gmail.com
>>>>>>> <ma...@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.bohmann@googlemail.com
>>>>>>> <ma...@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.korherr@gmail.com
>>>>>>> <ma...@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.bohmann@googlemail.com
>>>>>>> <ma...@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.korherr@gmail.com
>>>>>>> <ma...@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
>>>>>>> <jankeesvanandel@gmail.com
>>>>>>> <ma...@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.korherr@gmail.com
>>>>>>> <ma...@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
>>>>>>> >> >>
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >
>>>>>>> >
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: [core] Introducing implee6 - MYFACES-2579
Posted by Jan-Kees van Andel <ja...@gmail.com>.
Why not override the compiler plugin in the module to use JDK 6?
I think the whole point about the module is ease of development and this
will suffer when putting it in a separate jar.
About the manual classpath scanning or other runtime stuff. This should not
break because of JDK 6 stuff, since the bytecode should be backwards
compatible.
My 2 cents...
/JK
2010/3/11 Leonardo Uribe <lu...@gmail.com>
> Hi
>
> I'm working with jdk 1.5 and when I tried to compile current20 branch I
> have an error. This means to create myfaces jars it should be compiled with
> jdk 1.6, because implee6 has dependencies with jars with java 1.6 specific
> code:
>
> [INFO]
> ------------------------------------------------------------------------
> [ERROR] BUILD FAILURE
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Compilation failure
>
> D:\workspace\myfaces\current20\core\implee6\src\main\java\org\apache\myfaces\ee6
> \MyFacesContainerInitializer.java:[47,-1] cannot access
> javax.servlet.ServletCon
> tainerInitializer
> bad class file: C:\Documents and
> Settings\lu4242\.m2\repository\javax\javaee-web
>
> -api\6.0\javaee-web-api-6.0.jar(javax/servlet/ServletContainerInitializer.class)
>
> class file has wrong version 50.0, should be 49.0
>
> In theory, we can't do this, because if we do, myfaces-impl has one class
> jdk 1.6 specific, and jsf 2.0 is jdk 1.5 compatible. Now, in the practice
> this class is not loaded by any part of myfaces, but maybe some program that
> tries to scan the classpath and load this class into the classpath will see
> the problem.
>
> My personal opinion is implee6 should have its own separate jar with some
> OSGi specific stuff, so if someone wants to use it it should put three jars
> on the classpath: myfaces-api, myfaces-impl, myfaces-implee6. We have a lot
> of precedences for that kind of stuff (orchestra core and core15 for
> example, tomahawk sandbox and sandbox15).
>
> I also think this code should be moved to myfaces commons, because keep it
> as a module in core project means we have to use jdk 1.6 to compile all
> artifacts and we have a plugin that checks for jdk 1.5 compatibility that
> will fail (see checkJDK profile on myfaces impl pom).
>
> Suggestions are welcome.
>
> regards,
>
> Leonardo Uribe
>
>
> 2010/3/8 Jakob Korherr <ja...@gmail.com>
>
>> Hi,
>>
>> So I committed everything. Please feel free to test it - I am curious
>> about your opinions :)
>>
>> Regards,
>> Jakob
>>
>> 2010/3/8 Jakob Korherr <ja...@gmail.com>
>>
>> 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 <ge...@gmail.com>
>>>
>>> +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 <we...@gmail.com>
>>>>
>>>> +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 <jankeesvanandel@gmail.com
>>>>>> <ma...@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.korherr@gmail.com
>>>>>> <ma...@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 <jankeesvanandel@gmail.com
>>>>>> <ma...@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.korherr@gmail.com
>>>>>> <ma...@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.bohmann@googlemail.com
>>>>>> <ma...@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.korherr@gmail.com
>>>>>> <ma...@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.bohmann@googlemail.com
>>>>>> <ma...@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.korherr@gmail.com
>>>>>> <ma...@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
>>>>>> <jankeesvanandel@gmail.com
>>>>>> <ma...@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.korherr@gmail.com
>>>>>> <ma...@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
>>>>>> >> >>
>>>>>> >> >
>>>>>> >> >
>>>>>> >
>>>>>> >
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
Re: [core] Introducing implee6 - MYFACES-2579
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi
I'm working with jdk 1.5 and when I tried to compile current20 branch I have
an error. This means to create myfaces jars it should be compiled with jdk
1.6, because implee6 has dependencies with jars with java 1.6 specific code:
[INFO]
------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
[INFO] Compilation failure
D:\workspace\myfaces\current20\core\implee6\src\main\java\org\apache\myfaces\ee6
\MyFacesContainerInitializer.java:[47,-1] cannot access
javax.servlet.ServletCon
tainerInitializer
bad class file: C:\Documents and
Settings\lu4242\.m2\repository\javax\javaee-web
-api\6.0\javaee-web-api-6.0.jar(javax/servlet/ServletContainerInitializer.class)
class file has wrong version 50.0, should be 49.0
In theory, we can't do this, because if we do, myfaces-impl has one class
jdk 1.6 specific, and jsf 2.0 is jdk 1.5 compatible. Now, in the practice
this class is not loaded by any part of myfaces, but maybe some program that
tries to scan the classpath and load this class into the classpath will see
the problem.
My personal opinion is implee6 should have its own separate jar with some
OSGi specific stuff, so if someone wants to use it it should put three jars
on the classpath: myfaces-api, myfaces-impl, myfaces-implee6. We have a lot
of precedences for that kind of stuff (orchestra core and core15 for
example, tomahawk sandbox and sandbox15).
I also think this code should be moved to myfaces commons, because keep it
as a module in core project means we have to use jdk 1.6 to compile all
artifacts and we have a plugin that checks for jdk 1.5 compatibility that
will fail (see checkJDK profile on myfaces impl pom).
Suggestions are welcome.
regards,
Leonardo Uribe
2010/3/8 Jakob Korherr <ja...@gmail.com>
> Hi,
>
> So I committed everything. Please feel free to test it - I am curious about
> your opinions :)
>
> Regards,
> Jakob
>
> 2010/3/8 Jakob Korherr <ja...@gmail.com>
>
> 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 <ge...@gmail.com>
>>
>> +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 <we...@gmail.com>
>>>
>>> +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 <jankeesvanandel@gmail.com
>>>>> <ma...@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.korherr@gmail.com
>>>>> <ma...@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 <jankeesvanandel@gmail.com
>>>>> <ma...@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.korherr@gmail.com
>>>>> <ma...@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.bohmann@googlemail.com
>>>>> <ma...@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.korherr@gmail.com
>>>>> <ma...@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.bohmann@googlemail.com
>>>>> <ma...@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.korherr@gmail.com
>>>>> <ma...@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
>>>>> <jankeesvanandel@gmail.com
>>>>> <ma...@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.korherr@gmail.com
>>>>> <ma...@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
>>>>> >> >>
>>>>> >> >
>>>>> >> >
>>>>> >
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
Re: [core] Introducing implee6 - MYFACES-2579
Posted by Jakob Korherr <ja...@gmail.com>.
Hi,
So I committed everything. Please feel free to test it - I am curious about
your opinions :)
Regards,
Jakob
2010/3/8 Jakob Korherr <ja...@gmail.com>
> 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 <ge...@gmail.com>
>
> +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 <we...@gmail.com>
>>
>> +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 <jankeesvanandel@gmail.com
>>>> <ma...@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.korherr@gmail.com
>>>> <ma...@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 <jankeesvanandel@gmail.com
>>>> <ma...@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.korherr@gmail.com
>>>> <ma...@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.bohmann@googlemail.com
>>>> <ma...@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.korherr@gmail.com
>>>> <ma...@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.bohmann@googlemail.com
>>>> <ma...@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.korherr@gmail.com
>>>> <ma...@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
>>>> <jankeesvanandel@gmail.com
>>>> <ma...@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.korherr@gmail.com
>>>> <ma...@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
>>>> >> >>
>>>> >> >
>>>> >> >
>>>> >
>>>> >
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>
Re: [core] Introducing implee6 - MYFACES-2579
Posted by Jakob Korherr <ja...@gmail.com>.
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 <ge...@gmail.com>
> +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 <we...@gmail.com>
>
> +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 <jankeesvanandel@gmail.com
>>> <ma...@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.korherr@gmail.com
>>> <ma...@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 <jankeesvanandel@gmail.com
>>> <ma...@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.korherr@gmail.com
>>> <ma...@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.bohmann@googlemail.com
>>> <ma...@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.korherr@gmail.com
>>> <ma...@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.bohmann@googlemail.com
>>> <ma...@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.korherr@gmail.com
>>> <ma...@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
>>> <jankeesvanandel@gmail.com
>>> <ma...@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.korherr@gmail.com
>>> <ma...@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
>>> >> >>
>>> >> >
>>> >> >
>>> >
>>> >
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
Re: [core] Introducing implee6 - MYFACES-2579
Posted by Gerhard Petracek <ge...@gmail.com>.
+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 <we...@gmail.com>
> +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 <jankeesvanandel@gmail.com
>> <ma...@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.korherr@gmail.com
>> <ma...@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 <jankeesvanandel@gmail.com
>> <ma...@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.korherr@gmail.com
>> <ma...@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.bohmann@googlemail.com
>> <ma...@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.korherr@gmail.com
>> <ma...@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.bohmann@googlemail.com
>> <ma...@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.korherr@gmail.com
>> <ma...@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
>> <jankeesvanandel@gmail.com
>> <ma...@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.korherr@gmail.com
>> <ma...@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
>> >> >>
>> >> >
>> >> >
>> >
>> >
>>
>>
>>
>>
>>
>>
>>
>
>
Re: [core] Introducing implee6 - MYFACES-2579
Posted by Werner Punz <we...@gmail.com>.
+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 <jankeesvanandel@gmail.com
> <ma...@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.korherr@gmail.com
> <ma...@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 <jankeesvanandel@gmail.com
> <ma...@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.korherr@gmail.com
> <ma...@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.bohmann@googlemail.com
> <ma...@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.korherr@gmail.com
> <ma...@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.bohmann@googlemail.com
> <ma...@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.korherr@gmail.com
> <ma...@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
> <jankeesvanandel@gmail.com
> <ma...@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.korherr@gmail.com
> <ma...@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
> >> >>
> >> >
> >> >
> >
> >
>
>
>
>
>
>
Re: [core] Introducing implee6 - MYFACES-2579
Posted by Jakob Korherr <ja...@gmail.com>.
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 <ja...@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 <ja...@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 <ja...@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 <ja...@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 <be...@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 <ja...@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 <be...@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.korherr@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 <ja...@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 <ja...@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
>>>>> >> >>
>>>>> >> >
>>>>> >> >
>>>>> >
>>>>> >
>>>>>
>>>>
>>>>
>>>
>>
>
Re: [core] Introducing implee6 - MYFACES-2579
Posted by Jan-Kees van Andel <ja...@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 <ja...@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 <ja...@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 <ja...@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 <be...@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 <ja...@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 <be...@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.korherr@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 <ja...@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 <ja...@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
>>>> >> >>
>>>> >> >
>>>> >> >
>>>> >
>>>> >
>>>>
>>>
>>>
>>
>
Re: [core] Introducing implee6 - MYFACES-2579
Posted by Jakob Korherr <ja...@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 <ja...@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 <ja...@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 <be...@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 <ja...@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 <be...@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.korherr@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 <ja...@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 <ja...@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
>>> >> >>
>>> >> >
>>> >> >
>>> >
>>> >
>>>
>>
>>
>
Re: [core] Introducing implee6 - MYFACES-2579
Posted by Jan-Kees van Andel <ja...@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 <ja...@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 <be...@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 <ja...@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 <be...@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.korherr@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 <ja...@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 <ja...@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
>> >> >>
>> >> >
>> >> >
>> >
>> >
>>
>
>
Re: [core] Introducing implee6 - MYFACES-2579
Posted by Jakob Korherr <ja...@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 <be...@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 <ja...@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 <be...@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 <ja...@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 <ja...@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 <ja...@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
> >> >>
> >> >
> >> >
> >
> >
>
Re: [core] Introducing implee6 - MYFACES-2579
Posted by Bernd Bohmann <be...@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 <ja...@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 <be...@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 <ja...@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 <ja...@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 <ja...@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
>> >>
>> >
>> >
>
>
Re: [core] Introducing implee6 - MYFACES-2579
Posted by Jakob Korherr <ja...@gmail.com>.
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 <be...@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 <ja...@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 <ja...@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 <ja...@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
> >>
> >
> >
>
Re: [core] Introducing implee6 - MYFACES-2579
Posted by Bernd Bohmann <be...@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 <ja...@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 <ja...@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 <ja...@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
>>
>
>
Re: [core] Introducing implee6 - MYFACES-2579
Posted by Jakob Korherr <ja...@gmail.com>.
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 <ja...@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 <ja...@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
>>
>
>
Re: [core] Introducing implee6 - MYFACES-2579
Posted by Jan-Kees van Andel <ja...@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 <ja...@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
>