Re: Encoding post data on Tomcat 7 using 2.0.3 corrupted
already done. it is a know issue. I just posted the solution here in case
anybody else runs into the same issue.
On 27/08/2013, at 1:06 PM, Niki Dokovski wrote:
> On Tue, Aug 27, 2013 at 6:22 AM, Alexander Hartner wrote:
>
>> The problem was resolved by including both filters
>> (org.jboss.weld.servlet.ConversationFilter and
>> org.apache.catalina.filters.SetCharacterEncodingFilter).
>>
>
> Should this be reported to jboss weld? It could be documented or even code
> inspected if needed.
>
> cheers
> Niki
>
>
>
>>
>>
>>
>>
>> http://java.sun.com/xml/ns/javaee";
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
>> http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd";
>> version="3.0">
>>
>>
>>SetCharacterEncoding
>>
>> org.apache.catalina.filters.SetCharacterEncodingFilter
>>
>> encoding
>> UTF-8
>>
>>
>> ignore
>> false
>>
>>
>>
>>Conversation
>>org.jboss.weld.servlet.ConversationFilter
>>
>>SetCharacterEncoding
>>/*
>>
>>
>>Conversation
>>/*
>>
>>
>>
>> org.jboss.weld.environment.servlet.Listener
>>
>>
>>
>> 30
>>
>>
>>
>>
>>
>>
>> On 27/08/2013, at 12:14 AM, Konstantin Kolinko
>> wrote:
>>
>>> 2013/8/26 Alexander Hartner :
This may be more of an application problem than a tomcat issue, but I am
rather stuck with this one and hoping that somebody on this list may be
able to shed some light on my issue.
I am trying to post UTF-8 encoding text to my JSF2.2 application,
however the data received does not seem to be encoded correctly.I
narrowed this problem down to the weld listener. To illustrate the issue
I modified the test page from the tomcat faq:
1. <%@ page contentType="text/html; charset=UTF-8"
>> pageEncoding="UTF-8"%>
2.
3.
4.
5. Character encoding test page
6.
7.
8.
9. Encoding : <%=request.getCharacterEncoding()%>
10.
11. Data posted to this form was:
12. <%
13. request.setCharacterEncoding("UTF-8");
14. out.print(request.getParameter("mydata"));
15. %>
16.
17.
18.
19.
20.
21.
22.
23.
24.
25. .g. ç,g(,ö,s,,?, etc Soße " Test data "
26.
27.
So I have a simple web application which only consist of this page, and
the weld library in WEB-INF/lib (weld-servlet-2.0.3.Final.jar).
So far so good. However as soon as I include the weld listener in my
web.xml file
1.
2.
3. http://java.sun.com/xml/ns/javaee";
4. xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
5. xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
>> http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd";
6. version="3.0">
7.
8.
>> org.jboss.weld.environment.servlet.Listener
9.
10.
11.
12. 30
13.
14.
15.
The post parameters are corrupted by the listener.
I did enable URIEncoding="UTF-8" in the server.xml file, but this did
not make any difference.
1. >>> 2.port="8080" protocol="HTTP/1.1"
3.connectionTimeout="2"
4.redirectPort="8443"
5.URIEncoding="UTF-8"/>
With the listener enabled data like "Soße" is received as "SoÃY"e",
however once the listerner is removed everything works as expected.
>>>
>>> 1. I hope you have seen the FAQ.
>>> http://wiki.apache.org/tomcat/FAQ/CharacterEncoding
>>>
>>> and
>>>
>> http://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#Set_Character_Encoding_Filter
>>>
>>> 2. Try to run with a debugger
>>> http://wiki.apache.org/tomcat/FAQ/Developing#Debugging
>>>
>>> with a breakpoint in
>> org.apache.catalina.connector.Request#parseParameters()
>>>
>>> I guess that there is some component that calls one of getParameter()
>>> methods before your request.setCharacterEncoding("UTF-8") and thus the
>>> default of ISO-8859-1 is effective.
>>>
>>> 3. What exact version of Tomcat 7.0.x are you using?
>>>
>>> Best regards,
>>> Konstantin Kolinko
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>
>>
>>
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Encoding post data on Tomcat 7 using 2.0.3 corrupted
On Tue, Aug 27, 2013 at 6:22 AM, Alexander Hartner wrote:
> The problem was resolved by including both filters
> (org.jboss.weld.servlet.ConversationFilter and
> org.apache.catalina.filters.SetCharacterEncodingFilter).
>
Should this be reported to jboss weld? It could be documented or even code
inspected if needed.
cheers
Niki
>
>
>
>
> http://java.sun.com/xml/ns/javaee";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
> http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd";
> version="3.0">
>
>
> SetCharacterEncoding
>
> org.apache.catalina.filters.SetCharacterEncodingFilter
>
> encoding
> UTF-8
>
>
> ignore
> false
>
>
>
> Conversation
> org.jboss.weld.servlet.ConversationFilter
>
> SetCharacterEncoding
> /*
>
>
> Conversation
> /*
>
>
>
> org.jboss.weld.environment.servlet.Listener
>
>
>
> 30
>
>
>
>
>
>
> On 27/08/2013, at 12:14 AM, Konstantin Kolinko
> wrote:
>
> > 2013/8/26 Alexander Hartner :
> >> This may be more of an application problem than a tomcat issue, but I am
> >> rather stuck with this one and hoping that somebody on this list may be
> >> able to shed some light on my issue.
> >>
> >> I am trying to post UTF-8 encoding text to my JSF2.2 application,
> >> however the data received does not seem to be encoded correctly.I
> >> narrowed this problem down to the weld listener. To illustrate the issue
> >> I modified the test page from the tomcat faq:
> >>
> >>
> >>
> >> 1. <%@ page contentType="text/html; charset=UTF-8"
> pageEncoding="UTF-8"%>
> >> 2.
> >> 3.
> >> 4.
> >> 5. Character encoding test page
> >> 6.
> >> 7.
> >> 8.
> >> 9. Encoding : <%=request.getCharacterEncoding()%>
> >> 10.
> >> 11. Data posted to this form was:
> >> 12. <%
> >> 13. request.setCharacterEncoding("UTF-8");
> >> 14. out.print(request.getParameter("mydata"));
> >> 15. %>
> >> 16.
> >> 17.
> >> 18.
> >> 19.
> >> 20.
> >> 21.
> >> 22.
> >> 23.
> >> 24.
> >> 25. .g. ç,g(,ö,s,,?, etc Soße " Test data "
> >> 26.
> >> 27.
> >>
> >>
> >>
> >> So I have a simple web application which only consist of this page, and
> >> the weld library in WEB-INF/lib (weld-servlet-2.0.3.Final.jar).
> >>
> >> So far so good. However as soon as I include the weld listener in my
> >> web.xml file
> >>
> >>
> >>
> >> 1.
> >> 2.
> >> 3. http://java.sun.com/xml/ns/javaee";
> >> 4. xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> >> 5. xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
> http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd";
> >> 6. version="3.0">
> >> 7.
> >> 8.
> org.jboss.weld.environment.servlet.Listener
> >> 9.
> >> 10.
> >> 11.
> >> 12. 30
> >> 13.
> >> 14.
> >> 15.
> >>
> >>
> >>
> >> The post parameters are corrupted by the listener.
> >>
> >>
> >>
> >> I did enable URIEncoding="UTF-8" in the server.xml file, but this did
> >> not make any difference.
> >>
> >> 1. >> 2.port="8080" protocol="HTTP/1.1"
> >> 3.connectionTimeout="2"
> >> 4.redirectPort="8443"
> >> 5.URIEncoding="UTF-8"/>
> >>
> >>
> >>
> >> With the listener enabled data like "Soße" is received as "SoÃY"e",
> >> however once the listerner is removed everything works as expected.
> >>
> >
> > 1. I hope you have seen the FAQ.
> > http://wiki.apache.org/tomcat/FAQ/CharacterEncoding
> >
> > and
> >
> http://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#Set_Character_Encoding_Filter
> >
> > 2. Try to run with a debugger
> > http://wiki.apache.org/tomcat/FAQ/Developing#Debugging
> >
> > with a breakpoint in
> org.apache.catalina.connector.Request#parseParameters()
> >
> > I guess that there is some component that calls one of getParameter()
> > methods before your request.setCharacterEncoding("UTF-8") and thus the
> > default of ISO-8859-1 is effective.
> >
> > 3. What exact version of Tomcat 7.0.x are you using?
> >
> > Best regards,
> > Konstantin Kolinko
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
>
>
Re: Encoding post data on Tomcat 7 using 2.0.3 corrupted
The problem was resolved by including both filters
(org.jboss.weld.servlet.ConversationFilter and
org.apache.catalina.filters.SetCharacterEncodingFilter).
http://java.sun.com/xml/ns/javaee";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd";
version="3.0">
SetCharacterEncoding
org.apache.catalina.filters.SetCharacterEncodingFilter
encoding
UTF-8
ignore
false
Conversation
org.jboss.weld.servlet.ConversationFilter
SetCharacterEncoding
/*
Conversation
/*
org.jboss.weld.environment.servlet.Listener
30
On 27/08/2013, at 12:14 AM, Konstantin Kolinko wrote:
> 2013/8/26 Alexander Hartner :
>> This may be more of an application problem than a tomcat issue, but I am
>> rather stuck with this one and hoping that somebody on this list may be
>> able to shed some light on my issue.
>>
>> I am trying to post UTF-8 encoding text to my JSF2.2 application,
>> however the data received does not seem to be encoded correctly.I
>> narrowed this problem down to the weld listener. To illustrate the issue
>> I modified the test page from the tomcat faq:
>>
>>
>>
>> 1. <%@ page contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
>> 2.
>> 3.
>> 4.
>> 5. Character encoding test page
>> 6.
>> 7.
>> 8.
>> 9. Encoding : <%=request.getCharacterEncoding()%>
>> 10.
>> 11. Data posted to this form was:
>> 12. <%
>> 13. request.setCharacterEncoding("UTF-8");
>> 14. out.print(request.getParameter("mydata"));
>> 15. %>
>> 16.
>> 17.
>> 18.
>> 19.
>> 20.
>> 21.
>> 22.
>> 23.
>> 24.
>> 25. .g. ç,g(,ö,s,,?, etc Soße " Test data "
>> 26.
>> 27.
>>
>>
>>
>> So I have a simple web application which only consist of this page, and
>> the weld library in WEB-INF/lib (weld-servlet-2.0.3.Final.jar).
>>
>> So far so good. However as soon as I include the weld listener in my
>> web.xml file
>>
>>
>>
>> 1.
>> 2.
>> 3. http://java.sun.com/xml/ns/javaee";
>> 4. xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>> 5. xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
>> http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd";
>> 6. version="3.0">
>> 7.
>> 8.
>> org.jboss.weld.environment.servlet.Listener
>> 9.
>> 10.
>> 11.
>> 12. 30
>> 13.
>> 14.
>> 15.
>>
>>
>>
>> The post parameters are corrupted by the listener.
>>
>>
>>
>> I did enable URIEncoding="UTF-8" in the server.xml file, but this did
>> not make any difference.
>>
>> 1. > 2.port="8080" protocol="HTTP/1.1"
>> 3.connectionTimeout="2"
>> 4.redirectPort="8443"
>> 5.URIEncoding="UTF-8"/>
>>
>>
>>
>> With the listener enabled data like "Soße" is received as "SoÃY"e",
>> however once the listerner is removed everything works as expected.
>>
>
> 1. I hope you have seen the FAQ.
> http://wiki.apache.org/tomcat/FAQ/CharacterEncoding
>
> and
> http://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#Set_Character_Encoding_Filter
>
> 2. Try to run with a debugger
> http://wiki.apache.org/tomcat/FAQ/Developing#Debugging
>
> with a breakpoint in org.apache.catalina.connector.Request#parseParameters()
>
> I guess that there is some component that calls one of getParameter()
> methods before your request.setCharacterEncoding("UTF-8") and thus the
> default of ISO-8859-1 is effective.
>
> 3. What exact version of Tomcat 7.0.x are you using?
>
> Best regards,
> Konstantin Kolinko
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
Re: buffer expand warning in Tomcat (apache-tomcat-8.0.0-RC1-embed)
hi all, thought I would add some progress on this topic. I have changed my method for reading from the HttpServletRequest object but the same warning message is thrown for every 8192 bytes read. I no longer regard my code to be suspect though am happy to be corrected. The application operates completely normally except for the warning message. The code I am using to read the input is shown below. public void doPost(HttpServletRequest httpServletRequest.etc ...other code.. char[] cbuf=new char[8192]; int i=0; int requestLength=httpServletRequest.getContentLength(); BufferedReader in=httpServletRequest.getReader(); StringBuilder sb=new StringBuilder(requestLength); while(sb.length()http://tomcat.10.x6.nabble.com/buffer-expand-warning-in-Tomcat-apache-tomcat-8-0-0-RC1-embed-tp5003745p5003777.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Logging for session-replication debugging
Thank you, works perfectly.
On Mon, Aug 26, 2013 at 4:25 PM, Mark Eggers wrote:
> On 8/26/2013 12:29 PM, Tomcat Random wrote:
>
>> What exactly should go in logging.properties to get the most information
>> about clustering/session replication?
>>
>> I see two different logging suggestions, one in the docs and one in the
>> FAQ. Tried both but couldn't get anymore information that what's there
>> already coming out in the logs: No warnings, lots of INFO that seems like
>> things are OK.
>>
>> Tomcat_7_42. My environment is two physical servers, RHEL6, each with an
>> instance of Tomcat.
>>
>> Thanks in advance
>> Alec
>>
>>
> It's been a while since I've played with this, so your mileage may vary.
>
> # wrapped for easier reading
> # added one additional handler
>
> handlers = 1catalina.org.apache.juli.**FileHandler,
>2localhost.org.apache.juli.**FileHandler,
>3manager.org.apache.juli.**FileHandler,
>4host-manager.or.apache.juli.**FileHandler,
> java.util.logging.**ConsoleHandler,
>5cluster.org.apache.juli.**FileHandler
>
> # just the new cluster log handler - all others are stock
> # logging.properties
> # beware of the wrapping
>
> 5cluster.org.apache.juli.**FileHandler.level = FINER
> 5cluster.org.apache.juli.**FileHandler.directory = ${catalina.base}/logs
> 5cluster.org.apache.juli.**FileHandler.prefix = cluster.
>
> # just the clustering logs - all others are stock logging.properties
> org.apache.catalina.tribes.**MESSAGES.level = FINE
> org.apache.catalina.tribes.**MESSAGES.handlers =
> 5cluster.org.apache.juli.**FileHandler
>
> org.apache.catalina.tribes.**level = FINE
> org.apache.catalina.tribes.**handlers =
> 5cluster.org.apache.juli.**FileHandler
>
> org.apache.catalina.ha.level = FINE
> org.apache.catalina.ha.**handlers = 5cluster.org.apache.juli.**FileHander
>
> org.apache.catalina.ha.deploy.**level = INFO
> org.apache.catalina.ha.deploy.**handlers =
> 5cluster.org.apache.juli.**FileHandler
>
> Set logging at the desired level.
>
> I think I've posted this to the mailing list before . . .
>
> /mde/
>
> --**--**-
> To unsubscribe, e-mail:
> users-unsubscribe@tomcat.**apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
Re: Logging for session-replication debugging
On 8/26/2013 12:29 PM, Tomcat Random wrote:
What exactly should go in logging.properties to get the most information
about clustering/session replication?
I see two different logging suggestions, one in the docs and one in the
FAQ. Tried both but couldn't get anymore information that what's there
already coming out in the logs: No warnings, lots of INFO that seems like
things are OK.
Tomcat_7_42. My environment is two physical servers, RHEL6, each with an
instance of Tomcat.
Thanks in advance
Alec
It's been a while since I've played with this, so your mileage may vary.
# wrapped for easier reading
# added one additional handler
handlers = 1catalina.org.apache.juli.FileHandler,
2localhost.org.apache.juli.FileHandler,
3manager.org.apache.juli.FileHandler,
4host-manager.or.apache.juli.FileHandler,
java.util.logging.ConsoleHandler,
5cluster.org.apache.juli.FileHandler
# just the new cluster log handler - all others are stock
# logging.properties
# beware of the wrapping
5cluster.org.apache.juli.FileHandler.level = FINER
5cluster.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
5cluster.org.apache.juli.FileHandler.prefix = cluster.
# just the clustering logs - all others are stock logging.properties
org.apache.catalina.tribes.MESSAGES.level = FINE
org.apache.catalina.tribes.MESSAGES.handlers =
5cluster.org.apache.juli.FileHandler
org.apache.catalina.tribes.level = FINE
org.apache.catalina.tribes.handlers =
5cluster.org.apache.juli.FileHandler
org.apache.catalina.ha.level = FINE
org.apache.catalina.ha.handlers = 5cluster.org.apache.juli.FileHander
org.apache.catalina.ha.deploy.level = INFO
org.apache.catalina.ha.deploy.handlers =
5cluster.org.apache.juli.FileHandler
Set logging at the desired level.
I think I've posted this to the mailing list before . . .
/mde/
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Logging for session-replication debugging
What exactly should go in logging.properties to get the most information about clustering/session replication? I see two different logging suggestions, one in the docs and one in the FAQ. Tried both but couldn't get anymore information that what's there already coming out in the logs: No warnings, lots of INFO that seems like things are OK. Tomcat_7_42. My environment is two physical servers, RHEL6, each with an instance of Tomcat. Thanks in advance Alec
Re: Encoding post data on Tomcat 7 using 2.0.3 corrupted
2013/8/26 Alexander Hartner :
> This may be more of an application problem than a tomcat issue, but I am
> rather stuck with this one and hoping that somebody on this list may be
> able to shed some light on my issue.
>
> I am trying to post UTF-8 encoding text to my JSF2.2 application,
> however the data received does not seem to be encoded correctly.I
> narrowed this problem down to the weld listener. To illustrate the issue
> I modified the test page from the tomcat faq:
>
>
>
> 1. <%@ page contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
> 2.
> 3.
> 4.
> 5. Character encoding test page
> 6.
> 7.
> 8.
> 9. Encoding : <%=request.getCharacterEncoding()%>
> 10.
> 11. Data posted to this form was:
> 12. <%
> 13. request.setCharacterEncoding("UTF-8");
> 14. out.print(request.getParameter("mydata"));
> 15. %>
> 16.
> 17.
> 18.
> 19.
> 20.
> 21.
> 22.
> 23.
> 24.
> 25. .g. ç,g(,ö,s,,?, etc Soße " Test data "
> 26.
> 27.
>
>
>
> So I have a simple web application which only consist of this page, and
> the weld library in WEB-INF/lib (weld-servlet-2.0.3.Final.jar).
>
> So far so good. However as soon as I include the weld listener in my
> web.xml file
>
>
>
> 1.
> 2.
> 3. http://java.sun.com/xml/ns/javaee";
> 4. xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> 5. xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
> http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd";
> 6. version="3.0">
> 7.
> 8.
> org.jboss.weld.environment.servlet.Listener
> 9.
> 10.
> 11.
> 12. 30
> 13.
> 14.
> 15.
>
>
>
> The post parameters are corrupted by the listener.
>
>
>
> I did enable URIEncoding="UTF-8" in the server.xml file, but this did
> not make any difference.
>
> 1. 2.port="8080" protocol="HTTP/1.1"
> 3.connectionTimeout="2"
> 4.redirectPort="8443"
> 5.URIEncoding="UTF-8"/>
>
>
>
> With the listener enabled data like "Soße" is received as "SoÃY"e",
> however once the listerner is removed everything works as expected.
>
1. I hope you have seen the FAQ.
http://wiki.apache.org/tomcat/FAQ/CharacterEncoding
and
http://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#Set_Character_Encoding_Filter
2. Try to run with a debugger
http://wiki.apache.org/tomcat/FAQ/Developing#Debugging
with a breakpoint in org.apache.catalina.connector.Request#parseParameters()
I guess that there is some component that calls one of getParameter()
methods before your request.setCharacterEncoding("UTF-8") and thus the
default of ISO-8859-1 is effective.
3. What exact version of Tomcat 7.0.x are you using?
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8 & EL 3.0 Issue
On Aug 23, 2013, at 5:25 PM, Mark Thomas wrote:
> On 20/08/2013 16:46, Daniel Mikusa wrote:
>> Hello,
>>
>> I'm seeing some perplexing errors with a couple simple EL test.
>
> Dan,
>
> These look like bugs.
>
> I've taken a quick look at the first and it is fixable if we copy the
> smarter method finding code from ReflectionUtil in the implementation to
> the Util class in the API. I'd like to avoid that much copying if I can
> but I don't see an immediate way around it without creating unwanted
> dependencies.
>
> The second issue will require a little more work as there isn't an
> equivalent constructor finding method that can just be copied.
>
> It will probably be possible to share rather than duplicate code for the
> method and the constructor matching.
>
> To add to the fun, I recall some sensitivities in the EL TCK around the
> method matching. We are going to have to tread carefully.
>
> Please can you create a Bugzilla issue for these.
Certainly. Here's a link.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55483
Thanks
Dan
>
> Thanks,
>
> Mark
>
>>
>> 1.) Here's the first test.
>>
>>@Test
>>public void test01() {
>>ELProcessor processor = new ELProcessor();
>>processor.defineBean("sb", new StringBuilder());
>>Assert.assertEquals("a", processor.eval("sb.append('a');
>> sb.toString()"));
>>}
>>
>> This fails with the following stack trace.
>>
>> javax.el.ELException: Cannot convert a of type class java.lang.String to long
>> at org.apache.el.lang.ELSupport.coerceToNumber(ELSupport.java:349)
>> at org.apache.el.lang.ELSupport.coerceToNumber(ELSupport.java:328)
>> at org.apache.el.lang.ELSupport.coerceToType(ELSupport.java:450)
>> at
>> org.apache.el.ExpressionFactoryImpl.coerceToType(ExpressionFactoryImpl.java:48)
>> at javax.el.Util.buildParameters(Util.java:351)
>> at javax.el.BeanELResolver.invoke(BeanELResolver.java:173)
>> at javax.el.CompositeELResolver.invoke(CompositeELResolver.java:84)
>> at org.apache.el.parser.AstValue.getValue(AstValue.java:157)
>> at org.apache.el.parser.AstSemicolon.getValue(AstSemicolon.java:35)
>> at
>> org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:188)
>> at javax.el.ELProcessor.getValue(ELProcessor.java:45)
>> at javax.el.ELProcessor.eval(ELProcessor.java:38)
>> at
>> org.apache.el.parser.TestAstMethodCalls.test01(TestAstMethodCalls.java:32)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:606)
>> at
>> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
>> at
>> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
>> at
>> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
>> at
>> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
>> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
>> at
>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
>> at
>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
>> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
>> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
>> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
>> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
>> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
>> at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
>> at
>> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
>> at
>> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>> at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
>> at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
>> at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
>> at
>> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
>>
>> Looking into this, it appears that the EL is having trouble because
>> StringBuilder's append method is overloaded. It is instructed to call
>> append with the character 'c', but instead is trying to coerce the character
>> 'c' to a long and call append with the long.
>>
>> This chain of events seems to be kicked off in AstValue.getValue() line
>> #157, where it's calling resolver.invoke(..). The call to resolver.invoke()
>> is passing null as the paramType
Re: Encoding post data on Tomcat 7 using 2.0.3 corrupted
On Aug 26, 2013, at 1:40 AM, Alexander Hartner wrote:
> This may be more of an application problem than a tomcat issue, but I am
> rather stuck with this one and hoping that somebody on this list may be
> able to shed some light on my issue.
>
> I am trying to post UTF-8 encoding text to my JSF2.2 application,
> however the data received does not seem to be encoded correctly.I
> narrowed this problem down to the weld listener. To illustrate the issue
> I modified the test page from the tomcat faq:
>
>
>
> 1. <%@ page contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
> 2.
> 3.
> 4.
> 5. Character encoding test page
> 6.
> 7.
> 8.
> 9. Encoding : <%=request.getCharacterEncoding()%>
> 10.
> 11. Data posted to this form was:
> 12. <%
> 13. request.setCharacterEncoding("UTF-8");
What if you remove line #13? I don't think you should need to do this. The
request's character encoding should be set based on the "Content-Type" header.
If not specified it defaults to ISO-8859-1.
https://wiki.apache.org/tomcat/FAQ/CharacterEncoding#Q1
> 14. out.print(request.getParameter("mydata"));
> 15. %>
> 16.
> 17.
> 18.
> 19.
> 20.
> 21.
> 22.
> 23.
> 24.
> 25. .g. ç,g(,ö,s,,?, etc Soße " Test data "
> 26.
> 27.
>
>
>
> So I have a simple web application which only consist of this page, and
> the weld library in WEB-INF/lib (weld-servlet-2.0.3.Final.jar).
>
> So far so good. However as soon as I include the weld listener in my
> web.xml file
>
>
>
> 1.
> 2.
> 3. http://java.sun.com/xml/ns/javaee";
> 4. xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> 5. xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
> http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd";
> 6. version="3.0">
> 7.
> 8.
> org.jboss.weld.environment.servlet.Listener
> 9.
> 10.
> 11.
> 12. 30
> 13.
> 14.
> 15.
>
> The post parameters are corrupted by the listener.
>
> I did enable URIEncoding="UTF-8" in the server.xml file, but this did
> not make any difference.
>
> 1. 2.port="8080" protocol="HTTP/1.1"
> 3.connectionTimeout="2"
> 4.redirectPort="8443"
> 5.URIEncoding="UTF-8"/>
This option only affects the URI, not posted data.
"This specifies the character encoding used to decode the URI bytes, after
%xx decoding the URL. If not specified, ISO-8859-1 will be used."
https://tomcat.apache.org/tomcat-7.0-doc/config/http.html
>
> With the listener enabled data like "Soße" is received as "SoÃY"e",
> however once the listerner is removed everything works as expected.
If this is actually a problem with the listener, you would have better luck
posting to the weld / listener's mailing list.
Dan
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Migrating from GlassFish to Tomcat 7
On Aug 26, 2013, at 7:52 AM, B W wrote: > Looks like catalina.properties it is ! +1 catalina.properties is great for simple things, and it's more portable. One, not so common reason you might want to use setenv.sh is if you want to do something dynamic. Since setenv.sh is a shell script, you could dynamically capture some value and store it in a system property. Contrived Ex: CATALINA_OPTS="-Dhostname=`hostname`" Dan > On Thu, Aug 22, 2013 at 6:30 PM, Christopher Schultz < > ch...@christopherschultz.net> wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA256 >> >> B W, >> >> On 8/22/13 4:30 PM, B W wrote: >>> What is the advantage to using catalina.properties vs setenv.sh? >> >> If you use setenv.sh, then those system properties will only be >> available if you use the Tomcat scripts to launch. If you use jsvc or >> the Microsoft Windows Service Wrapper, they will not be available. >> >> Using catalina.properties should allow you to set system properties >> that will be loaded regardless of how you launch Tomcat. >> >> - -chris >> -BEGIN PGP SIGNATURE- >> Version: GnuPG v1.4.14 (Darwin) >> Comment: GPGTools - http://gpgtools.org >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >> >> iQIcBAEBCAAGBQJSFpD/AAoJEBzwKT+lPKRYvbEQALWOa8chxGNMyDTb7032vnnX >> iMgD0bdTyfXKHQUpseCikP185gksIXdBajxHKNyKH6lDEJLyl4udHg8dtAAPPlmZ >> FvveRHCuyxlcZXg3qAe7Zsnd83fPVMa5F/ysGDUHUbNIKSAq8YiQtFsnujLRQrKY >> Y+LZdoDMFbS6wNohBaxIQZtsjiOWu+/JblUAcqwOZ6JV0ZhCl6vhtGgp10UFxsjx >> BRz5hE6K8vZcYt2zvVGqB9+Kjy7APIPBB1TJTnp8ieA5Y6+Va/6wCtI6ve1FsH83 >> aj4aEzOejHx5x7shGvz8yr8LfbGGBfRBvHVwVteicffAiBvEPx+5C/t29nR0xJcn >> wvojyA5oSD5/O+W24mrgf27fmsY8JrgivZsnaSPyx2dHp31bbhkfQz7+FI0Hoh02 >> jNzNRoRKECOtmxWH/qI9zd9igOa3Merve1e6x0JWtoT9UOY7YFZRRl0jwDoTM75a >> Ogs0c/kKOlpb57/8iXpffMl9LHD54tCD+XgVb+Dlln7+aSic56eCx+edGqm241fe >> bWtB9o8nOsjzERjwwlkFFyZsXo1cfJza2LOlNSrsJjx+10KT+3cGxwBt+ywn5Q5j >> AhYX/YO8WkdCxei2DcZleFYzuuUyInmHnezoxDHvPfZSOzoPvbXfzyZQP8flSvgQ >> /Q2Pj4X4p65yhV/7s4bj >> =h6mX >> -END PGP SIGNATURE- >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Migrating from GlassFish to Tomcat 7
Looks like catalina.properties it is ! On Thu, Aug 22, 2013 at 6:30 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > B W, > > On 8/22/13 4:30 PM, B W wrote: > > What is the advantage to using catalina.properties vs setenv.sh? > > If you use setenv.sh, then those system properties will only be > available if you use the Tomcat scripts to launch. If you use jsvc or > the Microsoft Windows Service Wrapper, they will not be available. > > Using catalina.properties should allow you to set system properties > that will be loaded regardless of how you launch Tomcat. > > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.14 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCAAGBQJSFpD/AAoJEBzwKT+lPKRYvbEQALWOa8chxGNMyDTb7032vnnX > iMgD0bdTyfXKHQUpseCikP185gksIXdBajxHKNyKH6lDEJLyl4udHg8dtAAPPlmZ > FvveRHCuyxlcZXg3qAe7Zsnd83fPVMa5F/ysGDUHUbNIKSAq8YiQtFsnujLRQrKY > Y+LZdoDMFbS6wNohBaxIQZtsjiOWu+/JblUAcqwOZ6JV0ZhCl6vhtGgp10UFxsjx > BRz5hE6K8vZcYt2zvVGqB9+Kjy7APIPBB1TJTnp8ieA5Y6+Va/6wCtI6ve1FsH83 > aj4aEzOejHx5x7shGvz8yr8LfbGGBfRBvHVwVteicffAiBvEPx+5C/t29nR0xJcn > wvojyA5oSD5/O+W24mrgf27fmsY8JrgivZsnaSPyx2dHp31bbhkfQz7+FI0Hoh02 > jNzNRoRKECOtmxWH/qI9zd9igOa3Merve1e6x0JWtoT9UOY7YFZRRl0jwDoTM75a > Ogs0c/kKOlpb57/8iXpffMl9LHD54tCD+XgVb+Dlln7+aSic56eCx+edGqm241fe > bWtB9o8nOsjzERjwwlkFFyZsXo1cfJza2LOlNSrsJjx+10KT+3cGxwBt+ywn5Q5j > AhYX/YO8WkdCxei2DcZleFYzuuUyInmHnezoxDHvPfZSOzoPvbXfzyZQP8flSvgQ > /Q2Pj4X4p65yhV/7s4bj > =h6mX > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
