You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shale.apache.org by "Crabb, Curtis" <CC...@IQNavigator.com> on 2007/10/02 22:57:24 UTC
(Unknown)
As soon as I start using Shale 1.0.4, Ajax4Jsf stops working. I believe
the issue is as follows:
1.) Ajax4Jsf depends upon the javax.faces.ViewRoot being an instance of
AjaxViewRoot.
2.) Shale depends upon the javax.faces.ViewRoot being an instance of
ShaleViewRoot.
I believe I am correct in saying that my application can only use one
implementation of javax.faces.ViewRoot; the one being used in my case is
simply the last jar that is being loaded, which happens to be Shale (I
could also specify my own ViewRoot in my WEB-INF faces-config and then
niether AjaxViewRoot or ShaleViewRoot will be used). That being the
case, is it even possible to use both Ajax4Jsf and Shale in the same
application?
Can anyone shed some light on my confusion? Why does Shale override the
ViewRoot implementation when that immediately stops me from using other
3rd party products that override ViewRoot?
A bit of extra information:
Shale 1.0.3 does not provide it's own implementation of
javax.faces.ViewRoot; that being the case, I can successfully use it
with ajax4jsf.
Also, I can use ajax4jsf with Shale 1.0.4 if I specify in the following
in my own WEB-INF faces-config
<component>
<component-type>javax.faces.ViewRoot</component-type>
<component-class>org.ajax4jsf.framework.ajax.AjaxViewRoot</component-cla
ss>
<component-extension>
<component-family>javax.faces.ViewRoot</component-family>
</component-extension>
</component>
I believe this works simply because my copy of faces-config.xml is the
last configuration loaded, so my override takes precedence.
However, this can break Shale because now Shale sees an instance of
AjaxViewRoot rather than ShaleViewRoot.
So I am stuck with not knowing how to make both products work
simultaneously.
SV: [clay] tld2claycfg and jdk 1.6 problem
Posted by Hermod Opstvedt <he...@opstvedt.com>.
Hi
I'l look into it. This has never been tested by me on JDK6, so there might
be issues.
Hermod
-----Opprinnelig melding-----
Fra: Joost Schouten [mailto:joost@jsportal.com]
Sendt: 16. oktober 2007 09:13
Til: dev@shale.apache.org
Emne: [clay] tld2claycfg and jdk 1.6 problem
Hi,
I've been away for a while working on a Tapestry 5 project (nice framework
btw) and recently picked up my long running jsf/shale project. In the
process of following the changes I used tld2claycfg to build the cfg's for
the latest myfaces components.
When running tld2claycfg with jdk 1.6 I get the following exception:
"Underlying stream encoding 'Cp1252' and input paramter for
writeStartDocument() method 'utf-8' do not match"
This seems to be the exact same problem as
https://issues.apache.org/struts/browse/SHALE-456 with the one difference
that the provided patch didn't seem to work for me. (or does
https://svn.apache.org/repos/asf/shale/maven/trunk/tld2claycfg/ not yet have
the patch commited?)
When running jdk 1.5 all is fine. This looks like a bug to me. Tell me if
I'm wrong otherwise I can report it on jira.
Cheers,
Joost
-----Original Message-----
From: Greg Reddin [mailto:gredbug@gmail.com]
Sent: Saturday, October 06, 2007 10:50 AM
To: dev@shale.apache.org
Subject: Re:
On 10/5/07, Wendy Smoak <ws...@gmail.com> wrote:
>
> Then actually that sounds like we should get a 1.0.5 out with the
> fixes people are waiting for, and then you can commit the potentially
> breaking changes and sort out the Tiles stuff.
That sounds like a good idea.
WDYT? We should really move to dev@ now...
Done :-)
Greg
[clay] tld2claycfg and jdk 1.6 problem
Posted by Joost Schouten <jo...@jsportal.com>.
Hi,
I've been away for a while working on a Tapestry 5 project (nice framework
btw) and recently picked up my long running jsf/shale project. In the
process of following the changes I used tld2claycfg to build the cfg's for
the latest myfaces components.
When running tld2claycfg with jdk 1.6 I get the following exception:
"Underlying stream encoding 'Cp1252' and input paramter for
writeStartDocument() method 'utf-8' do not match"
This seems to be the exact same problem as
https://issues.apache.org/struts/browse/SHALE-456 with the one difference
that the provided patch didn't seem to work for me. (or does
https://svn.apache.org/repos/asf/shale/maven/trunk/tld2claycfg/ not yet have
the patch commited?)
When running jdk 1.5 all is fine. This looks like a bug to me. Tell me if
I'm wrong otherwise I can report it on jira.
Cheers,
Joost
-----Original Message-----
From: Greg Reddin [mailto:gredbug@gmail.com]
Sent: Saturday, October 06, 2007 10:50 AM
To: dev@shale.apache.org
Subject: Re:
On 10/5/07, Wendy Smoak <ws...@gmail.com> wrote:
>
> Then actually that sounds like we should get a 1.0.5 out with the
> fixes people are waiting for, and then you can commit the potentially
> breaking changes and sort out the Tiles stuff.
That sounds like a good idea.
WDYT? We should really move to dev@ now...
Done :-)
Greg
Re:
Posted by Greg Reddin <gr...@gmail.com>.
On 10/5/07, Wendy Smoak <ws...@gmail.com> wrote:
>
> Then actually that sounds like we should get a 1.0.5 out with the
> fixes people are waiting for, and then you can commit the potentially
> breaking changes and sort out the Tiles stuff.
That sounds like a good idea.
WDYT? We should really move to dev@ now...
Done :-)
Greg
Re:
Posted by Wendy Smoak <ws...@gmail.com>.
On 10/5/07, Greg Reddin <gr...@gmail.com> wrote:
> I agree. That move us closer to pushing Shale towards GA :-) I'm still here,
> but I've had *0* time to contribute of late unfortunately. I feel like
> upgrading the Tiles support is about a 5-minute job, but testing it is the
> hard part for me. I've never actually used Tiles 2 with JSF and, in fact,
> Tiles 2 itself has changed so much since I last used it I'm not sure if I'm
> still up to speed on it :-)
>
> At any rate, the biggest help we could use is someone to give testing
> guidance on the Tiles 2 components. I don't want to commit code and walk
> away without giving it some good test support. Someone sent me a .war file a
> while back and I haven't looked at it yet. Maybe it will be a start. If
> anybody else can boil your webapp down to a few tests to put it through its
> paces and attach that to a JIRA, that would be most welcome.
Then actually that sounds like we should get a 1.0.5 out with the
fixes people are waiting for, and then you can commit the potentially
breaking changes and sort out the Tiles stuff.
WDYT? We should really move to dev@ now...
--
Wendy
Re:
Posted by Greg Reddin <gr...@gmail.com>.
On 10/4/07, Wendy Smoak <ws...@gmail.com> wrote:
>
>
> There's not much development going on, but if there's interest in a
> release we can probably round up enough people to make it happen.
>
> I'd like to see the Tiles 2 integration sorted out first, though.
I agree. That move us closer to pushing Shale towards GA :-) I'm still here,
but I've had *0* time to contribute of late unfortunately. I feel like
upgrading the Tiles support is about a 5-minute job, but testing it is the
hard part for me. I've never actually used Tiles 2 with JSF and, in fact,
Tiles 2 itself has changed so much since I last used it I'm not sure if I'm
still up to speed on it :-)
At any rate, the biggest help we could use is someone to give testing
guidance on the Tiles 2 components. I don't want to commit code and walk
away without giving it some good test support. Someone sent me a .war file a
while back and I haven't looked at it yet. Maybe it will be a start. If
anybody else can boil your webapp down to a few tests to put it through its
paces and attach that to a JIRA, that would be most welcome.
Thanks,
Greg
Re:
Posted by Wendy Smoak <ws...@gmail.com>.
On 10/3/07, Lionel Port <li...@portconnection.com> wrote:
> There was a bug in Shale 1.0.4 (
> http://issues.apache.org/struts/browse/SHALE-409) that prevented ajax4jsf
> working with shale. It is fixed in the nightly builds. Just waiting on the
> release of shale 1.0.5, but the project seems to have stalled.
There's not much development going on, but if there's interest in a
release we can probably round up enough people to make it happen.
I'd like to see the Tiles 2 integration sorted out first, though.
--
Wendy
Re:
Posted by Lionel Port <li...@portconnection.com>.
There was a bug in Shale 1.0.4 (
http://issues.apache.org/struts/browse/SHALE-409) that prevented ajax4jsf
working with shale. It is fixed in the nightly builds. Just waiting on the
release of shale 1.0.5, but the project seems to have stalled.
On 10/3/07, Crabb, Curtis <CC...@iqnavigator.com> wrote:
>
> As soon as I start using Shale 1.0.4, Ajax4Jsf stops working. I believe
> the issue is as follows:
>
> 1.) Ajax4Jsf depends upon the javax.faces.ViewRoot being an instance of
> AjaxViewRoot.
> 2.) Shale depends upon the javax.faces.ViewRoot being an instance of
> ShaleViewRoot.
>
> I believe I am correct in saying that my application can only use one
> implementation of javax.faces.ViewRoot; the one being used in my case is
> simply the last jar that is being loaded, which happens to be Shale (I
> could also specify my own ViewRoot in my WEB-INF faces-config and then
> niether AjaxViewRoot or ShaleViewRoot will be used). That being the
> case, is it even possible to use both Ajax4Jsf and Shale in the same
> application?
>
> Can anyone shed some light on my confusion? Why does Shale override the
> ViewRoot implementation when that immediately stops me from using other
> 3rd party products that override ViewRoot?
>
>
>
> A bit of extra information:
>
> Shale 1.0.3 does not provide it's own implementation of
> javax.faces.ViewRoot; that being the case, I can successfully use it
> with ajax4jsf.
>
> Also, I can use ajax4jsf with Shale 1.0.4 if I specify in the following
> in my own WEB-INF faces-config
>
>
>
> <component>
> <component-type>javax.faces.ViewRoot</component-type>
>
> <component-class>org.ajax4jsf.framework.ajax.AjaxViewRoot</component-cla
> ss>
> <component-extension>
> <component-family>javax.faces.ViewRoot</component-family>
> </component-extension>
>
> </component>
>
>
> I believe this works simply because my copy of faces-config.xml is the
> last configuration loaded, so my override takes precedence.
>
> However, this can break Shale because now Shale sees an instance of
> AjaxViewRoot rather than ShaleViewRoot.
>
> So I am stuck with not knowing how to make both products work
> simultaneously.
>
>
>
>
>
>