Hi
I'm having a problem retrieving parameters in servlets, when submitted
with UTF-16 encoding. Basically, a request like this is sent:
================================================================
POST /bomtest HTTP/1.1
[...]
Content-Type: application/x-www-form-urlencoded;charset=UTF-16
Content-Length: 66
<fe><ff>.u.s.e.r.n.a.m.e.=.x.x.x.&.i.d.=.1.3.4.&.p.a.s.s.w.o.r.d.=.y.y.y
================================================================
where <fe><ff> is a Unicode byte order mark (the above is reliable, from
captured network traffic). A simple test servlet which shows the
encoding and iterates over the request's parameter map prints out:
request.getCharacterEncoding(): UTF-16
param: id?: 134? (6964fffd:313334fffd)
param: password?: yyy (70617373776f7264fffd:797979)
param: username?: xxx? (757365726e616d65fffd:787878fffd)
So, the character <fffd> is getting appended to each query parameter and
each value, except for the last value in the POST body. <fffd> is from
the Unicode block SPECIALS, and is described as "Replacement Character:
used to replace an incoming character whose value is unknown or
unrepresentable in Unicode".
The problem occurs with Jetty-4.2.20 as well as Jetty 5.1.12. It happens
under Sun 1.4, 1.5 and 1.6 JVMs (the latest ones), but works perfectly
under IBM 1.4 JVMs, e.g. 1.4.2.7.
Does this look familiar to anyone?
Thanks
Paolo
(Reposting to jetty-discuss after no responses on jetty-support)

