myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Korherr <jakob.korh...@gmail.com>
Subject Re: [core] Introducing implee6 - MYFACES-2579
Date Thu, 11 Mar 2010 22:39:29 GMT
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 <lu4242@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 <jakob.korherr@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 <jakob.korherr@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 <lu4242@gmail.com>
>>>
>>>> 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