Hi,
1. All classes in org.apache.myfaces.spi.
I did not change anything here, just internal imports (from *.spi.impl
to *.spi.util)!
2. All classes that has to be with LifecycleProvider (@PostConstruct
annotation). Such classes should be on spi package, but note spi work
started after 2.0
Hi
2011/7/11 Jakob Korherr jakob.korh...@gmail.com:
Hi,
1. All classes in org.apache.myfaces.spi.
I did not change anything here, just internal imports (from *.spi.impl
to *.spi.util)!
It is questionable to create .spi.util. After all, it is not supposed
that package be consumed by
Hi,
No, sorry Leo, they are not enough. Frankly, I don't understand why
you are blocking this solution. It is easy, it does not break anything
(if we do not change the package names), it is a lot more clean and we
can get rid of the shaded-impl module. If we don't do this now, we
will maybe have
Hi
I'll be clear and direct. What makes statements true or false are the
reasons behind it. Until this moment, you are not question the reasons
behind the reasoning proposed.
To be short, my argumentation is we can't change for now:
1. Everything inside org.apache.myfaces.spi
2.
Hi,
Leo, I really get your point that we can't change this stuff. Changing
SPI stuff (even just renaming packages) will break application server
integation code, we all got it now..
That's why I suggested (a few mails ago, but unfortunately too vague)
keeping the package names *.spi, *.spi.impl
hi jakob,
i suggest the same approach like before. last time leo requested some
changes and had to start the vote (with a short description) and this time
it's your turn.
if you feel that we need a vote about it, please feel free to start one.
regards,
gerhard
http://www.irian.at
Your JSF
Hi Gerhard,
OK, thx. Will do so!
Regards,
Jakob
2011/7/11 Gerhard Petracek gerhard.petra...@gmail.com:
hi jakob,
i suggest the same approach like before. last time leo requested some
changes and had to start the vote (with a short description) and this time
it's your turn.
if you feel that
Hi
2011/7/11 Jakob Korherr jakob.korh...@gmail.com:
Hi,
Leo, I really get your point that we can't change this stuff. Changing
SPI stuff (even just renaming packages) will break application server
integation code, we all got it now..
That's why I suggested (a few mails ago, but
Hi
2011/7/11 Gerhard Petracek gerhard.petra...@gmail.com:
hi jakob,
i suggest the same approach like before. last time leo requested some
changes and had to start the vote (with a short description) and this time
it's your turn.
if you feel that we need a vote about it, please feel free to
hi leo,
if both of you agree on the rest, we won't need a vote - that's right.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/7/12 Leonardo Uribe lu4...@gmail.com
Hi
Hi Gerhard
Ok, in theory the parts that we should not change, or otherwise that
will trigger a change on JEE containers are:
1. All classes in org.apache.myfaces.spi.
2. All classes that has to be with LifecycleProvider (@PostConstruct
annotation). Such classes should be on spi package, but note
Hi
Good to know that. Unfortunately, do a change on the spi related
classes will break existing integration code with containers like
Geronimo, JBoss and others too. Considering this, I think the costs
involved on the changes proposed are too big compared with the
benefits, which are very limited
hi leo,
thx for checking it.
it would be great, if you can post a list of parts (not classes) which would
break. so we can discuss this topic in a more concrete manner.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Hi guys,
We currently use the shaded-impl module in core 2.1.x to solve a
cyclic dependency problem. However, this introduces redundancy and
complexity and may lead to some strange issues. This can be solved by
the introduction of a myfaces-spi module (which is then packed
together with
+1
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/7/8 Jakob Korherr jakob.korh...@gmail.com
Hi guys,
We currently use the shaded-impl module in core 2.1.x to solve a
Hi
In principle I agree with this change, but after a quick patch review
I saw some package relocation for some classes (from
org.apache.myfaces.config.element to org.apache.myfaces.spi.data).
Those changes will break extensions scripting code. Such changes
should be done between major versions
hi,
thx for reviewing the changes.
for sure we can discuss when we are going to do such changes. however, if
ext-script is the only reason against it, we can do it right now imo.
there is no problem with shipping a small update of ext-script and the user
base is currently small enough to
Hi
Thinking more about it, I have a question about this change. The
intention of shaded-impl, is do some hack to allow use some classes
provided in impl (spi package, StartupServletExternalContextImpl ... )
for implee6 module. As soon as our implementation requires JDK 1.6,
this hack will be
I have no problem if you break Ext-Script, after all I program against
the impl, so whatever change you do I have to patch it in my codebase
anyway.
Don´t feel stopped by it.
Werner
Am 08.07.11 18:27, schrieb Gerhard Petracek:
hi,
thx for reviewing the changes.
for sure we can discuss
19 matches
Mail list logo