Multiple Web Application Source Directory
-----------------------------------------
Key: JETTY-381
URL: http://jira.codehaus.org/browse/JETTY-381
Project: Jetty
Issue Type: Improvement
Reporter: Jeremy Lauture
Context
-----------
I want to use maven-jetty-pling in hotdeploy mode.
My web app use Struts Framework.
I also use Xdoclet in order to generate the struts-config.xml and validation.xml
But I want to generate these files in a target directory in order to separate the source and generated files
Unfortunatly, this does seems not possible yet because I need to inform jetty that my web app source directory is split in two differents paths (src/main/webapp and target/xdoclet/)
In fact, I need to configure the struts servlet in the web.xml like this :
<init-param>
<param-name>config</param-name>
<param-value>/generated/struts-config.xml</param-value>
</init-param>
It's important to notice that the solution adding the path (target/xdoclet/) in the classpath do not solve my problem. In fact, the problem is not related to the classpath but rather to the web app source directory.
Need
--------
The only solution seems to add a new feature to jetty in order to be able to use multiple web application source directories.
In our case, we would like to have something like that:
<Call name="addLifeCycle">
<Arg>
<New class="org.mortbay.jetty.deployer.WebAppDeployer">
<Set name="contexts"><Ref id="Contexts"/></Set>
<Set name="webAppDirs">
<Array type="java.lang.String">
<Item>src/main/webapp</Item>
<Item>target/xdoclet/</Item>
</Array>
</Set>
[...]
</New>
</Arg>
</Call>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.codehaus.org/browse/JETTY-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100760 ]
Christian d'Heureuse commented on JETTY-380:
--------------------------------------------
I can confirm that the error is fixed with this code modification.
Thank you very much for the quick solution.
> SelectChannelConnector blocks for maxIdleTime ms
> ------------------------------------------------
>
> Key: JETTY-380
> URL: http://jira.codehaus.org/browse/JETTY-380
> Project: Jetty
> Issue Type: Bug
> Components: NIO
> Affects Versions: 6.1.4
> Environment: Windows XP, Java 1.6.0_01-b06
> Reporter: Christian d'Heureuse
> Assignee: Greg Wilkins
> Priority: Critical
>
> When I press the Refresh button in Firefox, the browser sends 18 HTTP GET requests to my servlet application (for alls the GIFs, Stylesheets and Scripts that are references by the page). Firefox seems to use two TCP connections, because some requests are processed in parallel. (The Jetty server and the Firefox browser run on the same Windows-XP machine).
> Often, but not always, Jetty blocks for SelectChannelConnector.maxIdleTime milliseconds during these requests.
> I tried different Jetty versions.
> The effect does not occur for: 6.0.0 and 6.0.1.
> It occurs for 6.0.2, 6.1.0, 6.1.1 and 6.1.4.
> When I use SocketConnector instead of SelectChannelConnector, the effect does not occur.
> While the connection is blocked (until the timeout occurs after maxIdleTime ms), other parallel requests are possible, but it has strange effects on the i/o operations of other threads. Sometimes it blocks console i/o and even loading Java class code from disk seems to be affected.
> When I press Ctrl-Break during the blocking, the following stack trace is displayed for the SelectChannelConnector thread:
> "btpool0-9 - Acceptor0 SelectChannelConnector@...:8080" prio=6 tid=0x0e38ac00 nid=0x1b0 runnable [0x0e7cf000..0x0e7cfa14]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.WindowsSelectorImpl$SubSelector.poll0(Native Method)
> at sun.nio.ch.WindowsSelectorImpl$SubSelector.poll(WindowsSelectorImpl.java:274)
> at sun.nio.ch.WindowsSelectorImpl$SubSelector.access$400(WindowsSelectorImpl.java:256)
> at sun.nio.ch.WindowsSelectorImpl.doSelect(WindowsSelectorImpl.java:137)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)
> - locked <0x045c5568> (a sun.nio.ch.Util$1)
> - locked <0x045c5578> (a java.util.Collections$UnmodifiableSet)
> - locked <0x045c54f0> (a sun.nio.ch.WindowsSelectorImpl)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)
> at org.mortbay.io.nio.SelectorManager$SelectSet.doSelect(SelectorManager.java:432)
> at org.mortbay.io.nio.SelectorManager.doSelect(SelectorManager.java:169)
> at org.mortbay.jetty.nio.SelectChannelConnector.accept(SelectChannelConnector.java:124)
> at org.mortbay.jetty.AbstractConnector$Acceptor.run(AbstractConnector.java:516)
> at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
> Jetty does not print any error messages (even with -DDEBUG=1) and after the timeout everything continues normal.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.codehaus.org/browse/JETTY-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100759 ]
Greg Wilkins commented on JETTY-379:
------------------------------------
Can you try to reproduce this with the latest from svn head?
I have modfied the test webapp to try to reproduce, but I cannot
If you hit http://jetty.mortbay.org:8080/test/dispatch/forward/dump/ex1
you will see it working correctly on our public server.
The ForwardAttributes class does not suppress all javax.servlet attributes, as it
calls _attr.setAttribute if need be. Besides, this is not the path that exception
attributes are set.
thanks
> declared error-page not called for a JasperException
> ----------------------------------------------------
>
> Key: JETTY-379
> URL: http://jira.codehaus.org/browse/JETTY-379
> Project: Jetty
> Issue Type: Bug
> Environment: win xp - eclipse - maven mojo
> Reporter: Andreas Knuth
> Priority: Critical
> Fix For: 6.0.1
>
>
> I've a general error-page which handles all types of Exceptions (e.g. JasperException -> shows een the line with the error)
> * I declare an error-page in web.xml like this
> {code}
> <error-page>
> <exception-type>org.apache.jasper.JasperException</exception-type>
> <location>/error-page.jsp</location>
> </error-page>
> {code}
> This page is never called on an exception *org.apache.jasper.JasperException: /WEB-INF/classes/de/dwpbank/wpdirect/vienna/ug0001samples/uc0004layout/pages/layout1.jsp(13,6) No such tag ro in the tag library imported with prefix v*
> *Reason:*
> * The Throwable above will be set to Dispatcher.ForwardAttributes by the key *javax.servlet.error.exception* but this method suppresses all keys starting on "javax.servlet", so the ErrorPageErrorHandler can never forward to it !
> Why does the Dispatcher.ForwardAttributes.setAttribute(...) does that ?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.codehaus.org/browse/JETTY-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100756 ]
Greg Wilkins commented on JETTY-380:
------------------------------------
DOH!
Jetty has a handler loop that keeps trying to parse requests while progress is being made.
If progress is not being made, it tries a few more times... just in case it is a NIO zero byte moment.
Unfortunately, pipelined requests don't need IO to be handled! So with no IO, after 4 times around
the loop, we just stop return with no more progress!
The fix is to simply clear the no-progress count every time a request is handled!
> SelectChannelConnector blocks for maxIdleTime ms
> ------------------------------------------------
>
> Key: JETTY-380
> URL: http://jira.codehaus.org/browse/JETTY-380
> Project: Jetty
> Issue Type: Bug
> Components: NIO
> Affects Versions: 6.1.4
> Environment: Windows XP, Java 1.6.0_01-b06
> Reporter: Christian d'Heureuse
> Assignee: Greg Wilkins
> Priority: Critical
>
> When I press the Refresh button in Firefox, the browser sends 18 HTTP GET requests to my servlet application (for alls the GIFs, Stylesheets and Scripts that are references by the page). Firefox seems to use two TCP connections, because some requests are processed in parallel. (The Jetty server and the Firefox browser run on the same Windows-XP machine).
> Often, but not always, Jetty blocks for SelectChannelConnector.maxIdleTime milliseconds during these requests.
> I tried different Jetty versions.
> The effect does not occur for: 6.0.0 and 6.0.1.
> It occurs for 6.0.2, 6.1.0, 6.1.1 and 6.1.4.
> When I use SocketConnector instead of SelectChannelConnector, the effect does not occur.
> While the connection is blocked (until the timeout occurs after maxIdleTime ms), other parallel requests are possible, but it has strange effects on the i/o operations of other threads. Sometimes it blocks console i/o and even loading Java class code from disk seems to be affected.
> When I press Ctrl-Break during the blocking, the following stack trace is displayed for the SelectChannelConnector thread:
> "btpool0-9 - Acceptor0 SelectChannelConnector@...:8080" prio=6 tid=0x0e38ac00 nid=0x1b0 runnable [0x0e7cf000..0x0e7cfa14]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.WindowsSelectorImpl$SubSelector.poll0(Native Method)
> at sun.nio.ch.WindowsSelectorImpl$SubSelector.poll(WindowsSelectorImpl.java:274)
> at sun.nio.ch.WindowsSelectorImpl$SubSelector.access$400(WindowsSelectorImpl.java:256)
> at sun.nio.ch.WindowsSelectorImpl.doSelect(WindowsSelectorImpl.java:137)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)
> - locked <0x045c5568> (a sun.nio.ch.Util$1)
> - locked <0x045c5578> (a java.util.Collections$UnmodifiableSet)
> - locked <0x045c54f0> (a sun.nio.ch.WindowsSelectorImpl)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)
> at org.mortbay.io.nio.SelectorManager$SelectSet.doSelect(SelectorManager.java:432)
> at org.mortbay.io.nio.SelectorManager.doSelect(SelectorManager.java:169)
> at org.mortbay.jetty.nio.SelectChannelConnector.accept(SelectChannelConnector.java:124)
> at org.mortbay.jetty.AbstractConnector$Acceptor.run(AbstractConnector.java:516)
> at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
> Jetty does not print any error messages (even with -DDEBUG=1) and after the timeout everything continues normal.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.codehaus.org/browse/JETTY-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100754 ]
Greg Wilkins commented on JETTY-380:
------------------------------------
Don't worry about wireshark dump.
I have managed to reproduce this by making a test harness that creates large pipelines
working on diagnosis and fix
> SelectChannelConnector blocks for maxIdleTime ms
> ------------------------------------------------
>
> Key: JETTY-380
> URL: http://jira.codehaus.org/browse/JETTY-380
> Project: Jetty
> Issue Type: Bug
> Components: NIO
> Affects Versions: 6.1.4
> Environment: Windows XP, Java 1.6.0_01-b06
> Reporter: Christian d'Heureuse
> Assignee: Greg Wilkins
> Priority: Critical
>
> When I press the Refresh button in Firefox, the browser sends 18 HTTP GET requests to my servlet application (for alls the GIFs, Stylesheets and Scripts that are references by the page). Firefox seems to use two TCP connections, because some requests are processed in parallel. (The Jetty server and the Firefox browser run on the same Windows-XP machine).
> Often, but not always, Jetty blocks for SelectChannelConnector.maxIdleTime milliseconds during these requests.
> I tried different Jetty versions.
> The effect does not occur for: 6.0.0 and 6.0.1.
> It occurs for 6.0.2, 6.1.0, 6.1.1 and 6.1.4.
> When I use SocketConnector instead of SelectChannelConnector, the effect does not occur.
> While the connection is blocked (until the timeout occurs after maxIdleTime ms), other parallel requests are possible, but it has strange effects on the i/o operations of other threads. Sometimes it blocks console i/o and even loading Java class code from disk seems to be affected.
> When I press Ctrl-Break during the blocking, the following stack trace is displayed for the SelectChannelConnector thread:
> "btpool0-9 - Acceptor0 SelectChannelConnector@...:8080" prio=6 tid=0x0e38ac00 nid=0x1b0 runnable [0x0e7cf000..0x0e7cfa14]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.WindowsSelectorImpl$SubSelector.poll0(Native Method)
> at sun.nio.ch.WindowsSelectorImpl$SubSelector.poll(WindowsSelectorImpl.java:274)
> at sun.nio.ch.WindowsSelectorImpl$SubSelector.access$400(WindowsSelectorImpl.java:256)
> at sun.nio.ch.WindowsSelectorImpl.doSelect(WindowsSelectorImpl.java:137)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)
> - locked <0x045c5568> (a sun.nio.ch.Util$1)
> - locked <0x045c5578> (a java.util.Collections$UnmodifiableSet)
> - locked <0x045c54f0> (a sun.nio.ch.WindowsSelectorImpl)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)
> at org.mortbay.io.nio.SelectorManager$SelectSet.doSelect(SelectorManager.java:432)
> at org.mortbay.io.nio.SelectorManager.doSelect(SelectorManager.java:169)
> at org.mortbay.jetty.nio.SelectChannelConnector.accept(SelectChannelConnector.java:124)
> at org.mortbay.jetty.AbstractConnector$Acceptor.run(AbstractConnector.java:516)
> at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
> Jetty does not print any error messages (even with -DDEBUG=1) and after the timeout everything continues normal.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.codehaus.org/browse/JETTY-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100752 ]
Christian d'Heureuse commented on JETTY-380:
--------------------------------------------
Greg, thanks for your quick reply.
When I change network.http.pipelining from true to false in Firefox, the error does not occur any more.
And when I have network.http.pipelining=true and change network.http.pipelining.maxrequests from 8 to 4 (which is the default), the error also does no longer occur.
It occurs with the following settings:
network.http.pipelining=true
network.http.pipelining.maxrequests=8
I will now try to capture the TCP packets. I cannot do it directly, because Wireshark cannot capture the localhost interface in Windows.
> SelectChannelConnector blocks for maxIdleTime ms
> ------------------------------------------------
>
> Key: JETTY-380
> URL: http://jira.codehaus.org/browse/JETTY-380
> Project: Jetty
> Issue Type: Bug
> Components: NIO
> Affects Versions: 6.1.4
> Environment: Windows XP, Java 1.6.0_01-b06
> Reporter: Christian d'Heureuse
> Assignee: Greg Wilkins
> Priority: Critical
>
> When I press the Refresh button in Firefox, the browser sends 18 HTTP GET requests to my servlet application (for alls the GIFs, Stylesheets and Scripts that are references by the page). Firefox seems to use two TCP connections, because some requests are processed in parallel. (The Jetty server and the Firefox browser run on the same Windows-XP machine).
> Often, but not always, Jetty blocks for SelectChannelConnector.maxIdleTime milliseconds during these requests.
> I tried different Jetty versions.
> The effect does not occur for: 6.0.0 and 6.0.1.
> It occurs for 6.0.2, 6.1.0, 6.1.1 and 6.1.4.
> When I use SocketConnector instead of SelectChannelConnector, the effect does not occur.
> While the connection is blocked (until the timeout occurs after maxIdleTime ms), other parallel requests are possible, but it has strange effects on the i/o operations of other threads. Sometimes it blocks console i/o and even loading Java class code from disk seems to be affected.
> When I press Ctrl-Break during the blocking, the following stack trace is displayed for the SelectChannelConnector thread:
> "btpool0-9 - Acceptor0 SelectChannelConnector@...:8080" prio=6 tid=0x0e38ac00 nid=0x1b0 runnable [0x0e7cf000..0x0e7cfa14]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.WindowsSelectorImpl$SubSelector.poll0(Native Method)
> at sun.nio.ch.WindowsSelectorImpl$SubSelector.poll(WindowsSelectorImpl.java:274)
> at sun.nio.ch.WindowsSelectorImpl$SubSelector.access$400(WindowsSelectorImpl.java:256)
> at sun.nio.ch.WindowsSelectorImpl.doSelect(WindowsSelectorImpl.java:137)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)
> - locked <0x045c5568> (a sun.nio.ch.Util$1)
> - locked <0x045c5578> (a java.util.Collections$UnmodifiableSet)
> - locked <0x045c54f0> (a sun.nio.ch.WindowsSelectorImpl)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)
> at org.mortbay.io.nio.SelectorManager$SelectSet.doSelect(SelectorManager.java:432)
> at org.mortbay.io.nio.SelectorManager.doSelect(SelectorManager.java:169)
> at org.mortbay.jetty.nio.SelectChannelConnector.accept(SelectChannelConnector.java:124)
> at org.mortbay.jetty.AbstractConnector$Acceptor.run(AbstractConnector.java:516)
> at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
> Jetty does not print any error messages (even with -DDEBUG=1) and after the timeout everything continues normal.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.codehaus.org/browse/JETTY-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100740 ]
Greg Wilkins commented on JETTY-380:
------------------------------------
Christian,
that stack trace is totally normal and that is where I would expect the acceptor thread to be.
the blocking on the other hand, is not normal.
Can you capture one of these events with tcpdump or wireshark or similar.
Can you also reproduce in a simply small webapp that you can attach to this issue?
finally, can you go to the about:config page of your firefox and report the value of
network.http.pipelining. You can try switching that value and see if that changes anything.
regards
> SelectChannelConnector blocks for maxIdleTime ms
> ------------------------------------------------
>
> Key: JETTY-380
> URL: http://jira.codehaus.org/browse/JETTY-380
> Project: Jetty
> Issue Type: Bug
> Components: NIO
> Affects Versions: 6.1.4
> Environment: Windows XP, Java 1.6.0_01-b06
> Reporter: Christian d'Heureuse
> Assignee: Greg Wilkins
> Priority: Critical
>
> When I press the Refresh button in Firefox, the browser sends 18 HTTP GET requests to my servlet application (for alls the GIFs, Stylesheets and Scripts that are references by the page). Firefox seems to use two TCP connections, because some requests are processed in parallel. (The Jetty server and the Firefox browser run on the same Windows-XP machine).
> Often, but not always, Jetty blocks for SelectChannelConnector.maxIdleTime milliseconds during these requests.
> I tried different Jetty versions.
> The effect does not occur for: 6.0.0 and 6.0.1.
> It occurs for 6.0.2, 6.1.0, 6.1.1 and 6.1.4.
> When I use SocketConnector instead of SelectChannelConnector, the effect does not occur.
> While the connection is blocked (until the timeout occurs after maxIdleTime ms), other parallel requests are possible, but it has strange effects on the i/o operations of other threads. Sometimes it blocks console i/o and even loading Java class code from disk seems to be affected.
> When I press Ctrl-Break during the blocking, the following stack trace is displayed for the SelectChannelConnector thread:
> "btpool0-9 - Acceptor0 SelectChannelConnector@...:8080" prio=6 tid=0x0e38ac00 nid=0x1b0 runnable [0x0e7cf000..0x0e7cfa14]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.WindowsSelectorImpl$SubSelector.poll0(Native Method)
> at sun.nio.ch.WindowsSelectorImpl$SubSelector.poll(WindowsSelectorImpl.java:274)
> at sun.nio.ch.WindowsSelectorImpl$SubSelector.access$400(WindowsSelectorImpl.java:256)
> at sun.nio.ch.WindowsSelectorImpl.doSelect(WindowsSelectorImpl.java:137)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)
> - locked <0x045c5568> (a sun.nio.ch.Util$1)
> - locked <0x045c5578> (a java.util.Collections$UnmodifiableSet)
> - locked <0x045c54f0> (a sun.nio.ch.WindowsSelectorImpl)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)
> at org.mortbay.io.nio.SelectorManager$SelectSet.doSelect(SelectorManager.java:432)
> at org.mortbay.io.nio.SelectorManager.doSelect(SelectorManager.java:169)
> at org.mortbay.jetty.nio.SelectChannelConnector.accept(SelectChannelConnector.java:124)
> at org.mortbay.jetty.AbstractConnector$Acceptor.run(AbstractConnector.java:516)
> at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
> Jetty does not print any error messages (even with -DDEBUG=1) and after the timeout everything continues normal.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

