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.korh...@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.korh...@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.petra...@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.p...@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 <jankeesvanan...@gmail.com
>>>>> <mailto:jankeesvanan...@gmail.com>>
>>>>>
>>>>>
>>>>>    Agreed, I was only thinking of one parameter: A parameter to turn
>>>>>    the entire StartupListener off.
>>>>>
>>>>>    I look at it as a binary thing. Either the developer chooses to go
>>>>>    with the flow with no custimization, OR he chooses to customize
>>>>>    everything.
>>>>>
>>>>>    I.e. org.apache.myfaces.DISABLE_FACES_SERVLET_AUTODEPLOY = true
>>>>>    (default false)
>>>>>
>>>>>    I think this will cover all use cases, where some may require a bit
>>>>>    more configuration, but still work...
>>>>>
>>>>>    /JK
>>>>>
>>>>>
>>>>>    2010/3/7 Jakob Korherr <jakob.korh...@gmail.com
>>>>>    <mailto:jakob.korh...@gmail.com>>
>>>>>
>>>>>
>>>>>        Yep!
>>>>>
>>>>>        We can discuss this stuff when the submodule is in place. Such
>>>>>        things are very easy to change/configure in the StartupListener.
>>>>>
>>>>>        However, I think we should come up with a very standard default
>>>>>        configuration. If the user wants something different, he will
>>>>>        have to configure the mapping himself in the web.xml just as it
>>>>>        is now. I am not a fan of too many configuration parameters
>>>>>        which interfere with other configuration methods.
>>>>>
>>>>>        Regards,
>>>>>        Jakob
>>>>>
>>>>>        2010/3/7 Jan-Kees van Andel <jankeesvanan...@gmail.com
>>>>>        <mailto:jankeesvanan...@gmail.com>>
>>>>>
>>>>>
>>>>>            In other words: Convention over configuration ;-)
>>>>>
>>>>>            I just think it's important to pick sensible defaults and to
>>>>>            be able to turn it off, for example using a context-param.
>>>>>
>>>>>            For example, I think the mapping *.xhtml should also be
>>>>>            default, but a developer must be able to turn *.xhtml off,
>>>>>            since it's a widely used extension also outside of JSF...
>>>>>
>>>>>            Regards,
>>>>>            Jan-Kees
>>>>>
>>>>>
>>>>>            2010/3/7 Jakob Korherr <jakob.korh...@gmail.com
>>>>>            <mailto:jakob.korh...@gmail.com>>
>>>>>
>>>>>
>>>>>                Hi Bernd,
>>>>>
>>>>>                For some users it may be so ;) :D
>>>>>
>>>>>                Look Bernd, it's not that big thing. It's just a class
>>>>>                and a text file. So it is by no means a problem to ship
>>>>>                this with MyFaces Core 2. Also Mojarra does something
>>>>>                similar too!
>>>>>
>>>>>                To your question: Nope! I just add the FacesServlet and
>>>>>                the standard mappings /faces/*, *.jsf and maybe also
>>>>>                *.faces, if there are no entries for the FacesServlet in
>>>>>                the web.xml. If a user wants something special, he do
>>>>>                will have to configure it in his web.xml. In this
>>>>>                scenario my StartupListener will just do nothing.
>>>>>
>>>>>
>>>>>                Regards,
>>>>>                Jakob
>>>>>
>>>>>                2010/3/6 Bernd Bohmann <bernd.bohm...@googlemail.com
>>>>>                <mailto:bernd.bohm...@googlemail.com>>
>>>>>
>>>>>
>>>>>                    Hello Jakob,
>>>>>
>>>>>                    do you really think adding an other dependency is a
>>>>>                    real problem?
>>>>>                    How do you configure prefix or suffix mapping? For
>>>>>                    each possible
>>>>>                    configuration option an own impl version?
>>>>>
>>>>>                    Regards
>>>>>
>>>>>                    Bernd
>>>>>
>>>>>
>>>>>                    On Sat, Mar 6, 2010 at 4:48 PM, Jakob Korherr
>>>>>                    <jakob.korh...@gmail.com
>>>>>                    <mailto:jakob.korh...@gmail.com>> wrote:
>>>>>                     > Hi Bernd,
>>>>>                     >
>>>>>                     > If this module wouldn't be a part of myfaces
>>>>>                    core, the users still would
>>>>>                     > have to configure something to run their
>>>>>                    MyFaces-2 apps in a EE6 container
>>>>>                     > (e.g. they'd have to include myfaces commons),
>>>>>                    which is not the target. The
>>>>>                     > target is to get rid of any unnecessary
>>>>>                    configuration to make the
>>>>>                     > development process easier!
>>>>>                     >
>>>>>                     > Regards,
>>>>>                     > Jakob
>>>>>                     >
>>>>>                     > 2010/3/6 Bernd Bohmann
>>>>>                    <bernd.bohm...@googlemail.com
>>>>>                    <mailto:bernd.bohm...@googlemail.com>>
>>>>>
>>>>>                     >>
>>>>>                     >> Hello Jakob,
>>>>>                     >>
>>>>>                     >> I'm not really sure that this feature should be
>>>>>                    part of myfaces-core.
>>>>>                     >> Maybe myfaces-commons would be a better place.
>>>>>                    But we can change this
>>>>>                     >> later.
>>>>>                     >>
>>>>>                     >> +1 on commiting the module.
>>>>>                     >>
>>>>>                     >> Regards
>>>>>                     >>
>>>>>                     >> Bernd
>>>>>                     >>
>>>>>                     >> On Sat, Mar 6, 2010 at 4:32 PM, Jakob Korherr
>>>>>                    <jakob.korh...@gmail.com
>>>>>                    <mailto:jakob.korh...@gmail.com>>
>>>>>
>>>>>                     >> wrote:
>>>>>                     >> > Hi Jan-Kees,
>>>>>                     >> >
>>>>>                     >> > Great :)
>>>>>                     >> >
>>>>>                     >> > I am currently testing on Tomcat, Jetty,
>>>>>                    GlassFish v3 and JBoss 6!
>>>>>                     >> >
>>>>>                     >> > Regards,
>>>>>                     >> > Jakob
>>>>>                     >> >
>>>>>                     >> > 2010/3/6 Jan-Kees van Andel
>>>>>                    <jankeesvanan...@gmail.com
>>>>>                    <mailto:jankeesvanan...@gmail.com>>
>>>>>
>>>>>                     >> >>
>>>>>                     >> >> Hey,
>>>>>                     >> >>
>>>>>                     >> >> If it works on Jetty and Tomcat, I'd say +1
>>>>>                    on committing the module.
>>>>>                     >> >>
>>>>>                     >> >> I can't think of big issues with committing
>>>>>                    it as a separate module.
>>>>>                     >> >> And
>>>>>                     >> >> we can always revert if we have to.
>>>>>                     >> >>
>>>>>                     >> >> Cool, can't wait to check it out! On what
>>>>>                    appserver are you testing
>>>>>                     >> >> this
>>>>>                     >> >> stuff Jakob?
>>>>>                     >> >>
>>>>>                     >> >> Regards,
>>>>>                     >> >> Jan-Kees
>>>>>                     >> >>
>>>>>                     >> >>
>>>>>                     >> >> 2010/3/6 Jakob Korherr
>>>>>                    <jakob.korh...@gmail.com
>>>>>                    <mailto:jakob.korh...@gmail.com>>
>>>>>
>>>>>                     >> >>>
>>>>>                     >> >>> Hi guys,
>>>>>                     >> >>>
>>>>>                     >> >>> I managed to introduce the core submodule
>>>>>                    "implee6" on my local
>>>>>                     >> >>> machine.
>>>>>                     >> >>> This new submodule includes Java EE 6
>>>>>                    dependencies and thus you can
>>>>>                     >> >>> use
>>>>>                     >> >>> Servlet API 3.0 and other new things in it.
>>>>>                     >> >>>
>>>>>                     >> >>> When building MyFaces, this new submodule is
>>>>>                    built before the normal
>>>>>                     >> >>> impl
>>>>>                     >> >>> submodule. Then the .class and the .java
>>>>>                    files are "injected" into the
>>>>>                     >> >>> impl-build. This is very similar to how
>>>>>                    shared_impl is included in the
>>>>>                     >> >>> myfaces-impl build at the moment, but
>>>>>                    without recompilation.
>>>>>                     >> >>>
>>>>>                     >> >>> In this way we are able to use the new
>>>>>                    services approach of Java EE 6
>>>>>                     >> >>> to
>>>>>                     >> >>> get rid of the Faces Servlet entries in
>>>>>                    web.xml, because in any Java
>>>>>                     >> >>> EE 6
>>>>>                     >> >>> container we can configure this dynamically
>>>>>                    at startup (see
>>>>>                     >> >>> MYFACES-2579 for
>>>>>                     >> >>> details). This also works fantastically on
>>>>>                    my local machine - it's
>>>>>                     >> >>> really
>>>>>                     >> >>> cool!
>>>>>                     >> >>>
>>>>>                     >> >>> Also with this method we are still Java EE 5
>>>>>                    complaint, because the EE
>>>>>                     >> >>> 6
>>>>>                     >> >>> classes just won't get loaded in a non EE 6
>>>>>                    environment, because there
>>>>>                     >> >>> are
>>>>>                     >> >>> no dependencies from impl or shared to them.
>>>>>                    They are only called (and
>>>>>                     >> >>> loaded) by a Java EE 6 container via the
>>>>>                    services definition.
>>>>>                     >> >>>
>>>>>                     >> >>> Furthermore I noticed that the Mojarra guys
>>>>>                    also include a similar
>>>>>                     >> >>> solution to this in their newest build!
>>>>>                     >> >>>
>>>>>                     >> >>> Now, before I commit something of this, I
>>>>>                    wanted to ask if there are
>>>>>                     >> >>> any
>>>>>                     >> >>> objections with this proposal. If so, please
>>>>>                    tell me your concerns!
>>>>>                     >> >>>
>>>>>                     >> >>> Regards,
>>>>>                     >> >>> Jakob
>>>>>                     >> >>
>>>>>                     >> >
>>>>>                     >> >
>>>>>                     >
>>>>>                     >
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>

Reply via email to