RE: possible tomcat 7.0.47 jsr-356 bug: NULL pointer being thrown when DecodeException is caught in PojoMessageHandlerWholeBaseT.onMessage
Morning Bob-
session should never be null..this is a bug
create an account here
https://issues.apache.org/bugzilla/createaccount.cgi
and file the bug report
Many thanks for discovering this bug and helping us to improve the product
Martin
__
From: bob.dere...@thingworx.com
To: users@tomcat.apache.org
Subject: possible tomcat 7.0.47 jsr-356 bug: NULL pointer being thrown when
DecodeException is caught in PojoMessageHandlerWholeBaseT.onMessage
Date: Sat, 19 Oct 2013 12:46:05 +
I am testing what happens when Encode/Decode Exceptions occur during JSR-356
communication and found that in the following code in onMessage, the
((WsSession)session) is NULL. As a result, the actual DecodeException (cause)
is lost.
// Can this message be decoded?
Object payload;
try {
payload = decode(message);
} catch (DecodeException de) {
((WsSession) session).getLocal().onError(session, de);
return;
}
Tracing this further up the stack, I found that Util.getMessageHandlers is
initializing it and passing NULL in for the session:
if (decoderMatch.getTextDecoders().size() 0) {
MessageHandlerResult result = new MessageHandlerResult(
new PojoMessageHandlerWholeText(listener, m, null,
endpointConfig,
decoderMatch.getTextDecoders(), new Object[1],
0, false, -1, -1),
MessageHandlerResultType.TEXT);
results.add(result);
}
Is this a bug, or do I need to do something else to get this internal session
initialize - in addition to calling: addMessageHandler(this) in the onOpen of
my Endpoint-derived class?
Thanks,
Bob DeRemer
Senior Director, Architecture and Development
http://www.thingworx.com
Skype: bob.deremer.thingworx
O: 610.594.6200 x812
M: 717.881.3986
RE: possible tomcat 7.0.47 jsr-356 bug: NULL pointer being thrown when DecodeException is caught in PojoMessageHandlerWholeBaseT.onMessage
-Original Message-
From: Martin Gainty [mailto:mgai...@hotmail.com]
Sent: Sunday, October 20, 2013 8:22 AM
To: Tomcat Users List
Subject: RE: possible tomcat 7.0.47 jsr-356 bug: NULL pointer being thrown
when DecodeException is caught in
PojoMessageHandlerWholeBaseT.onMessage
Morning Bob-
session should never be null..this is a bug
create an account here
https://issues.apache.org/bugzilla/createaccount.cgi
and file the bug report
Bug report submitted
Thx, bob
Many thanks for discovering this bug and helping us to improve the product
Martin
__
From: bob.dere...@thingworx.com
To: users@tomcat.apache.org
Subject: possible tomcat 7.0.47 jsr-356 bug: NULL pointer being thrown when
DecodeException is caught in PojoMessageHandlerWholeBaseT.onMessage
Date: Sat, 19 Oct 2013 12:46:05 +
I am testing what happens when Encode/Decode Exceptions occur during JSR-
356 communication and found that in the following code in onMessage, the
((WsSession)session) is NULL. As a result, the actual DecodeException
(cause) is
lost.
// Can this message be decoded?
Object payload;
try {
payload = decode(message);
} catch (DecodeException de) {
((WsSession) session).getLocal().onError(session, de);
return;
}
Tracing this further up the stack, I found that Util.getMessageHandlers is
initializing it and passing NULL in for the session:
if (decoderMatch.getTextDecoders().size() 0) {
MessageHandlerResult result = new MessageHandlerResult(
new PojoMessageHandlerWholeText(listener, m, null,
endpointConfig,
decoderMatch.getTextDecoders(), new Object[1],
0, false, -1, -1),
MessageHandlerResultType.TEXT);
results.add(result);
}
Is this a bug, or do I need to do something else to get this internal session
initialize - in addition to calling: addMessageHandler(this) in the onOpen of
my
Endpoint-derived class?
Thanks,
Bob DeRemer
Senior Director, Architecture and Development
http://www.thingworx.com
Skype: bob.deremer.thingworx
O: 610.594.6200 x812
M: 717.881.3986
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: can't connect to manager application
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 All, On 10/20/13 2:44 PM, Christopher Schultz wrote: Edoardo, On 10/18/13 6:03 PM, Edoardo Panfili wrote: Il 17/10/13 18:45, Edoardo Panfili ha scritto: My Tomcat (7.0.42) is listening on port 7080 and I have this conf/tomcat-users.xml in (production server) --- tomcat-users role rolename=manager-script/ user username=myname password=pwd roles=manager-script,manager-gui,manager-jmx/ /tomcat-users -- if I use curl -u myname:pwd http://localhost:7080/manager/text/reload?path=/myApplication the response is-- h1404 Not found/h1 p The page you tried to access (/manager/text/reload) does not exist. /p p The Manager application has been re-structured for Tomcat 7 onwards and some of URLs have changed. All URLs used to access the Manager application should now start with one of the following options: /p ul li/manager/html for the HTML GUI/li li/manager/text for the text interface/li li/manager/jmxproxy for the JMX proxy/li li/manager/status for the status pages/li /ul p Note that the URL for the text interface has changed from quot;/managerquot; to quot;/manager/textquot;. /p p You probably need to adjust the URL you are using to access the Manager application. However, there is always a chance you have found a bug in the Manager application. If you are sure you have found a bug, and that the bug has not already been reported, please report it to the Apache Tomcat team. /p - Installation step by step: Unpack new download from tomcat.apache.org 1- set users tomcat-users user username=edoardo password=pwd roles=manager-script,manager-gui,manager-jmx,other/ /tomcat-users then reload tomcat $curl -u edoardo:pwd http://localhost:8080/manager/text/reload?path=/examples OK - Reloaded application at context path /examples 2- copy myApplication from production server copy configuration file ($tomcat/Catalina/localhost/myApplication.xml) from production server stop start tomcat $curl -u edoardo:pwd http://localhost:8080/manager/text/reload?path=/myApplication OK - Reloaded application at context path /myApplication 3- first modify to server.xml shutdown tomcat modify server.xml Connector port=8080 protocol=HTTP/1.1 becomes Connector port=9080 protocol=HTTP/1.1 start then curl again all well 4- second modify to server.xml Host name=localhost appBase=webapps unpackWARs=true autoDeploy=true becomes Host name=localhost appBase=webapps unpackWARs=true autoDeploy=true deployXML=false stop-start $curl -u edoardo:pwd http://localhost:9080/manager/text/reload?path=/myApplication javax.servlet.ServletException: Error instantiating servlet class org.apache.catalina.manager.ManagerServlet [...] $curl -u edoardo:pwd http://localhost:9080/manager/text/reload?path=/myApplication the same error reported in the initial post (above) deployXML=false is recommended at http://tomcat.apache.org/tomcat-7.0-doc/config/host.html and useful for me. I'll bet the problem is that Tomcat doesn't like applications declaring themselves to be privileged=true. The first time Tomcat is started, META-INF/context.xml from the Manager is copied into conf/Catalina/localhost/manager.xml where the privileged=true is preserved. With deployXML=false, this file is not copied and so META-INF/context.xml is used instead. Tomcat maybe doesn't allow META-INF/context.xml to contain privileged=true. (Of course, Tomcat seems perfectly happy to copy META-INF/context.xml into conf/Catalina/localhost/manager.xml and *then* permit privileged=true so my premise is a bit shaky). Duh. I had this entirely backwards. Please ignore the noise. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSZCUDAAoJEBzwKT+lPKRYhQEQAMM21VkOkwCIb2lKcwv15ev4 0tDgNC3lZ4kW7g0srcD9EqxZV29vqUXPKknkCNib1upajaCUf8NRDedJmeUv2riO Bn73ezkaQIvjIejgAOQ7FsEGxh5VI483BpDkAMygILN19mUc4rPdT2PEp0u0S1S2 81MK85SujwHNiflZXxf76G3/Y1991gzD0Qpr8HDniPDrgW/ITDmsET4HMi4sw31u aXmSLo57iwJf/L/mIfCxTCakb8AveqyvR9Sx5ktRAGGS45nihOqHKs74dstM9d4H A8l1eHpGy34DDlKzDFA8OXjJO+ExhE37a8/Tw+6Ml9BS4evoNM6WL1KlfTc1SIN5 HXSNSnkTFqNPgefA3G0rH8/jNZNKnn2RyTynOZuGqe5Jpuv8sgugvU1Q3rHzcc/N i9idIWSM4TS3fxJRFSpw47FyhFXiI5qb0k8hxM52IuOZoOHavKn5w52C1ahRpNaY X055rKeTqz2mu/uajhtH+FdFVZWaC65mmvtIgeRbzdTzberTRjNNBNyxv7Q6u1Cv EAYjChm5VUaWM1aPmjdb1MWNdVRuFI2Mlm8FEI9gfj8RTQ0KmOtyUk10y0VQYKel MMdnC4oN+UeGL99OMrNJFVOL/1dh571iqrrWNiYBp6YlpPnm9FWfjCeNeLcJgjXV tJG5Tk1G27t3/FfNBdHV =sZRe -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: can't connect to manager application
2013/10/20 Christopher Schultz ch...@christopherschultz.net: Edoardo, On 10/18/13 6:03 PM, Edoardo Panfili wrote: Il 17/10/13 18:45, Edoardo Panfili ha scritto: I'll bet the problem is that Tomcat doesn't like applications declaring themselves to be privileged=true. The first time Tomcat is started, META-INF/context.xml from the Manager is copied into conf/Catalina/localhost/manager.xml where the privileged=true is preserved. With deployXML=false, this file is not copied and so META-INF/context.xml is used instead. Tomcat maybe doesn't allow META-INF/context.xml to contain privileged=true. (Of course, Tomcat seems perfectly happy to copy META-INF/context.xml into conf/Catalina/localhost/manager.xml and *then* permit privileged=true so my premise is a bit shaky). Copying is controlled by copyXML attribute. The meaning of deployXML=false is that Tomcat ignores META-INF/context.xml files bundled with web applications and honors only those there were explicitly (manually) configured by Administrator in the conf directory of the server. (Thus you have better control over deployed applications, but with more work to configure them.) deployXML=false and running with SecurityManager are usually used together. If you omit the latter, a rogue web application can reconfigure Tomcat via reflection. If you omit the former, an application can be configured via context.xml so that it bypasses some crucial security restrictions. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: User cannot edit wiki pages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jon, On 10/18/13 4:29 PM, Info wrote: On 17/10/2013 14:39, Info wrote: I am new to your user list, why don’t you help me out like the others instead of rudely patronising me. I asked you politely not to hijack threads and ignored that request. Other list members have responded politely to your questions and you have repeatedly ignored them. You have also been asked not to top-post and you continue to do so. This list tends to be tolerant of folks that make mistakes providing that folks listen when their mistakes are pointed out. Unfortunately - as in this case - the polite requests are ignored and the blunt approach is necessary in order for the message to get through. If you don't like having such messages directed at you, the solution is simple. Take heed to the polite advice the first time around. Mark Hey Mark, Thanks for your patience. I've never heard of top posting and the concept of it being bad, most modern email clients actually force you to top post so its habit. No, they don't. Note that Gmail isn't a real mail client. Why don’t you guys use a forum like PHPBB, surely that would stop these frustrations? Because forums suck. Digests don't work. You can't batch-download updates. You have to login to interact. Email is simply easier for ... just about everything. I can use my smart phone for this mailing list without any special software, and it's okay if my browser's javascript engine sucks because I'm not using it. If you like nntp better, you can use a mail-to-news gateway. In general, the ASF supports mailing lists for communication and not forums for the above and many other reasons. (Honestly, if we were to move to a forum format, I'd lobby for using something more like Stack Exchange since it's a great platform and rewards members of the community for submitting useful answers.) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSZGPMAAoJEBzwKT+lPKRYf4kP/jH6oz3LF3mWMZvFqtF7XTd5 gRmXKXnSaz33VDPLUDpTLRSPdraYrvJG/DKK0MLESdil0bolBLxRqRz8azNB6gTp cSSPizPlj5rDA3GRrOi0Cgqtkh1HR2MYTPQM/Re5dOdFSGEJfv5GAOV5ciF/Dyq8 LffoNPg6igwt407NC5B9Xyj30DzOYgVxwzsQyY3nPf/rnFoIN2C7DwyCr4Orn0ID oYEBVOVLnw0nGzKhdbQgkPpM2VDE7isCNse0gu6+Swvo7OnEcWJCa2V6JXo6/vK4 +FjXPBuoDyfxMUnftRfkbKANGG+RF0x3z8i5aNb3DYKXuIU6oTg9eIDoUzGszQLu RWtEV1KUX7BewjkttUOgdBJ6ROS8kzMD2YLP6rF50osbV1Suf9kKTwUcwlyHUMMt fxYP8k5HeCyD6cWjb74SSY1yB3D00IisH97Ciw4jTz2EgbUx3Dn98wBSECiMB9+l nyAiLv8grRBxH0o8sIlIddpOPLE5/fZR6LU6QbaypEggYIJ0xALKZNNqOKXmwjcS mLe8gQXbDjje+0Wk1uA6HOYHmo3XeIC3nubvrBrkftu5PTgfzPmy4g8oOEE3Ck4B c0yheH7q0suGP8dS1BfzQuXh7YsG2m3RbqTsqBc1ZXFvpheUQ9208tHpClbiPwWB 3bafhN0jVGZhOv+0kuUv =ATq8 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