SelectChannelConnector blocks for maxIdleTime ms
------------------------------------------------
Key: JETTY-380
URL: http://jira.codehaus.org/browse/JETTY-380
Project: Jetty
Issue Type: Bug
Components: NIO
Affects Versions: 6.1.4
Environment: Windows XP, Java 1.6.0_01-b06
Reporter: Christian d'Heureuse
Priority: Critical
When I press the Refresh button in Firefox, the browser sends 18 HTTP GET requests to my servlet application (for alls the GIFs, Stylesheets and Scripts that are references by the page). Firefox seems to use two TCP connections, because some requests are processed in parallel. (The Jetty server and the Firefox browser run on the same Windows-XP machine).
Often, but not always, Jetty blocks for SelectChannelConnector.maxIdleTime milliseconds during these requests.
I tried different Jetty versions.
The effect does not occur for: 6.0.0 and 6.0.1.
It occurs for 6.0.2, 6.1.0, 6.1.1 and 6.1.4.
When I use SocketConnector instead of SelectChannelConnector, the effect does not occur.
While the connection is blocked (until the timeout occurs after maxIdleTime ms), other parallel requests are possible, but it has strange effects on the i/o operations of other threads. Sometimes it blocks console i/o and even loading Java class code from disk seems to be affected.
When I press Ctrl-Break during the blocking, the following stack trace is displayed for the SelectChannelConnector thread:
"btpool0-9 - Acceptor0 SelectChannelConnector@...:8080" prio=6 tid=0x0e38ac00 nid=0x1b0 runnable [0x0e7cf000..0x0e7cfa14]
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.WindowsSelectorImpl$SubSelector.poll0(Native Method)
at sun.nio.ch.WindowsSelectorImpl$SubSelector.poll(WindowsSelectorImpl.java:274)
at sun.nio.ch.WindowsSelectorImpl$SubSelector.access$400(WindowsSelectorImpl.java:256)
at sun.nio.ch.WindowsSelectorImpl.doSelect(WindowsSelectorImpl.java:137)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)
- locked <0x045c5568> (a sun.nio.ch.Util$1)
- locked <0x045c5578> (a java.util.Collections$UnmodifiableSet)
- locked <0x045c54f0> (a sun.nio.ch.WindowsSelectorImpl)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)
at org.mortbay.io.nio.SelectorManager$SelectSet.doSelect(SelectorManager.java:432)
at org.mortbay.io.nio.SelectorManager.doSelect(SelectorManager.java:169)
at org.mortbay.jetty.nio.SelectChannelConnector.accept(SelectChannelConnector.java:124)
at org.mortbay.jetty.AbstractConnector$Acceptor.run(AbstractConnector.java:516)
at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
Jetty does not print any error messages (even with -DDEBUG=1) and after the timeout everything continues normal.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

