Re: Does JSR-356 provide a way for a client to pass security info on connect?
On Thu, Sep 5, 2013 at 8:48 AM, Niki Dokovski nick...@gmail.com wrote: On Thu, Sep 5, 2013 at 12:44 AM, Bob DeRemer bob.dere...@thingworx.comwrote: -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: Wednesday, September 04, 2013 3:59 PM To: Tomcat Users List Subject: Re: Does JSR-356 provide a way for a client to pass security info on connect? Bob DeRemer wrote: I'm curious if there's anything defined in JSR-356 to enable a client to pass some security claims in the connect that would allow me to perform an auth check - prior to actually establishing the websocket connection. In an attempt to avoid a websocket DOS, I'm looking to see whether we can do an auth check in the ServerEndpoint onOpen (or, possibly at an earlier stage) - before the actual websocket gets established. I know we can do this at the application level in the onMessage, but it'd be good to handle this before setting up the actual websocket if possible. From a not really websocket specialist : As I recall, a websocket link starts with a normal HTTP request, which then gets upgraded to a websocket connection. So it should be possible to do AAA at the initial HTTP stage, no ? From an earlier thread a couple of weeks (?) ago, it seems however difficult to retrieve some of that HTTP-level information later, when the websocket connection is established. Exactly what I am hoping to do: the WebSocket spec outlines the HTTP Upgrade handshake process. During this handshake, a client should be able to send additional HTTP headers for this exact purpose (i.e. cookies, auth tokens, etc.). The server-side just needs an application-level hook that can be called that can effectively link into the pipeline - allowing/rejecting the establishment of the connection. So, the big question(s): 1) does the tomcat client-side JSR impl provide a way to pass HTTP headers in the initial upgrade handshake Yes background http://docs.oracle.com/javaee/7/api/javax/websocket/ClientEndpointConfig.Configurator.html#beforeRequest(java.util.Map) There is a mutuable headers map. 2) does the tomcat server-side JSR impl provide a way to hook into the upgrade handshake and effectively allow/reject the connection Yes and (need to check further :)) background http://docs.oracle.com/javaee/7/api/javax/websocket/server/ServerEndpointConfig.Configurator.html#modifyHandshake(javax.websocket.server.ServerEndpointConfig, javax.websocket.server.HandshakeRequest, javax.websocket.HandshakeResponse) JSR 356 Specification - 3.1.5 Handshake Modification I doesn't particularly targets the rejection of the connection. The latter is defined in http://tools.ietf.org/html/rfc6455#section-1.6 Security Model. which simply uses the origin mechanism. The status code of the response when connection should be dropped is 403 Forbidden defined by http://tools.ietf.org/html/rfc6455#section-4.2.2 which is in relation to origin check. The implementation in Tomcat calls checkOrigin either on the default configurator or on a custom supplied one. Take a look at org.apache.tomcat.websocket.server.UpgradeUtil doUpgrade method cheers Niki - 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: JspTagException- Stream closed
where is the iter attribute declaration for selection HTML tag?
http://www.w3schools.com/tags/tag_select.asp
Martin
__
Verzicht und Vertraulichkeitanmerkung
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung.
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung
fuer den Inhalt uebernehmen.
From: tinu.b...@amd.com
To: users@tomcat.apache.org
Subject: RE: JspTagException- Stream closed
Date: Thu, 5 Sep 2013 04:09:34 +
Here is the body of the method doEndTag(). The exception is thrown for line
number 146, which isthis.iter = null; of the reset method.
public int doEndTag()
throws JspException
{
if (this.jdField_bodyContent_of_type_JavaxServletJspTagextBodyContent !=
null)
{
try
{
this.jdField_bodyContent_of_type_JavaxServletJspTagextBodyContent.writeOut(this.jdField_bodyContent_of_type_JavaxServletJspTagextBodyContent.getEnclosingWriter());
}
catch (IOException localIOException)
{
this.jdField_pageContext_of_type_JavaxServletJspPageContext.getServletContext().log(Res.getString(4),
localIOException);
throw new JspTagException(localIOException.getMessage());
}
}
reset();
return 6;
}
private void reset()
{
this.sDataSource = null;
this.changeCurrentRow = true;
this.useRange = false;
this.ds = null;
this.rs = null;
this.iter = null;
}
-Original Message-
From: Babu, Tinu [mailto:tinu.b...@amd.com]
Sent: Monday, August 26, 2013 2:51 PM
To: Tomcat Users List
Subject: RE: JspTagException- Stream closed
The RowSetIterate tag is declared in the JSP itself. All the JSPs having this
RowSetIterate tag is throwing Stream closed exception.
-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Wednesday, August 21, 2013 9:41 PM
To: Tomcat Users List
Subject: Re: JspTagException- Stream closed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Tinu,
On 8/20/13 9:59 PM, Babu, Tinu wrote:
Here is the piece of codes which is throwing the error.
select name=list1 size=15 multiple jbo:RowsetIterate
datasource=userRole option value=jbo:ShowValue
datasource=userRole dataitem=RoleName / jbo:ShowValue
datasource=userRole dataitem=RoleDesc / /option
/jbo:RowsetIterate /select
select name=list2 size=15 multiple jbo:RowsetIterate
datasource=roles option value=jbo:ShowValue datasource=roles
dataitem=RoleName / jbo:ShowValue datasource=roles
dataitem=RoleDesc / /option /jbo:RowsetIterate /select
Exception is always being thrown from the RowSetIterate Tags in JSPs.
This was working properly with Tomcat4 version and when we upgraded
our Tomcat to version 6 we started getting this strange exception.
Please share your thoughts.
Where is the row set itself declared? In the JSP? In a servlet somewhere that
executes before the JSP?
In general, I wouldn't recommend making any JDBC calls from within a
JSP: I prefer to take care of all data acquisition in a servlet (or
similar) before delegating the creation of a response to the view layer. But
that's just me.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJSFMNUAAoJEBzwKT+lPKRYRDUQAMs3ugmVpr/K0kGMRIV2xHvG
cb7Kd2uWrvAnFLqgbj6GuMFQvWsTXcbA3tlaa+iY3FSQEchFnzktONVdqml6CGsB
UdumVqg0GFPI9vPM7nq4EOxTZg6QlaVsy2LJ0hbmc4vFaYD6s4uz21yd2IMZ8MJy
FjGx6JylFn1c9RjLBegWRWUS3ykkapaZ8lwJU+QUnI1WxLp8mg37FV7ziwKIk5u5
yKc1nquQ/cj2aqUiEdpC2CEwmy05m2APiDmGT/UkKuZoHMRG1/OzLFlKg65RhlvB
x0iPSDZv6iP/neZEtGmOsYiQLG9F5/v4ziV+kgsJYbhmb6jtYIYiHcBYrn425Q2W
ERhqEuYRXR+2yRxt3/xzB0uSyg3eikhfwNoOrFH2OGgk4cpzSZJRW/E0N2EUYUwr
ZRuGpOr4wgpPOrJ3A02hGYpBz2ZtbiingTl/72IlLcgBnBUapWzSazPl4BE7gPe/
VToMDtlxm74qiqtvr8C8swGAK9Y2xwmFkFI2GF2tu7STgbDfIA7f8eILYo3+m57S
3oI/O4aVf38HiKuA5pZmahSU5mLtCi4Fj0RmzDSSwLgi0WYfgUzCsqKDJKFns2qe
PRNEyA8w7X4IKI4oJKgP/C7+gl3g8xycEo2C04Q6ZlZHjqfSBqJi6KnxJfdZLoYt
t18eSlW8KZBzKKHP7QpT
=011K
-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
-
To
RE: Does JSR-356 provide a way for a client to pass security info on connect?
-Original Message- From: Niki Dokovski [mailto:nick...@gmail.com] Sent: Thursday, September 05, 2013 7:22 AM To: Tomcat Users List Subject: Re: Does JSR-356 provide a way for a client to pass security info on connect? On Thu, Sep 5, 2013 at 8:48 AM, Niki Dokovski nick...@gmail.com wrote: On Thu, Sep 5, 2013 at 12:44 AM, Bob DeRemer bob.dere...@thingworx.comwrote: -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: Wednesday, September 04, 2013 3:59 PM To: Tomcat Users List Subject: Re: Does JSR-356 provide a way for a client to pass security info on connect? Bob DeRemer wrote: I'm curious if there's anything defined in JSR-356 to enable a client to pass some security claims in the connect that would allow me to perform an auth check - prior to actually establishing the websocket connection. In an attempt to avoid a websocket DOS, I'm looking to see whether we can do an auth check in the ServerEndpoint onOpen (or, possibly at an earlier stage) - before the actual websocket gets established. I know we can do this at the application level in the onMessage, but it'd be good to handle this before setting up the actual websocket if possible. From a not really websocket specialist : As I recall, a websocket link starts with a normal HTTP request, which then gets upgraded to a websocket connection. So it should be possible to do AAA at the initial HTTP stage, no ? From an earlier thread a couple of weeks (?) ago, it seems however difficult to retrieve some of that HTTP-level information later, when the websocket connection is established. Exactly what I am hoping to do: the WebSocket spec outlines the HTTP Upgrade handshake process. During this handshake, a client should be able to send additional HTTP headers for this exact purpose (i.e. cookies, auth tokens, etc.). The server-side just needs an application-level hook that can be called that can effectively link into the pipeline - allowing/rejecting the establishment of the connection. So, the big question(s): 1) does the tomcat client-side JSR impl provide a way to pass HTTP headers in the initial upgrade handshake Yes background http://docs.oracle.com/javaee/7/api/javax/websocket/ClientEndpointConf ig.Configurator.html#beforeRequest(java.util.Map) There is a mutuable headers map. 2) does the tomcat server-side JSR impl provide a way to hook into the upgrade handshake and effectively allow/reject the connection Yes and (need to check further :)) background http://docs.oracle.com/javaee/7/api/javax/websocket/server/ServerEndpo intConfig.Configurator.html#modifyHandshake(javax.websocket.server.Ser verEndpointConfig, javax.websocket.server.HandshakeRequest, javax.websocket.HandshakeResponse) JSR 356 Specification - 3.1.5 Handshake Modification I doesn't particularly targets the rejection of the connection. The latter is defined in http://tools.ietf.org/html/rfc6455#section-1.6 Security Model. which simply uses the origin mechanism. The status code of the response when connection should be dropped is 403 Forbidden defined by http://tools.ietf.org/html/rfc6455#section-4.2.2 which is in relation to origin check. The implementation in Tomcat calls checkOrigin either on the default configurator or on a custom supplied one. Take a look at org.apache.tomcat.websocket.server.UpgradeUtil doUpgrade method Awesome - I'll start looking into this today! -thx, bob cheers Niki --- -- 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Does JSR-356 provide a way for a client to pass security info on connect?
Bob DeRemer wrote: -Original Message- From: Niki Dokovski [mailto:nick...@gmail.com] Sent: Thursday, September 05, 2013 7:22 AM To: Tomcat Users List Subject: Re: Does JSR-356 provide a way for a client to pass security info on connect? On Thu, Sep 5, 2013 at 8:48 AM, Niki Dokovski nick...@gmail.com wrote: On Thu, Sep 5, 2013 at 12:44 AM, Bob DeRemer bob.dere...@thingworx.comwrote: -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: Wednesday, September 04, 2013 3:59 PM To: Tomcat Users List Subject: Re: Does JSR-356 provide a way for a client to pass security info on connect? Bob DeRemer wrote: I'm curious if there's anything defined in JSR-356 to enable a client to pass some security claims in the connect that would allow me to perform an auth check - prior to actually establishing the websocket connection. In an attempt to avoid a websocket DOS, I'm looking to see whether we can do an auth check in the ServerEndpoint onOpen (or, possibly at an earlier stage) - before the actual websocket gets established. I know we can do this at the application level in the onMessage, but it'd be good to handle this before setting up the actual websocket if possible. From a not really websocket specialist : As I recall, a websocket link starts with a normal HTTP request, which then gets upgraded to a websocket connection. So it should be possible to do AAA at the initial HTTP stage, no ? From an earlier thread a couple of weeks (?) ago, it seems however difficult to retrieve some of that HTTP-level information later, when the websocket connection is established. Exactly what I am hoping to do: the WebSocket spec outlines the HTTP Upgrade handshake process. During this handshake, a client should be able to send additional HTTP headers for this exact purpose (i.e. cookies, auth tokens, etc.). The server-side just needs an application-level hook that can be called that can effectively link into the pipeline - allowing/rejecting the establishment of the connection. So, the big question(s): 1) does the tomcat client-side JSR impl provide a way to pass HTTP headers in the initial upgrade handshake Yes background http://docs.oracle.com/javaee/7/api/javax/websocket/ClientEndpointConf ig.Configurator.html#beforeRequest(java.util.Map) There is a mutuable headers map. 2) does the tomcat server-side JSR impl provide a way to hook into the upgrade handshake and effectively allow/reject the connection Yes and (need to check further :)) background http://docs.oracle.com/javaee/7/api/javax/websocket/server/ServerEndpo intConfig.Configurator.html#modifyHandshake(javax.websocket.server.Ser verEndpointConfig, javax.websocket.server.HandshakeRequest, javax.websocket.HandshakeResponse) JSR 356 Specification - 3.1.5 Handshake Modification I doesn't particularly targets the rejection of the connection. The latter is defined in http://tools.ietf.org/html/rfc6455#section-1.6 Security Model. which simply uses the origin mechanism. The status code of the response when connection should be dropped is 403 Forbidden defined by http://tools.ietf.org/html/rfc6455#section-4.2.2 which is in relation to origin check. The implementation in Tomcat calls checkOrigin either on the default configurator or on a custom supplied one. Take a look at org.apache.tomcat.websocket.server.UpgradeUtil doUpgrade method Awesome - I'll start looking into this today! -thx, bob And when you have done and solved the problem, would you be nice and post some summary on the list as a conclusion to this thread ? This way other people who would encounter the same issue later may find some useful pointers to the solution. (Or even better, write an article for the Tomcat WiKi) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat session replication with static membership
To answer my own questions:
On 04/09/2013 14:18, Willem Fibbe wrote:
...
Now I was wondering 2 things:
- if a Tomcat node restarts, will it be possible that it is trying to receive
sessions from itself, rather than one or more of the other nodes? Or: should
I configure a different server.xml on each node (its own member left out)?
I have setup a small cluster-group for testing (just quick testing) and have
seen a Tomcat node starting up,
replicating sessions from its own. Therefore, all our nodes now have a
different server.xml where its own node is
removed.
- if I start Tomcat, I see in catalina.out:
WARNING:
[SetPropertiesRule]{Server/Service/Engine/Cluster/Channel/Interceptor/Member}
Setting property 'uniqueId' to '{10,0,10,227}' did not find a matching
property.
- I removed uniqueId-attribute, but will this cause any possible
problems?
So far, we have't seen any problems, although in catalina.out I see each server
with the same id:
INFO: Replication member
added:org.apache.catalina.tribes.membership.MemberImpl[tcp://hostname01.domain.nl:5678,hostname01.domain.nl,5678,
alive=0,id={0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 }, payload={}, command={},
domain={112 117 98 108 105 115 104 45 99 ...(15)}, ]
INFO: Replication member
added:org.apache.catalina.tribes.membership.MemberImpl[tcp://hostname02.domain.nl:5678,hostname02.domain.nl,5678,
alive=0,id={0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 }, payload={}, command={},
domain={112 117 98 108 105 115 104 45 99 ...(15)}, ]
Sessions seem te be replicating just fine though.
Willem
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JspTagException- Stream closed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Babu,
On 9/5/13 12:09 AM, Babu, Tinu wrote:
Here is the body of the method doEndTag(). The exception is thrown
for line number 146, which is this.iter = null; of the reset
method.
public int doEndTag() throws JspException { if
(this.jdField_bodyContent_of_type_JavaxServletJspTagextBodyContent
!= null) { try {
this.jdField_bodyContent_of_type_JavaxServletJspTagextBodyContent.writeOut(this.jdField_bodyContent_of_type_JavaxServletJspTagextBodyContent.getEnclosingWriter());
}
catch (IOException localIOException) {
this.jdField_pageContext_of_type_JavaxServletJspPageContext.getServletContext().log(Res.getString(4),
localIOException); throw new
JspTagException(localIOException.getMessage()); } }
reset();
return 6; }
private void reset() { this.sDataSource = null;
this.changeCurrentRow = true; this.useRange = false; this.ds =
null; this.rs = null; this.iter = null; }
I'll eat my hat if this.iter = null; is throwing a JspTagException
(especially one whose stack trace does not include the reset
method). I think you are looking at source code that does not match
the exception stack trace you are seeing.
You should be seeing another stack trace (in the application log,
according to the source I see above) that includes full details of the
IOException that is being caught and re-thrown as a JspTagException --
without including the cause when creating the new exception. Bad
Oracle! Bad!
If you find that exception, it might give you better information about
why it's happening in the first place.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJSKL7gAAoJEBzwKT+lPKRYu2AQAJypAp+njffwNgQnTfG3vgQv
1V7hauPzcVAtgHLYDGxaOl12/yXNOZ4Mhz15JsOWQxYPCXjWBsvtWEmhjVOK8AcE
kQZWV7AAvc/4Tg+SSHgjgJNSAD0geSyD3w7x5DwAanE6qdHa42mW8+W/jj+ru9aC
mJHztYIYhl35EMoVJAhRhvAXLqazcr/TQPdSvui6meXLcYAdvioNOq1e+WstCay/
eoBBfcv1Tod1vJKd6jvGCx6ljjyJnk+/0+y+O3UaE2a3lSTJym1GveGgTzwerJN6
WarE2q3rXP/GqfiwZxVj9XqyKC+2yfJSBCSoxQCGWX5wLnosXVKEU0GMFNpBjlEr
mVnpWf7CuYFEnQ/xUfrT7fawepP1dPBszozJlwmVM0UAA+jIeJs86n1o8s7LJXqN
+I47Ymo4mFODpXuPrgI+ijn+HSxFm6urckHOJRdEbTyMmPw6eGzKOMVua4GTGC96
U1nlS0yqm4G7AgJVqxs8I5aQ4zXxg08g9k39YUH5Rrs6tCoLX56pzQZO35bEyMn/
Rlx9Cb0Mu8LSsSyGQrscYLe5Lh4A5fW4WKiIahkgTwdiRGQY6YXWHGK7TAbHM8DT
xy7DwdF/GS9Enqq6nRWeMQyyAxG9q4dHxU5+Cf5HJDPIgnfGdUcshODK9I3mptQb
rUfqatQh5TYRwLBtlDAQ
=T0VJ
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Does JSR-356 provide a way for a client to pass security info on connect?
-Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: Thursday, September 05, 2013 10:04 AM To: Tomcat Users List Subject: Re: Does JSR-356 provide a way for a client to pass security info on connect? Bob DeRemer wrote: -Original Message- From: Niki Dokovski [mailto:nick...@gmail.com] Sent: Thursday, September 05, 2013 7:22 AM To: Tomcat Users List Subject: Re: Does JSR-356 provide a way for a client to pass security info on connect? On Thu, Sep 5, 2013 at 8:48 AM, Niki Dokovski nick...@gmail.com wrote: On Thu, Sep 5, 2013 at 12:44 AM, Bob DeRemer bob.dere...@thingworx.comwrote: -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: Wednesday, September 04, 2013 3:59 PM To: Tomcat Users List Subject: Re: Does JSR-356 provide a way for a client to pass security info on connect? Bob DeRemer wrote: I'm curious if there's anything defined in JSR-356 to enable a client to pass some security claims in the connect that would allow me to perform an auth check - prior to actually establishing the websocket connection. In an attempt to avoid a websocket DOS, I'm looking to see whether we can do an auth check in the ServerEndpoint onOpen (or, possibly at an earlier stage) - before the actual websocket gets established. I know we can do this at the application level in the onMessage, but it'd be good to handle this before setting up the actual websocket if possible. From a not really websocket specialist : As I recall, a websocket link starts with a normal HTTP request, which then gets upgraded to a websocket connection. So it should be possible to do AAA at the initial HTTP stage, no ? From an earlier thread a couple of weeks (?) ago, it seems however difficult to retrieve some of that HTTP-level information later, when the websocket connection is established. Exactly what I am hoping to do: the WebSocket spec outlines the HTTP Upgrade handshake process. During this handshake, a client should be able to send additional HTTP headers for this exact purpose (i.e. cookies, auth tokens, etc.). The server-side just needs an application-level hook that can be called that can effectively link into the pipeline - allowing/rejecting the establishment of the connection. So, the big question(s): 1) does the tomcat client-side JSR impl provide a way to pass HTTP headers in the initial upgrade handshake Yes background http://docs.oracle.com/javaee/7/api/javax/websocket/ClientEndpointCo nf ig.Configurator.html#beforeRequest(java.util.Map) There is a mutuable headers map. 2) does the tomcat server-side JSR impl provide a way to hook into the upgrade handshake and effectively allow/reject the connection Yes and (need to check further :)) background http://docs.oracle.com/javaee/7/api/javax/websocket/server/ServerEnd po intConfig.Configurator.html#modifyHandshake(javax.websocket.server.S er verEndpointConfig, javax.websocket.server.HandshakeRequest, javax.websocket.HandshakeResponse) JSR 356 Specification - 3.1.5 Handshake Modification I doesn't particularly targets the rejection of the connection. The latter is defined in http://tools.ietf.org/html/rfc6455#section-1.6 Security Model. which simply uses the origin mechanism. The status code of the response when connection should be dropped is 403 Forbidden defined by http://tools.ietf.org/html/rfc6455#section-4.2.2 which is in relation to origin check. The implementation in Tomcat calls checkOrigin either on the default configurator or on a custom supplied one. Take a look at org.apache.tomcat.websocket.server.UpgradeUtil doUpgrade method Awesome - I'll start looking into this today! -thx, bob And when you have done and solved the problem, would you be nice and post some summary on the list as a conclusion to this thread ? This way other people who would encounter the same issue later may find some useful pointers to the solution. (Or even better, write an article for the Tomcat WiKi) Absolutely, would love to! - 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: Does JSR-356 provide a way for a client to pass security info on connect?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Bob, On 9/5/13 12:32 PM, Bob DeRemer wrote: -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: Thursday, September 05, 2013 10:04 AM To: Tomcat Users List Subject: Re: Does JSR-356 provide a way for a client to pass security info on connect? And when you have done and solved the problem, would you be nice and post some summary on the list as a conclusion to this thread ? This way other people who would encounter the same issue later may find some useful pointers to the solution. (Or even better, write an article for the Tomcat WiKi) Absolutely, would love to! Or, come to this fall's Apache Bar Camp* in Washington, DC and give an informal presentation on your exploits with Websocket in Tomcat 7. - -chris * Details to follow. The organizers (I'm one) are meeting this evening for beers, so you know we'll get something accomplished. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSKMBQAAoJEBzwKT+lPKRYWUMP/igIgZyN2xZsw8WghisyLdqI 57KvNQTcw2A5RWZIurhCIFuGljDv6E3oWFC/nGAUTY9m74UObBtQsRjlXK/pTrC0 h3o9txPhPINoKj6CLUpYI2GvDKUW1yR9TRzpJYUoCsVW/YYnp5nsdek3SI4+7Ua9 I4WsnuRwayfZEWSgP7Rn4q8AmQanBFyHmdWgXmpN9n7IQG8hX9tqCSkkhPfJG97X a5vVxqKgBh3MFYW1SpnvFn7uCkCY7shfED2BJhruWVZgnaQAVn/I7dVWCj8Xzrgg YObM//PGyNceh9wzDU4bwHz9tYQ+XKruMLW7c7yneRgLsKisNc1+orM12zMLpC9f Ap+U8zX7Yi7CgQXvdTOkPjrYddEzJL75pNLhj0AfZMTr3XCeVBfmpRAY5dcwd+qq +gEKscff9od2koLG3LLSBwps4LVjnfYHPCNkQ+qhKc5DpKKpMmIQOSidTwFnY817 TJU3/SgXR81y/HdR4NqoLL9N98KqRDlkpZVsXn9NpWQEbazx2875C6CFDmW/8W6H BPPR7SR+6/hp15AqFmyOKyOgISdeaReMlhvAFtjxKIy38xmb39bXfJqN17ZPDr2x jx3tGD+GRQ0odDblaipp1IwjCW47XXE65gO6Y3p4KydaxtUrcr7P0iQ2/HO9B4Wl KigIasG+QYOKqqMw9fWV =u0iB -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: 7.0.42 - tomcat-juli.jar not found on classpath
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mike, On 9/5/13 1:57 PM, Mike Abernethy wrote: I'm not clear on what you're specifying. First you suggest that there shouldn't be a file tomcat7/bin/service.bat but then later cut text from it. The file exists on the 7.0.42.zip that I have on my laptop and on my server. - From a freshly-downloaded apache-tomcat-7.0.42.zip file: $ ls -l apache-tomcat-7.0.42/bin/ total 1392 - -rw-r--r-- 1 chris staff 28616 Jul 2 08:59 bootstrap.jar - -rw-r--r-- 1 chris staff2168 Jul 2 08:59 catalina-tasks.xml - -rw-r--r-- 1 chris staff 13217 Jul 2 08:59 catalina.bat - -rw-r--r-- 1 chris staff 19877 Jul 2 08:59 catalina.sh - -rw-r--r-- 1 chris staff 204944 Jul 2 08:59 commons-daemon-native.tar.gz - -rw-r--r-- 1 chris staff 24283 Jul 2 08:59 commons-daemon.jar - -rw-r--r-- 1 chris staff2131 Jul 2 08:59 configtest.bat - -rw-r--r-- 1 chris staff1982 Jul 2 08:59 configtest.sh - -rw-r--r-- 1 chris staff1342 Jul 2 08:59 cpappend.bat - -rw-r--r-- 1 chris staff7492 Jul 2 08:59 daemon.sh - -rw-r--r-- 1 chris staff2178 Jul 2 08:59 digest.bat - -rw-r--r-- 1 chris staff2021 Jul 2 08:59 digest.sh - -rw-r--r-- 1 chris staff3264 Jul 2 08:59 setclasspath.bat - -rw-r--r-- 1 chris staff3524 Jul 2 08:59 setclasspath.sh - -rw-r--r-- 1 chris staff2111 Jul 2 08:59 shutdown.bat - -rw-r--r-- 1 chris staff1960 Jul 2 08:59 shutdown.sh - -rw-r--r-- 1 chris staff2112 Jul 2 08:59 startup.bat - -rw-r--r-- 1 chris staff1961 Jul 2 08:59 startup.sh - -rw-r--r-- 1 chris staff 38333 Jul 2 08:59 tomcat-juli.jar - -rw-r--r-- 1 chris staff 288166 Jul 2 08:59 tomcat-native.tar.gz - -rw-r--r-- 1 chris staff4114 Jul 2 08:59 tool-wrapper.bat - -rw-r--r-- 1 chris staff5086 Jul 2 08:59 tool-wrapper.sh - -rw-r--r-- 1 chris staff2116 Jul 2 08:59 version.bat - -rw-r--r-- 1 chris staff1965 Jul 2 08:59 version.sh I don't see service.bat in there. The file I am referencing is in subversion. I suspect it gets packaged-up with the .exe installer -- the one that ships with tomcat7w.exe, etc. in the bin/ directory as well. You said you used the ZIP distribution, so I looked there. Not seeing that file made me suspect something was awry. Here is the line from that file that I was looking at to properly set the classpath for tomcat-juli.jar. It seems to match what you pasted set PR_CLASSPATH=%CATALINA_HOME%\bin\bootstrap.jar;%CATALINA_BASE%\bin\tomcat-juli.jar;%CATALINA_HOME%\bin\tomcat-juli.jar Try checking file permissions? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSKNDrAAoJEBzwKT+lPKRYbNoP/1dagXvQP8aoWROvClT+PHm+ zOg53E6G0I2Lp/zOXgVoxMpskGqFiA9V/Q8QNMjLzqoq53NAUzQgCM6HrW9jaqZQ RBBqDHEoq60MsJM+8CAO5o61Q2Ydp/z7DUtO2fSkh/aB1F8nF5PyDfMWfE6gNql2 zN+Vdy2VTlbmYzqIqazfExITkVtUiPmjv1rDQ8gALA4ydhA0JVGfPuaigQCfJyQc XNuNz7wuSQo3EIi/LXt/0DveimQBUGauniHAeaCTMlb1biX++0kL7RZHwAXdrswt tXV/hgJRdtpRSrl1qIltGFwQPdO7Y1RO5ZDJBhMDEDjOy0W5A+KO9c4l3g1gYACh IfSb7HzGmeh0dV8VXd+tc2xODb1knzYWrLzv1wO0xIStH3Aaqo8O6VtWHdilJEmJ JNXhGzVTFudj2Rb1l3gDWUsC9p5trGrexFsjJQkcXeXtiyir8Pgiq64JX4YHm0Ts 5Ph80Sv+2W4W5xFSa7G3tLXSZhjS/Q3AfCzNtViFpV3/VecAn736m2n37OQH+2vi aZTdxsGDhIpDXKMiY1zUnuwQWXLfFy0EJOlT4QZtCEu0nfJt5ws0z8j0zxG3HxxH uZNLrsoR9KlJel1nvIm/KLULKXTUgBNUE5Nr1g6e7QpAI6O56IL/yziqWnx5TnND Fk3NguBJ3epKbUn33f63 =aAam -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: 7.0.42 - tomcat-juli.jar not found on classpath
I downloaded this file again and it's in the bin directory. 64-bit Windows zip - Original Message - From: Christopher Schultz ch...@christopherschultz.net To: Tomcat Users List users@tomcat.apache.org Cc: Sent: Thursday, September 5, 2013 1:43 PM Subject: Re: 7.0.42 - tomcat-juli.jar not found on classpath -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mike, On 9/5/13 1:57 PM, Mike Abernethy wrote: I'm not clear on what you're specifying. First you suggest that there shouldn't be a file tomcat7/bin/service.bat but then later cut text from it. The file exists on the 7.0.42.zip that I have on my laptop and on my server. - From a freshly-downloaded apache-tomcat-7.0.42.zip file: $ ls -l apache-tomcat-7.0.42/bin/ total 1392 - -rw-r--r-- 1 chris staff 28616 Jul 2 08:59 bootstrap.jar - -rw-r--r-- 1 chris staff 2168 Jul 2 08:59 catalina-tasks.xml - -rw-r--r-- 1 chris staff 13217 Jul 2 08:59 catalina.bat - -rw-r--r-- 1 chris staff 19877 Jul 2 08:59 catalina.sh - -rw-r--r-- 1 chris staff 204944 Jul 2 08:59 commons-daemon-native.tar.gz - -rw-r--r-- 1 chris staff 24283 Jul 2 08:59 commons-daemon.jar - -rw-r--r-- 1 chris staff 2131 Jul 2 08:59 configtest.bat - -rw-r--r-- 1 chris staff 1982 Jul 2 08:59 configtest.sh - -rw-r--r-- 1 chris staff 1342 Jul 2 08:59 cpappend.bat - -rw-r--r-- 1 chris staff 7492 Jul 2 08:59 daemon.sh - -rw-r--r-- 1 chris staff 2178 Jul 2 08:59 digest.bat - -rw-r--r-- 1 chris staff 2021 Jul 2 08:59 digest.sh - -rw-r--r-- 1 chris staff 3264 Jul 2 08:59 setclasspath.bat - -rw-r--r-- 1 chris staff 3524 Jul 2 08:59 setclasspath.sh - -rw-r--r-- 1 chris staff 2111 Jul 2 08:59 shutdown.bat - -rw-r--r-- 1 chris staff 1960 Jul 2 08:59 shutdown.sh - -rw-r--r-- 1 chris staff 2112 Jul 2 08:59 startup.bat - -rw-r--r-- 1 chris staff 1961 Jul 2 08:59 startup.sh - -rw-r--r-- 1 chris staff 38333 Jul 2 08:59 tomcat-juli.jar - -rw-r--r-- 1 chris staff 288166 Jul 2 08:59 tomcat-native.tar.gz - -rw-r--r-- 1 chris staff 4114 Jul 2 08:59 tool-wrapper.bat - -rw-r--r-- 1 chris staff 5086 Jul 2 08:59 tool-wrapper.sh - -rw-r--r-- 1 chris staff 2116 Jul 2 08:59 version.bat - -rw-r--r-- 1 chris staff 1965 Jul 2 08:59 version.sh I don't see service.bat in there. The file I am referencing is in subversion. I suspect it gets packaged-up with the .exe installer -- the one that ships with tomcat7w.exe, etc. in the bin/ directory as well. You said you used the ZIP distribution, so I looked there. Not seeing that file made me suspect something was awry. Here is the line from that file that I was looking at to properly set the classpath for tomcat-juli.jar. It seems to match what you pasted set PR_CLASSPATH=%CATALINA_HOME%\bin\bootstrap.jar;%CATALINA_BASE%\bin\tomcat-juli.jar;%CATALINA_HOME%\bin\tomcat-juli.jar Try checking file permissions? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSKNDrAAoJEBzwKT+lPKRYbNoP/1dagXvQP8aoWROvClT+PHm+ zOg53E6G0I2Lp/zOXgVoxMpskGqFiA9V/Q8QNMjLzqoq53NAUzQgCM6HrW9jaqZQ RBBqDHEoq60MsJM+8CAO5o61Q2Ydp/z7DUtO2fSkh/aB1F8nF5PyDfMWfE6gNql2 zN+Vdy2VTlbmYzqIqazfExITkVtUiPmjv1rDQ8gALA4ydhA0JVGfPuaigQCfJyQc XNuNz7wuSQo3EIi/LXt/0DveimQBUGauniHAeaCTMlb1biX++0kL7RZHwAXdrswt tXV/hgJRdtpRSrl1qIltGFwQPdO7Y1RO5ZDJBhMDEDjOy0W5A+KO9c4l3g1gYACh IfSb7HzGmeh0dV8VXd+tc2xODb1knzYWrLzv1wO0xIStH3Aaqo8O6VtWHdilJEmJ JNXhGzVTFudj2Rb1l3gDWUsC9p5trGrexFsjJQkcXeXtiyir8Pgiq64JX4YHm0Ts 5Ph80Sv+2W4W5xFSa7G3tLXSZhjS/Q3AfCzNtViFpV3/VecAn736m2n37OQH+2vi aZTdxsGDhIpDXKMiY1zUnuwQWXLfFy0EJOlT4QZtCEu0nfJt5ws0z8j0zxG3HxxH uZNLrsoR9KlJel1nvIm/KLULKXTUgBNUE5Nr1g6e7QpAI6O56IL/yziqWnx5TnND Fk3NguBJ3epKbUn33f63 =aAam -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: 7.0.42 - tomcat-juli.jar not found on classpath
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mike, On 9/4/13 4:42 PM, Mike Abernethy wrote: I installed Tomcat 7.0.42 on my Windows 2008 server. I have Tomcat 6 installed already and host multiple instances of tomcat in separate folders. I repeated this same process for Tomcat 7. 1. Installed java1.7 2. Unzipped the .zip 64-bit tomcat file into a folder C:\tomcat7 3. Created a new instance folder called C:\tomcat-instances\project I registered the tomcat instance as a service in Windows with the following arguments in a .bat file (this works fine for Tomcat 6) set SERVICE_NAME=project set CATALINA_HOME=C:\tomcat7 set JAVA_HOME=C:\java1.7 set CATALINA_BASE=%cd% call C:\tomcat7\bin\service.bat install %SERVICE_NAME% Where did you get bin\service.bat? I just downloaded the 7.0.42 .zip file and it does not include this script. (It's not in the .tar.gz bundle, either, which I already had). Did you take it from Tomcat 6? If so, this might be a Tomcat 6 problem that you have make into a Tomcat 7 problems. However, when I start the service in Windows, it fails with the following error message WARNING: Failed to scan [file:/C:/tomcat-instances/project/bin/tomcat-juli.jar] from classloader hierarchy java.io.FileNotFoundException: C:\tomcat-instances\project\bin\tomcat-juli.jar (The system cannot find the path specified) at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.init(ZipFile.java:214) Looking into the service.bat file, it looks like the CLASSPATH is supposed to be looking in CATALINA_BASE\bin and then CATALINA_HOME\bin for the tomcat-juli.jar, but it appears that it is not doing this. It appears to be only looking in CATALINA_BASE\bin and failing. Line 134 of the bin/service.bat you can find in the SVN tree[1] has this to say: set PR_CLASSPATH=%CATALINA_HOME%\bin\bootstrap.jar;%CATALINA_BASE%\bin\tomcat-juli.jar;%CATALINA_HOME%\bin\tomcat-juli.jar So, Tomcat 7 definitely looks like it's looking in both CATALINA_BASE and CATALINA_HOME (in that order). If you *are* using the Tomcat 7 service.bat file, then perhaps you have a file permissions issue: is LOCAL SERVICE (or whomever local services run as on your version of Windows) allowed to read that path? - -chris [1] http://svn.apache.org/viewvc/tomcat/tc7.0.x/tags/TOMCAT_7_0_42/bin/service.bat?view=markup -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSKMJ6AAoJEBzwKT+lPKRYzt8P+weRBp+1u7mKXVtQSaXXcdQf 5AGZ4GwOXhhXMZZfHiImAqUygogd8QVEZ4mIKwexAdiOGj38yNVZnAi42GRVC+Wc O1HRHgC+D12ullg7/py7iHot0QQUEqtu77tSwfbUCue/xWan+u3wnUuRUmZDfZp9 eSBei7M/rbNcsPKIKPmvj4PXo1Q3h8RGBmXUKl/IBqj3aTNHuifLamf7pAPauS+q GRiKJjFu4tpDal68tXZW43AmK9su1mgZu+YGl/cH9Dr9fMkKhDi5v/bGlRT4PB2X Bgf0hm06PaQyP2UA2V21el+N7B/Hco4LvzgnZ38PascppFiC9NKwp7X7GXZdxrG7 r2mSn9CHShZYQg3sArHCHDvNNkcvQp7IBpVXpV73iH2ULkm2VrwA23vK6RgZ4NQ+ Mu2Y+o9PBH0/5Adhj9ohzydih/fDaCTqAlLaDPqTIESdJX1ynkyvDHfsYuReRc43 /xrMt2Ct+zSBelSaAmt2kdWoXnyPPCZb3vab+mPztJbzBd3WVCkuw0IW1r7Uio3K SmIv/NFP359sGGBWP3/HP8aS9XzAP34SolP23H5mUiyjl7Qe7vj/WmyDl7nw0Zgo MnA2Ec6ydG8cGZIAPYvuPQs/UfLG0Bgf5R/luqd8PniGB8x9xJqzBtyPzN2zGwhV 0vfOfcW7+J7j7MevnYyo =RXA1 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Does JSR-356 provide a way for a client to pass security info on connect?
-Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Thursday, September 05, 2013 1:33 PM To: Tomcat Users List Subject: Re: Does JSR-356 provide a way for a client to pass security info on connect? -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Bob, On 9/5/13 12:32 PM, Bob DeRemer wrote: -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: Thursday, September 05, 2013 10:04 AM To: Tomcat Users List Subject: Re: Does JSR-356 provide a way for a client to pass security info on connect? And when you have done and solved the problem, would you be nice and post some summary on the list as a conclusion to this thread ? This way other people who would encounter the same issue later may find some useful pointers to the solution. (Or even better, write an article for the Tomcat WiKi) Absolutely, would love to! Or, come to this fall's Apache Bar Camp* in Washington, DC and give an informal presentation on your exploits with Websocket in Tomcat 7. Hi chris, That would be great. Once you know the WHEN and WHERE, let me know. If available, I'll definitely try to make it. I'm just up in PA, so that's only a 2 hr drive. Thx,bob - -chris * Details to follow. The organizers (I'm one) are meeting this evening for beers, so you know we'll get something accomplished. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSKMBQAAoJEBzwKT+lPKRYWUMP/igIgZyN2xZsw8WghisyLdq I 57KvNQTcw2A5RWZIurhCIFuGljDv6E3oWFC/nGAUTY9m74UObBtQsRjlXK/pTrC0 h3o9txPhPINoKj6CLUpYI2GvDKUW1yR9TRzpJYUoCsVW/YYnp5nsdek3SI4+7Ua9 I4WsnuRwayfZEWSgP7Rn4q8AmQanBFyHmdWgXmpN9n7IQG8hX9tqCSkkhPfJG 97X a5vVxqKgBh3MFYW1SpnvFn7uCkCY7shfED2BJhruWVZgnaQAVn/I7dVWCj8Xzrg g YObM//PGyNceh9wzDU4bwHz9tYQ+XKruMLW7c7yneRgLsKisNc1+orM12zMLpC 9f Ap+U8zX7Yi7CgQXvdTOkPjrYddEzJL75pNLhj0AfZMTr3XCeVBfmpRAY5dcwd+qq +gEKscff9od2koLG3LLSBwps4LVjnfYHPCNkQ+qhKc5DpKKpMmIQOSidTwFnY817 TJU3/SgXR81y/HdR4NqoLL9N98KqRDlkpZVsXn9NpWQEbazx2875C6CFDmW/8W 6H BPPR7SR+6/hp15AqFmyOKyOgISdeaReMlhvAFtjxKIy38xmb39bXfJqN17ZPDr2x jx3tGD+GRQ0odDblaipp1IwjCW47XXE65gO6Y3p4KydaxtUrcr7P0iQ2/HO9B4Wl KigIasG+QYOKqqMw9fWV =u0iB -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
(7.0.40) Seeing deadlock followed by maxThread usage using a Async Servlet AsyncContext.dispatch with BIO
I'm trying to determine if there are any known issues using an Async servlet with the default BIO connector in Tomcat 7.0.40 on windows server 2008. PROBLEM: We have a situation where we're occasionally getting a deadlock (according to Java Melody). When this happens, it's just a matter of time until all the threads in the connector's internal pool are exhausted because browser-based clients continue to make calls on this async servlet - effectively polling for work. QUESTION: I'm in the process of going through the stacks and code, but I'm not well versed in the async servlet code (which is mostly from the Vysper project), so I'm trying to figure out if the underlying AsyncContext.dispatch usage is a problem [at least when used with BIO]. Given the 3 stacks below, I'd greatly appreciate it if someone who understands the Async servlet plumbing might be able to take a quick look and see if anything stands out that could be the cause. If you need any additional information, please let me know. Thanks, Bob DEADLOCKED STACK INFORMATION Warning, the following threads are deadlocked : http-bio-192.168.230.133-443-exec-1329, http-bio-192.168.230.133-443-exec-685, http-bio-192.168.230.133-443-exec-687 http-bio-192.168.230.133-443-exec-685 daemon prio=5 BLOCKED org.apache.tomcat.util.net.JIoEndpoint.processSocketAsync(JIoEndpoint.java:556) org.apache.coyote.http11.Http11Processor.actionInternal(Http11Processor.java:365) org.apache.coyote.http11.AbstractHttp11Processor.action(AbstractHttp11Processor.java:848) org.apache.coyote.Request.action(Request.java:344) org.apache.catalina.core.AsyncContextImpl.dispatch(AsyncContextImpl.java:222) org.apache.catalina.core.AsyncContextImpl.dispatch(AsyncContextImpl.java:181) org.apache.catalina.core.AsyncContextImpl.dispatch(AsyncContextImpl.java:175) org.apache.vysper.xmpp.extension.xep0124.BoshBackedSessionContext.write0(BoshBackedSessionContext.java:251) org.apache.vysper.xmpp.extension.xep0124.BoshHandler.terminateSession(BoshHandler.java:237) org.apache.vysper.xmpp.extension.xep0124.BoshHandler.processSession(BoshHandler.java:228) org.apache.vysper.xmpp.extension.xep0124.BoshHandler.process(BoshHandler.java:192) org.apache.vysper.xmpp.extension.xep0124.BoshSaxContentHandler.emitStanza(BoshSaxContentHandler.java:90) org.apache.vysper.xmpp.extension.xep0124.BoshSaxContentHandler.endElement(BoshSaxContentHandler.java:78) org.apache.vysper.xml.sax.impl.XMLParser.endElement(XMLParser.java:480) org.apache.vysper.xml.sax.impl.XMLParser.token(XMLParser.java:227) org.apache.vysper.xml.sax.impl.XMLTokenizer.emit(XMLTokenizer.java:154) org.apache.vysper.xml.sax.impl.XMLTokenizer.parse(XMLTokenizer.java:108) org.apache.vysper.xml.sax.impl.XMLParser.parse(XMLParser.java:121) org.apache.vysper.xml.sax.impl.DefaultNonBlockingXMLReader.parse(DefaultNonBlockingXMLReader.java:185) org.apache.vysper.xmpp.extension.xep0124.BoshDecoder.decode(BoshDecoder.java:81) com.thingworx.xmpp.vysper.extensions.xep0124.ThingworxBoshServlet.doPost(ThingworxBoshServlet.java:176) javax.servlet.http.HttpServlet.service(HttpServlet.java:647) javax.servlet.http.HttpServlet.service(HttpServlet.java:728) org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:206) net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:179) org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) com.thingworx.security.filter.AuthenticationFilter.propagateRequest(AuthenticationFilter.java:279) com.thingworx.security.filter.AuthenticationFilter.doFilter(AuthenticationFilter.java:150) org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222) org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:581) org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99) org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953) org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
RE: 7.0.42 - tomcat-juli.jar not found on classpath
From: Christopher Schultz [mailto:ch...@christopherschultz.net] Subject: Re: 7.0.42 - tomcat-juli.jar not found on classpath - From a freshly-downloaded apache-tomcat-7.0.42.zip file: I don't see service.bat in there. This appears to be a regression specific to 7.0.42; all previous 7.0.x.zip files included bin/service.bat. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: 7.0.42 - tomcat-juli.jar not found on classpath
Chris, I'm not clear on what you're specifying. First you suggest that there shouldn't be a file tomcat7/bin/service.bat but then later cut text from it. The file exists on the 7.0.42.zip that I have on my laptop and on my server. Here is the line from that file that I was looking at to properly set the classpath for tomcat-juli.jar. It seems to match what you pasted set PR_CLASSPATH=%CATALINA_HOME%\bin\bootstrap.jar;%CATALINA_BASE%\bin\tomcat-juli.jar;%CATALINA_HOME%\bin\tomcat-juli.jar From: Christopher Schultz ch...@christopherschultz.net To: Tomcat Users List users@tomcat.apache.org Sent: Thursday, September 5, 2013 12:42 PM Subject: Re: 7.0.42 - tomcat-juli.jar not found on classpath -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mike, On 9/4/13 4:42 PM, Mike Abernethy wrote: I installed Tomcat 7.0.42 on my Windows 2008 server. I have Tomcat 6 installed already and host multiple instances of tomcat in separate folders. I repeated this same process for Tomcat 7. 1. Installed java1.7 2. Unzipped the .zip 64-bit tomcat file into a folder C:\tomcat7 3. Created a new instance folder called C:\tomcat-instances\project I registered the tomcat instance as a service in Windows with the following arguments in a .bat file (this works fine for Tomcat 6) set SERVICE_NAME=project set CATALINA_HOME=C:\tomcat7 set JAVA_HOME=C:\java1.7 set CATALINA_BASE=%cd% call C:\tomcat7\bin\service.bat install %SERVICE_NAME% Where did you get bin\service.bat? I just downloaded the 7.0.42 .zip file and it does not include this script. (It's not in the .tar.gz bundle, either, which I already had). Did you take it from Tomcat 6? If so, this might be a Tomcat 6 problem that you have make into a Tomcat 7 problems. However, when I start the service in Windows, it fails with the following error message WARNING: Failed to scan [file:/C:/tomcat-instances/project/bin/tomcat-juli.jar] from classloader hierarchy java.io.FileNotFoundException: C:\tomcat-instances\project\bin\tomcat-juli.jar (The system cannot find the path specified) at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.init(ZipFile.java:214) Looking into the service.bat file, it looks like the CLASSPATH is supposed to be looking in CATALINA_BASE\bin and then CATALINA_HOME\bin for the tomcat-juli.jar, but it appears that it is not doing this. It appears to be only looking in CATALINA_BASE\bin and failing. Line 134 of the bin/service.bat you can find in the SVN tree[1] has this to say: set PR_CLASSPATH=%CATALINA_HOME%\bin\bootstrap.jar;%CATALINA_BASE%\bin\tomcat-juli.jar;%CATALINA_HOME%\bin\tomcat-juli.jar So, Tomcat 7 definitely looks like it's looking in both CATALINA_BASE and CATALINA_HOME (in that order). If you *are* using the Tomcat 7 service.bat file, then perhaps you have a file permissions issue: is LOCAL SERVICE (or whomever local services run as on your version of Windows) allowed to read that path? - -chris [1] http://svn.apache.org/viewvc/tomcat/tc7.0.x/tags/TOMCAT_7_0_42/bin/service.bat?view=markup -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSKMJ6AAoJEBzwKT+lPKRYzt8P+weRBp+1u7mKXVtQSaXXcdQf 5AGZ4GwOXhhXMZZfHiImAqUygogd8QVEZ4mIKwexAdiOGj38yNVZnAi42GRVC+Wc O1HRHgC+D12ullg7/py7iHot0QQUEqtu77tSwfbUCue/xWan+u3wnUuRUmZDfZp9 eSBei7M/rbNcsPKIKPmvj4PXo1Q3h8RGBmXUKl/IBqj3aTNHuifLamf7pAPauS+q GRiKJjFu4tpDal68tXZW43AmK9su1mgZu+YGl/cH9Dr9fMkKhDi5v/bGlRT4PB2X Bgf0hm06PaQyP2UA2V21el+N7B/Hco4LvzgnZ38PascppFiC9NKwp7X7GXZdxrG7 r2mSn9CHShZYQg3sArHCHDvNNkcvQp7IBpVXpV73iH2ULkm2VrwA23vK6RgZ4NQ+ Mu2Y+o9PBH0/5Adhj9ohzydih/fDaCTqAlLaDPqTIESdJX1ynkyvDHfsYuReRc43 /xrMt2Ct+zSBelSaAmt2kdWoXnyPPCZb3vab+mPztJbzBd3WVCkuw0IW1r7Uio3K SmIv/NFP359sGGBWP3/HP8aS9XzAP34SolP23H5mUiyjl7Qe7vj/WmyDl7nw0Zgo MnA2Ec6ydG8cGZIAPYvuPQs/UfLG0Bgf5R/luqd8PniGB8x9xJqzBtyPzN2zGwhV 0vfOfcW7+J7j7MevnYyo =RXA1 -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: 7.0.42 - tomcat-juli.jar not found on classpath
From: Mike Abernethy [mailto:maberne...@yahoo.com] Subject: Re: 7.0.42 - tomcat-juli.jar not found on classpath I downloaded this file again and it's in the bin directory. 64-bit Windows zip It's not present in the plain .zip file since the service wrapper programs aren't included in the plain one. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat class loading with index.list - invalid jar index exception
All: I am facing an invalid jar index exception in both tomcat 5.5.x and 7.0.39 . After some investigation , we figured out this is because of class loading in tomcat which uses index.list file in jar files. I have two jars with same package names but classes in those package are different. Since the package name are defined or mentioned in the index.list file of every jar for some reason tomcat is showing me an invalid jar index exception even if try to load a simple index.jsp. Any suggestions to overcome this is greatly appreciated. Thanks !! Thanks and Regards, Sabari
JVM options (where to configure)
Hello, I would like to know where to place JVM HostSpot parameter flags in the Tomcat config files. I have read that a file named setenv.sh should be created in CATALINA_HOME/bin, and there you place the configs, yet I've also read that you simply place them in catalina.sh. Which is the preferred? Also I've seen configurations with JAVA_OPS and CATALINA_OPS. Which is the preferred there? OS: RHEL 5.5 Kernel: 2.6.18-194.8.1.el5 Apache Tomcat: 7.0.39 JDK: 1.6.0_45 Thank you -John - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JVM options (where to configure)
On 05/09/2013 22:55, John Beaulaurier -X (jbeaulau - ADVANCED NETWORK INFORMATION INC at Cisco) wrote: Hello, I would like to know where to place JVM HostSpot parameter flags in the Tomcat config files. I have read that a file named setenv.sh should be created in CATALINA_HOME/bin, and there you place the configs, yet I've also read that you simply place them in catalina.sh. Which is the preferred? setenv.[sh|bat] as appropriate for your platform. Also I've seen configurations with JAVA_OPS and CATALINA_OPS. Which is the preferred there? Generally, CATALINA_OPTS When Tomcat is stopped, a second process is created that creates a connection to the shutdown port of the main process and provides the shutdown command. CATALINA_OPTS applies only the main process JAVA_OPTS applies to both You are unlikely to want your memory settings (or any other settinsg for that matter) for the main process to be applied to the shutdown process. Therefore use CATALINA_OPTS. The comments in catalina.[sh|bat] cover this. Mark OS: RHEL 5.5 Kernel: 2.6.18-194.8.1.el5 Apache Tomcat: 7.0.39 JDK: 1.6.0_45 Thank you -John - 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: JVM options (where to configure)
On Thu, Sep 5, 2013 at 5:55 PM, John Beaulaurier -X (jbeaulau - ADVANCED NETWORK INFORMATION INC at Cisco) jbeau...@cisco.com wrote: Hello, I would like to know where to place JVM HostSpot parameter flags in the Tomcat config files. I have read that a file named setenv.sh should be created in CATALINA_HOME/bin, and there you place the configs, yet I've also read that you simply place them in catalina.sh. Which is the preferred? Also I've seen configurations with JAVA_OPS and CATALINA_OPS. Which is the preferred there? OS: RHEL 5.5 Kernel: 2.6.18-194.8.1.el5 Apache Tomcat: 7.0.39 JDK: 1.6.0_45 Hey John, My preferred way to use this is to create CATALINA_HOMEbin/setenv.sh (or CATALINA_BASE/bin/setenv.sh if you have multi-instance setup) and add JVM options to CATALINA_OPTS, rather than JAVA_OPTS. JAVA_OPTS is going to be used for shutdown script as well, not just startup. CATALINA_OPTS is going to be used for startup script only. I prefer setenv.sh route, because it provides clear separation of the product and configuration customizations. This is really handy when you do upgrades! Hope that helps! Cheers n.
Re: Tomcat class loading with index.list - invalid jar index exception
On 05/09/2013 22:00, Sabari Gandhi wrote: All: I am facing an invalid jar index exception in both tomcat 5.5.x and 7.0.39 . After some investigation , we figured out this is because of class loading in tomcat which uses index.list file in jar files. I have two jars with same package names but classes in those package are different. Since the package name are defined or mentioned in the index.list file of every jar for some reason tomcat is showing me an invalid jar index exception even if try to load a simple index.jsp. Any suggestions to overcome this is greatly appreciated. Thanks !! Your jar indexes are broken. They need to be re-generated for all the JAR files in in one go so that the package mappings are correct. The error you are seeing is from the JRE code, not from Tomcat. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
