Thanks, Jakob and Leonardo, the new changes work perfect ;-)
By the way, I have run the TCK on my local environment, although there are
some failure cases, they should be caused by webbeans integration.
2010/12/11 Jakob Korherr jakob.korh...@gmail.com
Hi guys,
As discussed, I just committed a
Hi
Good to know that, thanks. In these moments I'm running the necessary steps
for send the vote, so I hope to release these artifacts this week.
regards,
Leonardo Uribe
2010/12/13 Ivan xhh...@gmail.com
Thanks, Jakob and Leonardo, the new changes work perfect ;-)
By the way, I have run the
Hi,
OK, great! I added another comment to MYFACES-2945 explaining why I
did it this way.
Please tell me your final opinion after reading this comment and I'll
commit an appropriate version of the proposed patch!
Regards,
Jakob
2010/12/9 Leonardo Uribe lu4...@gmail.com:
Hi
I think it is not
Hi Jakob
I think it is better do not include it as parameter and instead add some
comment on the javadoc,
saying the information to take into account is retrieved from
FacesConfigurationProvider. The fact
of use FacesConfigurationProvider is more an implementation detail than a
requeriment, so if
Hi Leo,
OK great. That's fine with me.
I will apply the appropriate changes and commit the patch!
Regards,
Jakob
2010/12/10 Leonardo Uribe lu4...@gmail.com:
Hi Jakob
I think it is better do not include it as parameter and instead add some
comment on the javadoc,
saying the information to
Hi guys,
As discussed, I just committed a modified version of the proposed patch.
Furthermore I added the custom SPI impl that I used for testing to the
issue [1] which may help for the real Geronimo impl.
It would be great if you guys could check if this solution works for
you, and if so, we
Hi,
I called it ugly, because of its implementation code in
DefaultFacesConfigurationProvider: The method is already inside of a
FacesConfigurationProvider, but it does this:
FacesConfigurationProvider provider = FacesConfigurationProviderFactory.
Hi guys,
I just uploaded a patch for a FacesConfigurationMerger SPI:
MYFACES-2945-FacesConfigurationMerger.patch
Furthermore I added a quick code sample as comment on the MYFACES-2945
issue about how Geronimo can use this new SPI.
Please take a look at the patch and if there are no objections,
Hi
I think it is not necessary to pass FacesConfigurationProvider as param for
getFacesConfigData, because in theory we don't do anything with it before
pass it and wrappers will not do anything with it later. I think it looks
good to load it using
Hi guys,
I really see no reason why Geronimo should implement its own
faces-config merging and ordering algorithm or even have to think
about relying on MyFaces internals. IMHO getFacesConfigData() should
be removed from FacesConfigurationProvider, because this algorithm
does not have to be
Hi
I agree with Jakob about faces-config merging and ordering algorithm should
not be exposed by MyFaces. Why is it not enough?. At this point it is not
clear the reasons. Note in this moment ordering and sorting algoritm it is
not being exposed by FacesConfigurationProvider interface.
Other
my 2 cents, it seems for me less urgly ...
a. For the FacesConfigurationProvider , it is better to have only one method
getFacesConfigData()
b. Create another abstract class AbstractFacesConfigurationProvider which
extends FacesConfigurationProvider, and define those proctected methods of
get***,
Hi
2010/12/6 Ivan xhh...@gmail.com
So, at least could you please help to add the export the
org.apache.myfaces.config package in 2.0.3, that will make my life easier
now. And remove it once those methods are moved to
FacesConfigurationProvider in the future.
Instead do that, it is
On Dec 7, 2010, at 10:12 AM, Leonardo Uribe wrote:
Hi
2010/12/6 Ivan xhh...@gmail.com
So, at least could you please help to add the export the
org.apache.myfaces.config package in 2.0.3, that will make my life easier
now. And remove it once those methods are moved to
Hi
2010/12/7 David Jencks david_jen...@yahoo.com
On Dec 7, 2010, at 10:12 AM, Leonardo Uribe wrote:
Hi
2010/12/6 Ivan xhh...@gmail.com
So, at least could you please help to add the export the
org.apache.myfaces.config package in 2.0.3, that will make my life easier
now. And remove
Thanks for tacking this, Leonardo.
I am not sure I understand the changes. Moving methods to the
FacesConfigurationProvider is required, but it seems to me that it is not
enough. With this spi, do I still need to provide those sorting/merging/...
methods ?
The only way I could see now is that, a.
On Dec 5, 2010, at 7:44 PM, Ivan wrote:
I am wondering whether the myfaces bundle could also export the spi.impl
package, I hope to take advantage of some codes there, e.g.
DefaultFacesConfigurationProvider, it contains some sort algorithm.
thanks.
I'd say if you need to expose the
2010/12/6 David Jencks david_jen...@yahoo.com
On Dec 5, 2010, at 7:44 PM, Ivan wrote:
I am wondering whether the myfaces bundle could also export the spi.impl
package, I hope to take advantage of some codes there, e.g.
DefaultFacesConfigurationProvider, it contains some sort algorithm.
Hi
First of all, I want to note that if the default algorithm for
FacesConfigResourceProvider is not able to find a.faces-config.xml and
c.faces-config.xml, that means the Thread Context Class Loader needs to be
fixed, because is not taking into account jar files under WEB-INF/lib.
2010/12/6
Some detailed information :
a. org.apache.myfaces.config.impl.digester -
DigesterFacesConfigUnmarshallerImpl
b. org.apache.myfaces.config - DefaultFacesConfigurationProvider
c. org.apache.myfaces.spi.impl - ServletMappingImpl
For item c, I have removed the use of ServletMappingImpl, so no need to
Hi
2010/12/6 Ivan xhh...@gmail.com
Some detailed information :
a. org.apache.myfaces.config.impl.digester -
DigesterFacesConfigUnmarshallerImpl
b. org.apache.myfaces.config - DefaultFacesConfigurationProvider
c. org.apache.myfaces.spi.impl - ServletMappingImpl
For item c, I have removed
2010/12/7 Leonardo Uribe lu4...@gmail.com
Hi
2010/12/6 Ivan xhh...@gmail.com
Some detailed information :
a. org.apache.myfaces.config.impl.digester -
DigesterFacesConfigUnmarshallerImpl
b. org.apache.myfaces.config - DefaultFacesConfigurationProvider
c. org.apache.myfaces.spi.impl -
*To: *David Jencks david_jen...@yahoo.com
*Subject: **Re: ordering tck failures in geronimo*
Hi David
I tried to run the test files in tomcat:
jsf_appconfigresources_absolute_ordering_web
jsf_appconfigresources_startupbehavior_web
jsf_appconfigresources_relative_ordering_web
Obviously doing
AM PST
*To: *David Jencks david_jen...@yahoo.com
*Subject: **Re: ordering tck failures in geronimo*
Hi David
I tried to run the test files in tomcat:
jsf_appconfigresources_absolute_ordering_web
jsf_appconfigresources_startupbehavior_web
jsf_appconfigresources_relative_ordering_web
I'm seeing some new tck failures in some tests related to config ordering in
the jsf tests in geronimo. I haven't figured out yet if this is due to a
recent change in myfaces or something in the geronimo integration. I've posted
some details on the geronimo tck list: if anyone with an NDA,
25 matches
Mail list logo