declared error-page not called for a JasperException
----------------------------------------------------
Key: JETTY-379
URL: http://jira.codehaus.org/browse/JETTY-379
Project: Jetty
Issue Type: Bug
Environment: win xp - eclipse - maven mojo
Reporter: Andreas Knuth
Priority: Critical
Fix For: 6.0.1
I've a general error-page which handles all types of Exceptions (e.g. JasperException -> shows een the line with the error)
* I declare an error-page in web.xml like this
{code}
<error-page>
<exception-type>org.apache.jasper.JasperException</exception-type>
<location>/error-page.jsp</location>
</error-page>
{code}
This page is never called on an exception *org.apache.jasper.JasperException: /WEB-INF/classes/de/dwpbank/wpdirect/vienna/ug0001samples/uc0004layout/pages/layout1.jsp(13,6) No such tag ro in the tag library imported with prefix v*
*Reason:*
* The Throwable above will be set to Dispatcher.ForwardAttributes by the key *javax.servlet.error.exception* but this method suppresses all keys starting on "javax.servlet", so the ErrorPageErrorHandler can never forward to it !
Why does the Dispatcher.ForwardAttributes.setAttribute(...) does that ?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.codehaus.org/browse/JETTY-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100666 ]
Ate Douma commented on JETTY-377:
---------------------------------
Ok, that's cool.
I'll try to test it out today and let you know.
> Support HttpSession proxying to allow portlet bridges to provide "scoped" session view to dispatched servlets
> -------------------------------------------------------------------------------------------------------------
>
> Key: JETTY-377
> URL: http://jira.codehaus.org/browse/JETTY-377
> Project: Jetty
> Issue Type: Improvement
> Components: Servlet
> Affects Versions: 6.1.4
> Environment: JDK 1.5, Jetty 6.1.4, Jetspeed-2.1.1-dev
> Reporter: Ate Douma
> Assignee: Greg Wilkins
> Attachments: patch.txt, patch2.txt
>
>
> Apache Portals Bridges provides a neat solution (I wrote myself ;) ) to "scope" HttpSession attributes for a specific Portlet window when it dispatches to a servlet.
> See: http://svn.apache.org/viewvc/portals/bridges/trunk/common/src/java/org/apache/portals/bridges/util/ServletPortletSessionProxy.java?view=markup
> This solution is needed for transparent "bridging" of existing web development frameworks like Struts, or Wicket (which I'm currently working on) to portlets.
> So far, this proxy solution works like a charm and I've tested it successfully on Tomcat, Websphere, WebLogic and GlassFish.
> Only with Jetty it fails :(
> The reason is simple: AbstractSessionManager uses direct type casting of a provided HttpSession parameter to its inner Session class, so when a proxied version is passed in a ClassCastException is the result.
> But the solution is also very simple, small and completely non-intrusive and I've attached a patch for it.
> It adds a new interface JettySession with one method: JettySession getJettySession() and applies it to AbstractSessionManager.Session.
> That interface allows Jetty to always get back to its own/underlying Session class.
> With this patch applied, I can now run Jetspeed-2.1.1 (trunk) fully on Jetty 6.1.4 and we're planning to provide a Jetty based Jetspeed-2 demo installer with the imminent 2.1.1 release including neat hot deployment of war support.. But we will need to provide our own patched version of Jetty until this issue can be resolved.
> (NB: I'm also a Jetspeed-2 committer)
> So I would very much appreciate if you can review and consider this patch for inclusion in the next version of Jetty so we won't need to use a patched version of Jetty for running Jetspeed-2.
> Regards,
> Ate
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.codehaus.org/browse/JETTY-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Greg Wilkins resolved JETTY-377.
--------------------------------
Resolution: Fixed
Ate,
this is not a real attribute and is not listed in the names, can't be replaced and does not use memory/cycles in the attribute map.
It is a common technique used by most container implementations to expose private APIs
via attributes.
This is checked in now and it would be good to know if this is working for you.
I am pushing a maven snapshot at the moment.
> Support HttpSession proxying to allow portlet bridges to provide "scoped" session view to dispatched servlets
> -------------------------------------------------------------------------------------------------------------
>
> Key: JETTY-377
> URL: http://jira.codehaus.org/browse/JETTY-377
> Project: Jetty
> Issue Type: Improvement
> Components: Servlet
> Affects Versions: 6.1.4
> Environment: JDK 1.5, Jetty 6.1.4, Jetspeed-2.1.1-dev
> Reporter: Ate Douma
> Assignee: Greg Wilkins
> Attachments: patch.txt, patch2.txt
>
>
> Apache Portals Bridges provides a neat solution (I wrote myself ;) ) to "scope" HttpSession attributes for a specific Portlet window when it dispatches to a servlet.
> See: http://svn.apache.org/viewvc/portals/bridges/trunk/common/src/java/org/apache/portals/bridges/util/ServletPortletSessionProxy.java?view=markup
> This solution is needed for transparent "bridging" of existing web development frameworks like Struts, or Wicket (which I'm currently working on) to portlets.
> So far, this proxy solution works like a charm and I've tested it successfully on Tomcat, Websphere, WebLogic and GlassFish.
> Only with Jetty it fails :(
> The reason is simple: AbstractSessionManager uses direct type casting of a provided HttpSession parameter to its inner Session class, so when a proxied version is passed in a ClassCastException is the result.
> But the solution is also very simple, small and completely non-intrusive and I've attached a patch for it.
> It adds a new interface JettySession with one method: JettySession getJettySession() and applies it to AbstractSessionManager.Session.
> That interface allows Jetty to always get back to its own/underlying Session class.
> With this patch applied, I can now run Jetspeed-2.1.1 (trunk) fully on Jetty 6.1.4 and we're planning to provide a Jetty based Jetspeed-2 demo installer with the imminent 2.1.1 release including neat hot deployment of war support.. But we will need to provide our own patched version of Jetty until this issue can be resolved.
> (NB: I'm also a Jetspeed-2 committer)
> So I would very much appreciate if you can review and consider this patch for inclusion in the next version of Jetty so we won't need to use a patched version of Jetty for running Jetspeed-2.
> Regards,
> Ate
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.codehaus.org/browse/JETTY-378?page=3Dcom.atlassian.jira.p=
lugin.system.issuetabpanels:comment-tabpanel#action_100656 ]=20
Greg Wilkins commented on JETTY-378:
------------------------------------
Jason,
I have checked in what should be at least a partial fix for this issue.
But, a larger audit/test would be needed to confirm all functions operate
correctly.
> encoding on zOS
> ---------------
>
> Key: JETTY-378
> URL: http://jira.codehaus.org/browse/JETTY-378
> Project: Jetty
> Issue Type: Bug
> Affects Versions: 6.1.4
> Environment: zOS
> Reporter: Greg Wilkins
> Priority: Minor
>
> From jason randall:
> I'm making a call to getRequestURL() on the Request object from a servlet
> running on Jetty 6.1.1 on a z/OS machine running with uss using the defau=
lt file
> encoding which is Cp1047. This call returns almost everything correctly,
> including the scheme, port and uri. However, the host name is encoded
> improperly. So for example instead of getting the following:
> http://mvsbuss:9080/redirect
> I get:
> http://_=CE=CB=C2=CD=CB=CB=9A=98=90=98=90:9080/redirect
> It looks like the getServerName in org.mortbay.jetty.Request is assuming =
the
> value in the Host HTTP Header is using the mainframe's default system enc=
oding.
> AbstractBuffer.toString() does not provide a character encoding option o=
ther
> than the system's character encoding. Whereas when determining the
> Request.getResultURI() a UTF-8 encoding scheme is used no matter what the
> system's encoding is set. =20
> I do have a workaround for this issue by re-encoding the server name usin=
g UTF-8
> however I get a similar issue when the DefaultServlet (makes a call to
> passConditionalHeaders) attempts to parse the value in the If-Modified-Si=
nce
> header as a date but the string was encoding using the system default and=
a
> java.lang.IllegalArgumentException: Cannot convert date is thrown.
> I would rather not set the file.encoding system property to UTF-8 because=
then
> my log files will not be readable on the z/OS machine. This was working
> properly in Jetty 4.1 without having to set the file.encoding property.
> Any insight into a possible work aroud for this would be appreciated.
--=20
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: htt=
p://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.codehaus.org/browse/JETTY-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100640 ]
Ate Douma commented on JETTY-377:
---------------------------------
Although through session.getAttributeNames() someone could get to this "private" attribute and thus theoretically even remove it, they're self to blame then I guess.
So for me its a fine solution too.
> Support HttpSession proxying to allow portlet bridges to provide "scoped" session view to dispatched servlets
> -------------------------------------------------------------------------------------------------------------
>
> Key: JETTY-377
> URL: http://jira.codehaus.org/browse/JETTY-377
> Project: Jetty
> Issue Type: Improvement
> Components: Servlet
> Affects Versions: 6.1.4
> Environment: JDK 1.5, Jetty 6.1.4, Jetspeed-2.1.1-dev
> Reporter: Ate Douma
> Assignee: Greg Wilkins
> Attachments: patch.txt, patch2.txt
>
>
> Apache Portals Bridges provides a neat solution (I wrote myself ;) ) to "scope" HttpSession attributes for a specific Portlet window when it dispatches to a servlet.
> See: http://svn.apache.org/viewvc/portals/bridges/trunk/common/src/java/org/apache/portals/bridges/util/ServletPortletSessionProxy.java?view=markup
> This solution is needed for transparent "bridging" of existing web development frameworks like Struts, or Wicket (which I'm currently working on) to portlets.
> So far, this proxy solution works like a charm and I've tested it successfully on Tomcat, Websphere, WebLogic and GlassFish.
> Only with Jetty it fails :(
> The reason is simple: AbstractSessionManager uses direct type casting of a provided HttpSession parameter to its inner Session class, so when a proxied version is passed in a ClassCastException is the result.
> But the solution is also very simple, small and completely non-intrusive and I've attached a patch for it.
> It adds a new interface JettySession with one method: JettySession getJettySession() and applies it to AbstractSessionManager.Session.
> That interface allows Jetty to always get back to its own/underlying Session class.
> With this patch applied, I can now run Jetspeed-2.1.1 (trunk) fully on Jetty 6.1.4 and we're planning to provide a Jetty based Jetspeed-2 demo installer with the imminent 2.1.1 release including neat hot deployment of war support.. But we will need to provide our own patched version of Jetty until this issue can be resolved.
> (NB: I'm also a Jetspeed-2 committer)
> So I would very much appreciate if you can review and consider this patch for inclusion in the next version of Jetty so we won't need to use a patched version of Jetty for running Jetspeed-2.
> Regards,
> Ate
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Jason,
I've opened
http://jira.codehaus.org/browse/JETTY-378
and will investigate
but I suspect there could be other issues as well.
If it is just log files that prevent setting file.encoding,
then it may be easier having an encoding option on the log file.
--
Greg Wilkins<gregw@...> US: +1 3104915462
http://www.webtide.com UK: +44(0)2079932589 AU: +61(0)417786631

encoding on zOS
---------------
Key: JETTY-378
URL: http://jira.codehaus.org/browse/JETTY-378
Project: Jetty
Issue Type: Bug
Affects Versions: 6.1.4
Environment: zOS
Reporter: Greg Wilkins
Priority: Minor
>From jason randall:
I'm making a call to getRequestURL() on the Request object from a servlet
running on Jetty 6.1.1 on a z/OS machine running with uss using the default=
file
encoding which is Cp1047. This call returns almost everything correctly,
including the scheme, port and uri. However, the host name is encoded
improperly. So for example instead of getting the following:
http://mvsbuss:9080/redirect
I get:
http://_=CE=CB=C2=CD=CB=CB=9A=98=90=98=90:9080/redirect
It looks like the getServerName in org.mortbay.jetty.Request is assuming th=
e
value in the Host HTTP Header is using the mainframe's default system encod=
ing.
AbstractBuffer.toString() does not provide a character encoding option oth=
er
than the system's character encoding. Whereas when determining the
Request.getResultURI() a UTF-8 encoding scheme is used no matter what the
system's encoding is set. =20
I do have a workaround for this issue by re-encoding the server name using =
UTF-8
however I get a similar issue when the DefaultServlet (makes a call to
passConditionalHeaders) attempts to parse the value in the If-Modified-Sinc=
e
header as a date but the string was encoding using the system default and a
java.lang.IllegalArgumentException: Cannot convert date is thrown.
I would rather not set the file.encoding system property to UTF-8 because t=
hen
my log files will not be readable on the z/OS machine. This was working
properly in Jetty 4.1 without having to set the file.encoding property.
Any insight into a possible work aroud for this would be appreciated.
--=20
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: htt=
p://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.codehaus.org/browse/JETTY-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100616 ]
Greg Wilkins commented on JETTY-377:
------------------------------------
Actually, I have thought of a third way that is fast.
I will use the getAttribute(String) method and do an == check on a name of "org.mortbay.jetty.servlet.Session"
and if it matches, I will pass back the session.
So the line is now:
Session s = (Session)((session instanceof Session)?session:session.getAttribute(SESSION_ATTR));
because it is an == check, it is fast
because the string is private static, no other session user can get it.
So it is a perfect way to tunnel through any wrappers/proxies.
I have implemented this and will check in after a bit more testing.
cheers
> Support HttpSession proxying to allow portlet bridges to provide "scoped" session view to dispatched servlets
> -------------------------------------------------------------------------------------------------------------
>
> Key: JETTY-377
> URL: http://jira.codehaus.org/browse/JETTY-377
> Project: Jetty
> Issue Type: Improvement
> Components: Servlet
> Affects Versions: 6.1.4
> Environment: JDK 1.5, Jetty 6.1.4, Jetspeed-2.1.1-dev
> Reporter: Ate Douma
> Assignee: Greg Wilkins
> Attachments: patch.txt, patch2.txt
>
>
> Apache Portals Bridges provides a neat solution (I wrote myself ;) ) to "scope" HttpSession attributes for a specific Portlet window when it dispatches to a servlet.
> See: http://svn.apache.org/viewvc/portals/bridges/trunk/common/src/java/org/apache/portals/bridges/util/ServletPortletSessionProxy.java?view=markup
> This solution is needed for transparent "bridging" of existing web development frameworks like Struts, or Wicket (which I'm currently working on) to portlets.
> So far, this proxy solution works like a charm and I've tested it successfully on Tomcat, Websphere, WebLogic and GlassFish.
> Only with Jetty it fails :(
> The reason is simple: AbstractSessionManager uses direct type casting of a provided HttpSession parameter to its inner Session class, so when a proxied version is passed in a ClassCastException is the result.
> But the solution is also very simple, small and completely non-intrusive and I've attached a patch for it.
> It adds a new interface JettySession with one method: JettySession getJettySession() and applies it to AbstractSessionManager.Session.
> That interface allows Jetty to always get back to its own/underlying Session class.
> With this patch applied, I can now run Jetspeed-2.1.1 (trunk) fully on Jetty 6.1.4 and we're planning to provide a Jetty based Jetspeed-2 demo installer with the imminent 2.1.1 release including neat hot deployment of war support.. But we will need to provide our own patched version of Jetty until this issue can be resolved.
> (NB: I'm also a Jetspeed-2 committer)
> So I would very much appreciate if you can review and consider this patch for inclusion in the next version of Jetty so we won't need to use a patched version of Jetty for running Jetspeed-2.
> Regards,
> Ate
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.codehaus.org/browse/JETTY-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Greg Wilkins reassigned JETTY-377:
----------------------------------
Assignee: Greg Wilkins
> Support HttpSession proxying to allow portlet bridges to provide "scoped" session view to dispatched servlets
> -------------------------------------------------------------------------------------------------------------
>
> Key: JETTY-377
> URL: http://jira.codehaus.org/browse/JETTY-377
> Project: Jetty
> Issue Type: Improvement
> Components: Servlet
> Affects Versions: 6.1.4
> Environment: JDK 1.5, Jetty 6.1.4, Jetspeed-2.1.1-dev
> Reporter: Ate Douma
> Assignee: Greg Wilkins
> Attachments: patch.txt, patch2.txt
>
>
> Apache Portals Bridges provides a neat solution (I wrote myself ;) ) to "scope" HttpSession attributes for a specific Portlet window when it dispatches to a servlet.
> See: http://svn.apache.org/viewvc/portals/bridges/trunk/common/src/java/org/apache/portals/bridges/util/ServletPortletSessionProxy.java?view=markup
> This solution is needed for transparent "bridging" of existing web development frameworks like Struts, or Wicket (which I'm currently working on) to portlets.
> So far, this proxy solution works like a charm and I've tested it successfully on Tomcat, Websphere, WebLogic and GlassFish.
> Only with Jetty it fails :(
> The reason is simple: AbstractSessionManager uses direct type casting of a provided HttpSession parameter to its inner Session class, so when a proxied version is passed in a ClassCastException is the result.
> But the solution is also very simple, small and completely non-intrusive and I've attached a patch for it.
> It adds a new interface JettySession with one method: JettySession getJettySession() and applies it to AbstractSessionManager.Session.
> That interface allows Jetty to always get back to its own/underlying Session class.
> With this patch applied, I can now run Jetspeed-2.1.1 (trunk) fully on Jetty 6.1.4 and we're planning to provide a Jetty based Jetspeed-2 demo installer with the imminent 2.1.1 release including neat hot deployment of war support.. But we will need to provide our own patched version of Jetty until this issue can be resolved.
> (NB: I'm also a Jetspeed-2 committer)
> So I would very much appreciate if you can review and consider this patch for inclusion in the next version of Jetty so we won't need to use a patched version of Jetty for running Jetspeed-2.
> Regards,
> Ate
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

I'm making a call to getRequestURL() on the Request object from a servlet
running on Jetty 6.1.1 on a z/OS machine running with uss using the default file
encoding which is Cp1047. This call returns almost everything correctly,
including the scheme, port and uri. However, the host name is encoded
improperly. So for example instead of getting the following:
http://mvsbuss:9080/redirect
I get:
http://_ÎËÂÍËËš˜˜:9080/redirect
It looks like the getServerName in org.mortbay.jetty.Request is assuming the
value in the Host HTTP Header is using the mainframe's default system encoding.
AbstractBuffer.toString() does not provide a character encoding option other
than the system's character encoding. Whereas when determining the
Request.getResultURI() a UTF-8 encoding scheme is used no matter what the
system's encoding is set.
I do have a workaround for this issue by re-encoding the server name using UTF-8
however I get a similar issue when the DefaultServlet (makes a call to
passConditionalHeaders) attempts to parse the value in the If-Modified-Since
header as a date but the string was encoding using the system default and a
java.lang.IllegalArgumentException: Cannot convert date is thrown.
I would rather not set the file.encoding system property to UTF-8 because then
my log files will not be readable on the z/OS machine. This was working
properly in Jetty 4.1 without having to set the file.encoding property.
Any insight into a possible work aroud for this would be appreciated.
Regards,
Jason