myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Kienenberger <mkien...@gmail.com>
Subject Re: [core] Introducing implee6 - MYFACES-2579
Date Thu, 11 Mar 2010 21:36:46 GMT
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 <lu4242@gmail.com> wrote:
> Hi
>
> 2010/3/11 Jakob Korherr <jakob.korherr@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 <lu4242@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 <jankeesvanandel@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 <lu4242@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 <jakob.korherr@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 <jakob.korherr@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 <gerhard.petracek@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 <werner.punz@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
>>>>>>>>>> <mailto:jankeesvanandel@gmail.com>>
>>>>>>>>>>
>>>>>>>>>>    Agreed, I was only thinking of one parameter:
A parameter to
>>>>>>>>>> turn
>>>>>>>>>>    the entire StartupListener off.
>>>>>>>>>>
>>>>>>>>>>    I look at it as a binary thing. Either the developer
chooses to
>>>>>>>>>> go
>>>>>>>>>>    with the flow with no custimization, OR he chooses
to customize
>>>>>>>>>>    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
>>>>>>>>>>    <mailto:jakob.korherr@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
>>>>>>>>>>        <mailto:jankeesvanandel@gmail.com>>
>>>>>>>>>>
>>>>>>>>>>            In other words: Convention over
configuration ;-)
>>>>>>>>>>
>>>>>>>>>>            I just think it's important to pick
sensible defaults
>>>>>>>>>> and to
>>>>>>>>>>            be able to turn it off, for example
using a
>>>>>>>>>> context-param.
>>>>>>>>>>
>>>>>>>>>>            For example, I think the mapping
*.xhtml should also be
>>>>>>>>>>            default, but a developer must be
able to turn *.xhtml
>>>>>>>>>> off,
>>>>>>>>>>            since it's a widely used extension
also outside of
>>>>>>>>>> JSF...
>>>>>>>>>>
>>>>>>>>>>            Regards,
>>>>>>>>>>            Jan-Kees
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>            2010/3/7 Jakob Korherr <jakob.korherr@gmail.com
>>>>>>>>>>            <mailto:jakob.korherr@gmail.com>>
>>>>>>>>>>
>>>>>>>>>>                Hi Bernd,
>>>>>>>>>>
>>>>>>>>>>                For some users it may be so
;) :D
>>>>>>>>>>
>>>>>>>>>>                Look Bernd, it's not that
big thing. It's just a
>>>>>>>>>> class
>>>>>>>>>>                and a text file. So it is
by no means a problem to
>>>>>>>>>> ship
>>>>>>>>>>                this with MyFaces Core 2.
Also Mojarra does
>>>>>>>>>> something
>>>>>>>>>>                similar too!
>>>>>>>>>>
>>>>>>>>>>                To your question: Nope! I
just add the FacesServlet
>>>>>>>>>> and
>>>>>>>>>>                the standard mappings /faces/*,
*.jsf and maybe
>>>>>>>>>> also
>>>>>>>>>>                *.faces, if there are no entries
for the
>>>>>>>>>> FacesServlet in
>>>>>>>>>>                the web.xml. If a user wants
something special, he
>>>>>>>>>> do
>>>>>>>>>>                will have to configure it
in his web.xml. In this
>>>>>>>>>>                scenario my StartupListener
will just do nothing.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                Regards,
>>>>>>>>>>                Jakob
>>>>>>>>>>
>>>>>>>>>>                2010/3/6 Bernd Bohmann
>>>>>>>>>> <bernd.bohmann@googlemail.com
>>>>>>>>>>                <mailto:bernd.bohmann@googlemail.com>>
>>>>>>>>>>
>>>>>>>>>>                    Hello Jakob,
>>>>>>>>>>
>>>>>>>>>>                    do you really think
adding an other dependency
>>>>>>>>>> is a
>>>>>>>>>>                    real problem?
>>>>>>>>>>                    How do you configure
prefix or suffix mapping?
>>>>>>>>>> For
>>>>>>>>>>                    each possible
>>>>>>>>>>                    configuration option
an own impl version?
>>>>>>>>>>
>>>>>>>>>>                    Regards
>>>>>>>>>>
>>>>>>>>>>                    Bernd
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                    On Sat, Mar 6, 2010
at 4:48 PM, Jakob Korherr
>>>>>>>>>>                    <jakob.korherr@gmail.com
>>>>>>>>>>                    <mailto:jakob.korherr@gmail.com>>
wrote:
>>>>>>>>>>                     > Hi Bernd,
>>>>>>>>>>                     >
>>>>>>>>>>                     > If this module
wouldn't be a part of myfaces
>>>>>>>>>>                    core, the users still
would
>>>>>>>>>>                     > have to configure
something to run their
>>>>>>>>>>                    MyFaces-2 apps in a
EE6 container
>>>>>>>>>>                     > (e.g. they'd have
to include myfaces
>>>>>>>>>> commons),
>>>>>>>>>>                    which is not the target.
The
>>>>>>>>>>                     > target is to get
rid of any unnecessary
>>>>>>>>>>                    configuration to make
the
>>>>>>>>>>                     > development process
easier!
>>>>>>>>>>                     >
>>>>>>>>>>                     > Regards,
>>>>>>>>>>                     > Jakob
>>>>>>>>>>                     >
>>>>>>>>>>                     > 2010/3/6 Bernd
Bohmann
>>>>>>>>>>                    <bernd.bohmann@googlemail.com
>>>>>>>>>>                    <mailto:bernd.bohmann@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
>>>>>>>>>>                    <mailto: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
>>>>>>>>>>                    <jankeesvanandel@gmail.com
>>>>>>>>>>                    <mailto:jankeesvanandel@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
>>>>>>>>>>                    <mailto:jakob.korherr@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
>>>>>>>>>>                     >> >>
>>>>>>>>>>                     >> >
>>>>>>>>>>                     >> >
>>>>>>>>>>                     >
>>>>>>>>>>                     >
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>

Mime
View raw message