Re: Tobago Renderer with JSF RI
Hi, generally Tobago can not be combined with any other tags libs freely. You can use f: tags, but not h: tags. The main reason is, that in Tobago every container has a layout-manager which set the position of the component. You may use tc:link instead of h:commandLink. An other effect is, that the tc:link will be rendered with the configured theme automatically. Hope that helps. Udo Pierre Martin schrieb: Hi all, I got this project that runs basically with simple JSF RI components. Now I'm trying to include Tobago components in the project. Since I included all the libs required, it seems taht my RI components are trying to get rendered by my tobago renderer. In glassfish I got this stack : Wrong type: Need org.apache.myfaces.tobago.component.UICommand, but was javax.faces.component.html.HtmlCommandLink I'm very new to tobago. Am I doing something wrong? Here is my tobago-config.xml richmond tobago-resource org/apache/myfaces/tobago/renderkit tanx! -- A man is rich in proportion to the number of things he can afford to let alone. - Thoreau
Re: [Trinidad] forced UTF-8 in PPR responses?
Thanks for the answer. So Trinidad is fine, which is good news, but I have to find another explanation as why it fails on my app. If I'm not mistaking, the browser should make the conversion on-the-fly before putting the new content into the page. But it does dot, and I have  © characters, meaning that those are utf8 chars interpreted as windows-1252. About the reason that I am using win1252 instead of utf-8 : I'd be glad to hear that it's not totally "unavoidable". We're developping a new application that will come as a complement of our older ones. One prerequisite is to re-use some database tables (say, customers, cities/countries, and the likes). The database used is... Oracle 10 XE (yeah, I know, don't get me started), which has no i18n support, and only knows windows-1252. I'm not the Master of Charset Encoding, especially when it comes to databases, but I was told that in this special case, I cannot instruct the Oracle server that I'm a utf8-speaking client, so I have to use the default, which is windows-1252. I'd take ANY solution to this problem, as far as it doesn't break the compatibility with the other apps using the same database. If there's a way to have xmhHttpRequest responses correctly displayed as windows1252, then I'm fine. If I can instead keep utf8 and still use the existing databases as-is, it'll make my day :o) Again, thanks for answering me Regards, Cedric Durmont 2010/2/11 Andrew Robinson : > According to the W3C specification, XML http responses should always > use UTF-8 encoding (requests too actually) > http://www.w3.org/TR/XMLHttpRequest/ > > "Authors are strongly encouraged to encode their resources using UTF-8" > > http://erik.eae.net/archives/2005/05/27/18.55.22/: > "UTF-8 is the standard encoding for XML files, so it MSXML probably > assumes that all files have that encoding if none is set." > > http://www.w3.org/TR/2006/WD-XMLHttpRequest-20060405/ > "responseText of type DOMString > If the readyState attribute has a value other than 3 (Receiving) or 4 > (Loaded), it must be the empty string. Otherwise, it must be the the > body of the data received so far, interpreted using the character > encoding specified in the response, or UTF-8 if no character encoding > was specified. Invalid bytes must be converted to U+FFFD REPLACEMENT > CHARACTER." > "If the method is POST or PUT, then the data passed to the send() > method must be used for the entity body. If data is a string, the data > must be encoded as UTF-8 for transmission. If the data is a Document, > then the document must be serialised using the encoding given by > data.xmlEncoding, if specified, or UTF-8 otherwise [DOM3]. If data is > not a Document or a DOMString the host language must use the > stringification mechanisms on the argument that was passed." > > Basically from what I have seen in the google results, UTF-8 is the > XML standard and browsers are expecting AJAX to use UTF-8 for both > request and responses. It appears that Trinidad is honoring these > guidelines by forcing UTF-8 for XML responses (and other responses, > like file-download) > > My question is why you are using windows-1252 encoding? What is the > "unavoidable reason"? > > -Andrew > > > On Thu, Feb 11, 2010 at 6:07 AM, Cédric Durmont wrote: >> Hi there, >> >> I was wondering : what's the reason why XmlHttpServletResponse forces >> the response to UTF-8, explicitly ignoring the page's encoding ? >> I had a project in utf-8 that ran just fine (even with all accents and >> fancy stuff we have here in France), but I have to switch it to >> windows-1252 for some unavoidable reason. Everything has been >> converted to windows-1252, including the filter I use to force >> encoding in http requests. The only non-working things are PPR calls. >> >> I tracked modifications of http Response objects down to >> XmlHttpServletResponse : >> >> .. >> _contentType = "text/xml;charset=utf-8"; >> .. >> >> So, did I miss something, or PPR actually only works for iso8859-1 / >> utf-8 apps ? >> >> >> Regards, >> Cedric Durmont >> >
Re: [Trinidad] forced UTF-8 in PPR responses?
Hi, we were having the same problem some time ago. We added a filter to our webapp that checks for the type of request and change the encoding properly. This is, you can call CoreRenderKit.isAjaxRequest(externalContext) to check if it is a PPR request and in that case, you can force the encoding to be UTF-8, avoiding the wrong conversion. HTH, -- Rafa On Fri, Feb 12, 2010 at 12:38 PM, Cédric Durmont wrote: > Thanks for the answer. So Trinidad is fine, which is good news, but I > have to find another explanation as why it fails on my app. If I'm not > mistaking, the browser should make the conversion on-the-fly before > putting the new content into the page. But it does dot, and I have  © > characters, meaning that those are utf8 chars interpreted as > windows-1252. > > About the reason that I am using win1252 instead of utf-8 : I'd be > glad to hear that it's not totally "unavoidable". > We're developping a new application that will come as a complement of > our older ones. One prerequisite is to re-use some database tables > (say, customers, cities/countries, and the likes). The database used > is... Oracle 10 XE (yeah, I know, don't get me started), which has no > i18n support, and only knows windows-1252. > > I'm not the Master of Charset Encoding, especially when it comes to > databases, but I was told that in this special case, I cannot instruct > the Oracle server that I'm a utf8-speaking client, so I have to use > the default, which is windows-1252. > > I'd take ANY solution to this problem, as far as it doesn't break the > compatibility with the other apps using the same database. If there's > a way to have xmhHttpRequest responses correctly displayed as > windows1252, then I'm fine. If I can instead keep utf8 and still use > the existing databases as-is, it'll make my day :o) > > Again, thanks for answering me > Regards, > Cedric Durmont > > 2010/2/11 Andrew Robinson : > > According to the W3C specification, XML http responses should always > > use UTF-8 encoding (requests too actually) > > http://www.w3.org/TR/XMLHttpRequest/ > > > > "Authors are strongly encouraged to encode their resources using UTF-8" > > > > http://erik.eae.net/archives/2005/05/27/18.55.22/: > > "UTF-8 is the standard encoding for XML files, so it MSXML probably > > assumes that all files have that encoding if none is set." > > > > http://www.w3.org/TR/2006/WD-XMLHttpRequest-20060405/ > > "responseText of type DOMString > > If the readyState attribute has a value other than 3 (Receiving) or 4 > > (Loaded), it must be the empty string. Otherwise, it must be the the > > body of the data received so far, interpreted using the character > > encoding specified in the response, or UTF-8 if no character encoding > > was specified. Invalid bytes must be converted to U+FFFD REPLACEMENT > > CHARACTER." > > "If the method is POST or PUT, then the data passed to the send() > > method must be used for the entity body. If data is a string, the data > > must be encoded as UTF-8 for transmission. If the data is a Document, > > then the document must be serialised using the encoding given by > > data.xmlEncoding, if specified, or UTF-8 otherwise [DOM3]. If data is > > not a Document or a DOMString the host language must use the > > stringification mechanisms on the argument that was passed." > > > > Basically from what I have seen in the google results, UTF-8 is the > > XML standard and browsers are expecting AJAX to use UTF-8 for both > > request and responses. It appears that Trinidad is honoring these > > guidelines by forcing UTF-8 for XML responses (and other responses, > > like file-download) > > > > My question is why you are using windows-1252 encoding? What is the > > "unavoidable reason"? > > > > -Andrew > > > > > > On Thu, Feb 11, 2010 at 6:07 AM, Cédric Durmont > wrote: > >> Hi there, > >> > >> I was wondering : what's the reason why XmlHttpServletResponse forces > >> the response to UTF-8, explicitly ignoring the page's encoding ? > >> I had a project in utf-8 that ran just fine (even with all accents and > >> fancy stuff we have here in France), but I have to switch it to > >> windows-1252 for some unavoidable reason. Everything has been > >> converted to windows-1252, including the filter I use to force > >> encoding in http requests. The only non-working things are PPR calls. > >> > >> I tracked modifications of http Response objects down to > >> XmlHttpServletResponse : > >> > >> .. > >> _contentType = "text/xml;charset=utf-8"; > >> .. > >> > >> So, did I miss something, or PPR actually only works for iso8859-1 / > >> utf-8 apps ? > >> > >> > >> Regards, > >> Cedric Durmont > >> > > >
Re: [Trinidad] forced UTF-8 in PPR responses?
I recommend trying to set the encoding in the web container's configuration (eg: server.xml). Mike Quentel Senior Geospatial Software Developer 4DM Inc. 671 Danforth Avenue Suite 305 Toronto, Ontario M4J 1L3 Ph/Fax 416 - 410-7569 www.4dm-inc.com Providing solutions through mapping technology -Original Message- From: Cédric Durmont Date: Fri, 12 Feb 2010 12:38:39 To: MyFaces Discussion Subject: Re: [Trinidad] forced UTF-8 in PPR responses? Thanks for the answer. So Trinidad is fine, which is good news, but I have to find another explanation as why it fails on my app. If I'm not mistaking, the browser should make the conversion on-the-fly before putting the new content into the page. But it does dot, and I have  © characters, meaning that those are utf8 chars interpreted as windows-1252. About the reason that I am using win1252 instead of utf-8 : I'd be glad to hear that it's not totally "unavoidable". We're developping a new application that will come as a complement of our older ones. One prerequisite is to re-use some database tables (say, customers, cities/countries, and the likes). The database used is... Oracle 10 XE (yeah, I know, don't get me started), which has no i18n support, and only knows windows-1252. I'm not the Master of Charset Encoding, especially when it comes to databases, but I was told that in this special case, I cannot instruct the Oracle server that I'm a utf8-speaking client, so I have to use the default, which is windows-1252. I'd take ANY solution to this problem, as far as it doesn't break the compatibility with the other apps using the same database. If there's a way to have xmhHttpRequest responses correctly displayed as windows1252, then I'm fine. If I can instead keep utf8 and still use the existing databases as-is, it'll make my day :o) Again, thanks for answering me Regards, Cedric Durmont 2010/2/11 Andrew Robinson : > According to the W3C specification, XML http responses should always > use UTF-8 encoding (requests too actually) > http://www.w3.org/TR/XMLHttpRequest/ > > "Authors are strongly encouraged to encode their resources using UTF-8" > > http://erik.eae.net/archives/2005/05/27/18.55.22/: > "UTF-8 is the standard encoding for XML files, so it MSXML probably > assumes that all files have that encoding if none is set." > > http://www.w3.org/TR/2006/WD-XMLHttpRequest-20060405/ > "responseText of type DOMString > If the readyState attribute has a value other than 3 (Receiving) or 4 > (Loaded), it must be the empty string. Otherwise, it must be the the > body of the data received so far, interpreted using the character > encoding specified in the response, or UTF-8 if no character encoding > was specified. Invalid bytes must be converted to U+FFFD REPLACEMENT > CHARACTER." > "If the method is POST or PUT, then the data passed to the send() > method must be used for the entity body. If data is a string, the data > must be encoded as UTF-8 for transmission. If the data is a Document, > then the document must be serialised using the encoding given by > data.xmlEncoding, if specified, or UTF-8 otherwise [DOM3]. If data is > not a Document or a DOMString the host language must use the > stringification mechanisms on the argument that was passed." > > Basically from what I have seen in the google results, UTF-8 is the > XML standard and browsers are expecting AJAX to use UTF-8 for both > request and responses. It appears that Trinidad is honoring these > guidelines by forcing UTF-8 for XML responses (and other responses, > like file-download) > > My question is why you are using windows-1252 encoding? What is the > "unavoidable reason"? > > -Andrew > > > On Thu, Feb 11, 2010 at 6:07 AM, Cédric Durmont wrote: >> Hi there, >> >> I was wondering : what's the reason why XmlHttpServletResponse forces >> the response to UTF-8, explicitly ignoring the page's encoding ? >> I had a project in utf-8 that ran just fine (even with all accents and >> fancy stuff we have here in France), but I have to switch it to >> windows-1252 for some unavoidable reason. Everything has been >> converted to windows-1252, including the filter I use to force >> encoding in http requests. The only non-working things are PPR calls. >> >> I tracked modifications of http Response objects down to >> XmlHttpServletResponse : >> >> .. >> _contentType = "text/xml;charset=utf-8"; >> .. >> >> So, did I miss something, or PPR actually only works for iso8859-1 / >> utf-8 apps ? >> >> >> Regards, >> Cedric Durmont >> >
[Trinidad] Regarding PartialTriggers attribute
Hi For our Application we wanted to raise partialTriggers based on three components. Accidentally till now we were using commas to separate them and it worked fine. We use : Trinidad1.2.12 jsf-facelets1.1.14 JBoss 4.2.1 Now when we tried to run this in other environment (other than JBoss), it gives error saying java.lang.IllegalArgumentException: Cannot convert selectedReaction of type class java.lang.String to class [Ljava.lang.String; When we searched in Trinidad Doc it recommends to use spaces instead of commas. Then we found in http://issues.apache.org/jira/browse/TRINIDAD-1417 that we need to use EL expressions as even spaces don't work. Now some FAQs regarding this: 1) Why commas were working in JBoss environment since it's not supported as per the document? Does any jar allowed it? 2) If it was working in JBoss then why it failed in the new environment? 3) Is there any fix regarding spaces issue? Thanks and Regards, Preeti Agarwal
Re: [Trinidad] forced UTF-8 in PPR responses?
Thanks for the tip, Rafa, now it works like a charm :o)
Could not find how to get an ExternalContext from inside a filter,
however. So my test is :
if ("true".equals(((HttpServletRequest)(request)).getHeader("Tr-XHR-Message")) )
... because it's basically what isAjaxRequest and ExternalContext actually do.
Thanks everyone for your help :o)
Regards,
Cedric Durmont
2010/2/12 Mike Quentel (4DM) :
> I recommend trying to set the encoding in the web container's configuration
> (eg: server.xml).
>
>
> Mike Quentel
> Senior Geospatial Software Developer
> 4DM Inc.
> 671 Danforth Avenue Suite 305
> Toronto, Ontario
> M4J 1L3
> Ph/Fax 416 - 410-7569
> www.4dm-inc.com
> Providing solutions through mapping technology
>
> -Original Message-
> From: Cédric Durmont
> Date: Fri, 12 Feb 2010 12:38:39
> To: MyFaces Discussion
> Subject: Re: [Trinidad] forced UTF-8 in PPR responses?
>
> Thanks for the answer. So Trinidad is fine, which is good news, but I
> have to find another explanation as why it fails on my app. If I'm not
> mistaking, the browser should make the conversion on-the-fly before
> putting the new content into the page. But it does dot, and I have  ©
> characters, meaning that those are utf8 chars interpreted as
> windows-1252.
>
> About the reason that I am using win1252 instead of utf-8 : I'd be
> glad to hear that it's not totally "unavoidable".
> We're developping a new application that will come as a complement of
> our older ones. One prerequisite is to re-use some database tables
> (say, customers, cities/countries, and the likes). The database used
> is... Oracle 10 XE (yeah, I know, don't get me started), which has no
> i18n support, and only knows windows-1252.
>
> I'm not the Master of Charset Encoding, especially when it comes to
> databases, but I was told that in this special case, I cannot instruct
> the Oracle server that I'm a utf8-speaking client, so I have to use
> the default, which is windows-1252.
>
> I'd take ANY solution to this problem, as far as it doesn't break the
> compatibility with the other apps using the same database. If there's
> a way to have xmhHttpRequest responses correctly displayed as
> windows1252, then I'm fine. If I can instead keep utf8 and still use
> the existing databases as-is, it'll make my day :o)
>
> Again, thanks for answering me
> Regards,
> Cedric Durmont
>
> 2010/2/11 Andrew Robinson :
>> According to the W3C specification, XML http responses should always
>> use UTF-8 encoding (requests too actually)
>> http://www.w3.org/TR/XMLHttpRequest/
>>
>> "Authors are strongly encouraged to encode their resources using UTF-8"
>>
>> http://erik.eae.net/archives/2005/05/27/18.55.22/:
>> "UTF-8 is the standard encoding for XML files, so it MSXML probably
>> assumes that all files have that encoding if none is set."
>>
>> http://www.w3.org/TR/2006/WD-XMLHttpRequest-20060405/
>> "responseText of type DOMString
>> If the readyState attribute has a value other than 3 (Receiving) or 4
>> (Loaded), it must be the empty string. Otherwise, it must be the the
>> body of the data received so far, interpreted using the character
>> encoding specified in the response, or UTF-8 if no character encoding
>> was specified. Invalid bytes must be converted to U+FFFD REPLACEMENT
>> CHARACTER."
>> "If the method is POST or PUT, then the data passed to the send()
>> method must be used for the entity body. If data is a string, the data
>> must be encoded as UTF-8 for transmission. If the data is a Document,
>> then the document must be serialised using the encoding given by
>> data.xmlEncoding, if specified, or UTF-8 otherwise [DOM3]. If data is
>> not a Document or a DOMString the host language must use the
>> stringification mechanisms on the argument that was passed."
>>
>> Basically from what I have seen in the google results, UTF-8 is the
>> XML standard and browsers are expecting AJAX to use UTF-8 for both
>> request and responses. It appears that Trinidad is honoring these
>> guidelines by forcing UTF-8 for XML responses (and other responses,
>> like file-download)
>>
>> My question is why you are using windows-1252 encoding? What is the
>> "unavoidable reason"?
>>
>> -Andrew
>>
>>
>> On Thu, Feb 11, 2010 at 6:07 AM, Cédric Durmont wrote:
>>> Hi there,
>>>
>>> I was wondering : what's the reason why XmlHttpServletResponse forces
>>> the response to UTF-8, explicitly ignoring the page's encoding ?
>>> I had a project in utf-8 that ran just fine (even with all accents and
>>> fancy stuff we have here in France), but I have to switch it to
>>> windows-1252 for some unavoidable reason. Everything has been
>>> converted to windows-1252, including the filter I use to force
>>> encoding in http requests. The only non-working things are PPR calls.
>>>
>>> I tracked modifications of http Response objects down to
>>> XmlHttpServletResponse :
>>>
>>> ..
>>> _contentType = "text/xml;charset=utf-8";
>>> ..
>>>
>>> So, did I miss something, or PPR actually only works for
RE: dramatic performance decrease after update to JSF 1.2
I have some news regarding the performance problem. The major performance decrease was caused by a Tomcat Bug. See https://issues.apache.org/bugzilla/show_bug.cgi?id=48600 Setting metadata-complete="true" in web.xml improved the 1.2 speed significantly! There seems to be still another problem in Tocmat: Average results of 500 calls of a simple page (jsp) with 1000 h:output tags: JSF 1.1 Tomcat: 26ms JSF 1.1 Jetty: 35ms JSF 1.2 Tomcat: 72ms JSF 1.2 Jetty: 41ms Is anybody here aware of other Tomcat bugs or settings that could explain the above numbers? I'll also ask on the tomcat list. Michael -Original Message- From: Michael Heinen [mailto:michael.hei...@recommind.com] Sent: Freitag, 29. Januar 2010 09:36 To: MyFaces Discussion Subject: RE: dramatic performance decrease after update to JSF 1.2 I am really astonished that nobody else out in the world faced or addressed this problem so far. JSF 1.2 seems to be much slower than JSF 1.1 (with jsps, don't know about facelets). It can be reproduced easily with a simple JSF app without tiles, richfaces and all this stuff. Just create a simple page with a few hundred output tags without any EL: e.g. . It is nearly two times slower and the time is lost during phase render response. Same effect occurs with Mojarra, which seems to be faster than Myfaces (at least for this simple case). This effect is of course worse in case of heavy load on the app. A version upgrade should not result in such a performance loss, we are not talking about a few percent. Does anybody have an explanation for this? Is it caused by separating tree creation from rendering? Is the component tree now walked completely two times, for creation and rendering? Michael -Original Message- From: Michael Heinen [mailto:michael.hei...@recommind.com] Sent: Freitag, 15. Januar 2010 11:07 To: MyFaces Discussion Subject: dramatic performance decrease after update to JSF 1.2 Hi, I have updated my application to JSF 1.2 during the last weeks. Now I did some performance tests and the result has been alarming! Performance declined by factor 2-4 depending on hardware and actions!!! Measurements: I used two different contexts on same Tomcat means identical tomcat config and JDK. I started only one of the contexts for each tests run. Backend is also the same. JMeter was used to fire requests but the difference can be seen by manual clicks immediately. Obvious results: Time is lost in phase render response. Sample numbers for a single request on a slow notebook in phase render response (with debug logging): JSF1.1: 1594ms JSF1.1: 4766ms (The numbers are much better without debug logging of course but the factor is still the same) Environment: Tomcat 6.0.20 JDK 1.6.0.18 Updated Libs: myFaces: 1.1.5 to 1.2.8 tomahawk: 1.1.7 to 12-1.1.9 richfaces: 3.1.5 to 3.3.3Beta1 tiles: 1(struts) to 2.0.5 jstl: 1.1.0 to 1.2 commons-digester: 1.7 to 1.8 oro-2.0.8 to jakarta-oro.jar Settings: identical in 1.1 and 1.2: javax.faces.STATE_SAVING_METHOD=server org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION = 1 org.apache.myfaces.SERIALIZE_STATE_IN_SESSION = false org.apache.myfaces.COMPRESS_STATE_IN_SESSION=false 1.2 new: org.apache.myfaces.SECRET added org.apache.myfaces.USE_ENCRYPTION = false org.apache.myfaces.CACHE_OLD_VIEWS_IN_SESSION_MODE=off (I patched this in 1.1 and removed the old references) Questions before I start profiling and probably sink time: 1) Is this typical or expected? 2) Is any new configuration flag added to 1.2 which could have high impact on performance? 3) Any other hints where to look at? Michael
[Trinidad] Help with autoSubmit
Hi
I've been working with JSF & IceFaces, but rather new to MyFaces + Trinidad.
And I'm facing a problem with autoSubmit.
Basically, I have two selectOneChoice elements (project and subproject), and
the second should be disabled until the first one has been selected. In the
same form, I also have a few other fields that are marked as required and need
some further validation.
The problem I have is the following: when I select an item in the first
selectOneChoice, the second becomes enabled. So far so good... So I fill in the
other fields and click the 'add' button. The problem is that the selected value
in the second selectOneChoice (#{entryBean.currentLine.subProjectId}) does not
get pushed to the backing bean, while the two others are. I can see that when
the addAction method is fired; only projectId and activityId return the right
value, subprojectid is always 0.
The first selectOneChoice is marked as immediate to bypass the validation
controls. I have also attached a valueChangeListener (projectChangeListener) to
it so that the value gets stored in the backing bean (btw, why isn't that done
automatically?)
Am I doing something wrong or is this a know issue? I don't think my case is
really unusual...
Thanks a lot for your help
Jean-Noël Colin
public String addAction() {
System.out.println("Add action called");
System.out.println(currentLine.getProjectId());
System.out.println(currentLine.getSubProjectId());
System.out.println(currentLine.getActivityId());
return null;
}
public void projectChangeListener(ValueChangeEvent event) {
System.out.println("new project: " + event.getOldValue() + ":"
+ event.getNewValue());
System.out.println(currentLine.getSubProjectId());
currentLine.setProjectId((Long) event.getNewValue());
Re: [Trinidad] Regarding PartialTriggers attribute
You cannot mix strings an EL in partialTriggers, the JSP tag will not
allow it (I know, not cool). You have to either use a space-separated
string or EL that points to a string array. There are no other
options. I would suggest filing a JIRA ticket to fix this and then use
an EL function to convert the strings to an array yourself.
-Andrew
On Fri, Feb 12, 2010 at 6:54 AM, preeti agarwal
wrote:
> Hi
> For our Application we wanted to raise partialTriggers based on
> three components. Accidentally till now we were using commas to separate
> them and it worked fine.
>
> partialTriggers="link#{count},h_anchors#{count},expandAll">
>
> We use :
> Trinidad 1.2.12
> jsf-facelets 1.1.14
> JBoss 4.2.1
>
>
>
> Now when we tried to run this in other environment (other than JBoss),
> it gives error saying
>
> java.lang.IllegalArgumentException: Cannot convert selectedReaction of
> type class java.lang.String to class [Ljava.lang.String;
>
>
> When we searched in Trinidad Doc it recommends to use spaces instead of
> commas. Then we found in
> http://issues.apache.org/jira/browse/TRINIDAD-1417 that we need to use
> EL expressions as even spaces don't work.
>
> Now some FAQs regarding this:
>
> 1) Why commas were working in JBoss environment since it's not
> supported as per the document? Does any jar allowed it?
>
> 2) If it was working in JBoss then why it failed in the new
> environment?
>
> 3) Is there any fix regarding spaces issue?
>
>
>
>
> Thanks and Regards,
>
> Preeti Agarwal
>
Re: [Trinidad] forced UTF-8 in PPR responses?
Good! :D
On Fri, Feb 12, 2010 at 4:57 PM, Cédric Durmont wrote:
> Thanks for the tip, Rafa, now it works like a charm :o)
> Could not find how to get an ExternalContext from inside a filter,
> however. So my test is :
> if
> ("true".equals(((HttpServletRequest)(request)).getHeader("Tr-XHR-Message"))
> )
>
> ... because it's basically what isAjaxRequest and ExternalContext actually
> do.
>
> Thanks everyone for your help :o)
> Regards,
> Cedric Durmont
>
>
> 2010/2/12 Mike Quentel (4DM) :
> > I recommend trying to set the encoding in the web container's
> configuration (eg: server.xml).
> >
> >
> > Mike Quentel
> > Senior Geospatial Software Developer
> > 4DM Inc.
> > 671 Danforth Avenue Suite 305
> > Toronto, Ontario
> > M4J 1L3
> > Ph/Fax 416 - 410-7569
> > www.4dm-inc.com
> > Providing solutions through mapping technology
> >
> > -Original Message-
> > From: Cédric Durmont
> > Date: Fri, 12 Feb 2010 12:38:39
> > To: MyFaces Discussion
> > Subject: Re: [Trinidad] forced UTF-8 in PPR responses?
> >
> > Thanks for the answer. So Trinidad is fine, which is good news, but I
> > have to find another explanation as why it fails on my app. If I'm not
> > mistaking, the browser should make the conversion on-the-fly before
> > putting the new content into the page. But it does dot, and I have  ©
> > characters, meaning that those are utf8 chars interpreted as
> > windows-1252.
> >
> > About the reason that I am using win1252 instead of utf-8 : I'd be
> > glad to hear that it's not totally "unavoidable".
> > We're developping a new application that will come as a complement of
> > our older ones. One prerequisite is to re-use some database tables
> > (say, customers, cities/countries, and the likes). The database used
> > is... Oracle 10 XE (yeah, I know, don't get me started), which has no
> > i18n support, and only knows windows-1252.
> >
> > I'm not the Master of Charset Encoding, especially when it comes to
> > databases, but I was told that in this special case, I cannot instruct
> > the Oracle server that I'm a utf8-speaking client, so I have to use
> > the default, which is windows-1252.
> >
> > I'd take ANY solution to this problem, as far as it doesn't break the
> > compatibility with the other apps using the same database. If there's
> > a way to have xmhHttpRequest responses correctly displayed as
> > windows1252, then I'm fine. If I can instead keep utf8 and still use
> > the existing databases as-is, it'll make my day :o)
> >
> > Again, thanks for answering me
> > Regards,
> > Cedric Durmont
> >
> > 2010/2/11 Andrew Robinson :
> >> According to the W3C specification, XML http responses should always
> >> use UTF-8 encoding (requests too actually)
> >> http://www.w3.org/TR/XMLHttpRequest/
> >>
> >> "Authors are strongly encouraged to encode their resources using UTF-8"
> >>
> >> http://erik.eae.net/archives/2005/05/27/18.55.22/:
> >> "UTF-8 is the standard encoding for XML files, so it MSXML probably
> >> assumes that all files have that encoding if none is set."
> >>
> >> http://www.w3.org/TR/2006/WD-XMLHttpRequest-20060405/
> >> "responseText of type DOMString
> >> If the readyState attribute has a value other than 3 (Receiving) or 4
> >> (Loaded), it must be the empty string. Otherwise, it must be the the
> >> body of the data received so far, interpreted using the character
> >> encoding specified in the response, or UTF-8 if no character encoding
> >> was specified. Invalid bytes must be converted to U+FFFD REPLACEMENT
> >> CHARACTER."
> >> "If the method is POST or PUT, then the data passed to the send()
> >> method must be used for the entity body. If data is a string, the data
> >> must be encoded as UTF-8 for transmission. If the data is a Document,
> >> then the document must be serialised using the encoding given by
> >> data.xmlEncoding, if specified, or UTF-8 otherwise [DOM3]. If data is
> >> not a Document or a DOMString the host language must use the
> >> stringification mechanisms on the argument that was passed."
> >>
> >> Basically from what I have seen in the google results, UTF-8 is the
> >> XML standard and browsers are expecting AJAX to use UTF-8 for both
> >> request and responses. It appears that Trinidad is honoring these
> >> guidelines by forcing UTF-8 for XML responses (and other responses,
> >> like file-download)
> >>
> >> My question is why you are using windows-1252 encoding? What is the
> >> "unavoidable reason"?
> >>
> >> -Andrew
> >>
> >>
> >> On Thu, Feb 11, 2010 at 6:07 AM, Cédric Durmont
> wrote:
> >>> Hi there,
> >>>
> >>> I was wondering : what's the reason why XmlHttpServletResponse forces
> >>> the response to UTF-8, explicitly ignoring the page's encoding ?
> >>> I had a project in utf-8 that ran just fine (even with all accents and
> >>> fancy stuff we have here in France), but I have to switch it to
> >>> windows-1252 for some unavoidable reason. Everything has been
> >>> converted to windows-1252, including the filter I use to force
> >>> e
