[Resin-interest] Resin 4.0.37 via Eclipse Plugin
Within Eclipse I did the following: 1) Went to New -- Dynamic Web Project 2) Selected Resin 4.0 as my Target runtime on the dialog that pops up 3) Left Default Configuration for Resin 4.0 selected under Configuration 4) Selected Generate web.xml deployment descriptor 5) On the Server tab, I right-click -- New -- Server and select Resin -- Resin 4.0 and mainly Next, Next, Next until done. Now when I try to start the new Server (which should be sitting on port 8080) it errors out with: com.caucho.config.core.ResinImport.init(): Required file 'C:\...\Servers\Resin 4.0 at localhost-config\cluster-default.xml' can not be read for resin:import. Is this expected? Can someone point me to a web page that shows me how to create or setup the cluster-default.xml? Or is there a better way to get a Resin Server up and running using Eclipse than the steps I took? Or maybe my plugin is too old? I'm just sorta lost on where to go from here. Thanks, Aaron ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin 4.0.37 via Eclipse Plugin
Ah, I just tried going about it a completely different way. I started with Help -- Install new updates, threw in Caucho and found the Resin URL and installed it. Now it's all working nicely. Must have been due to my old plugin or something. Thanks, Aaron -Original Message- From: resin-interest-boun...@caucho.com [mailto:resin-interest- boun...@caucho.com] On Behalf Of Aaron Freeman Sent: Monday, September 30, 2013 3:28 PM To: 'General Discussion for the Resin application server' Subject: [Resin-interest] Resin 4.0.37 via Eclipse Plugin Within Eclipse I did the following: 1) Went to New -- Dynamic Web Project 2) Selected Resin 4.0 as my Target runtime on the dialog that pops up 3) Left Default Configuration for Resin 4.0 selected under Configuration 4) Selected Generate web.xml deployment descriptor 5) On the Server tab, I right-click -- New -- Server and select Resin -- Resin 4.0 and mainly Next, Next, Next until done. Now when I try to start the new Server (which should be sitting on port 8080) it errors out with: com.caucho.config.core.ResinImport.init(): Required file 'C:\...\Servers\Resin 4.0 at localhost-config\cluster-default.xml' can not be read for resin:import. Is this expected? Can someone point me to a web page that shows me how to create or setup the cluster-default.xml? Or is there a better way to get a Resin Server up and running using Eclipse than the steps I took? Or maybe my plugin is too old? I'm just sorta lost on where to go from here. Thanks, Aaron ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Non-pro Question
In resin-4.0.35 I am spinning on a typical BufferedInputStream read loop to read from a multipart stream. It works great, but for some reason a large percent of the connections hang at some point on the blocked read call. I thought that the default SocketTimeout setting in Resin would cause that to eventually throw an exception, but that does not appear to be happening. Here is a partial thread dump of the blocked call: at java.net.SocketInputStream.socketRead0 (SocketInputStream.java:-2) at java.net.SocketInputStream.read (SocketInputStream.java:150) at java.net.SocketInputStream.read (SocketInputStream.java:121) at sun.security.ssl.InputRecord.readFully (InputRecord.java:442) at sun.security.ssl.InputRecord.read (InputRecord.java:480) -- locked java.lang.Object@0x627eabb3 at sun.security.ssl.SSLSocketImpl.readRecord (SSLSocketImpl.java:927) at sun.security.ssl.SSLSocketImpl.readDataRecord (SSLSocketImpl.java:884) at sun.security.ssl.AppInputStream.read (AppInputStream.java:102) at com.caucho.vfs.SocketStream.read (SocketStream.java:187) at com.caucho.vfs.ReadStream.read (ReadStream.java:472) at com.caucho.server.http.ContentLengthStream.read (ContentLengthStream.java:79) Any ideas why the socketRead0 just hangs and the SocketTimeout never fires? Thanks, Aaron ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] BEAST SSL Attack
On a whim we looked to see if there was a new snapshot, and there was, so we tried it. Looks like the honor-cipher-code addition is working great. We were able to get it to show that we are compliant - so we will be doing more internal testing to make sure the snapshot is stable enough and then we will roll it out. Thanks a bunch! Aaron From: resin-interest-boun...@caucho.com [mailto:resin-interest-boun...@caucho.com] On Behalf Of Aaron Freeman Sent: Friday, January 18, 2013 10:09 AM To: 'General Discussion for the Resin application server' Subject: Re: [Resin-interest] BEAST SSL Attack OK, just keep us posted. Thanks, Aaron From: resin-interest-boun...@caucho.com [mailto:resin-interest-boun...@caucho.com] On Behalf Of Paul Cowan Sent: Friday, January 18, 2013 10:01 AM To: General Discussion for the Resin application server Subject: Re: [Resin-interest] BEAST SSL Attack On Jan 18, 2013, at 10:18 AM, Aaron Freeman aaron.free...@layerz.com wrote: We're getting scanned today. Any hope on this? I just tested that Resin snapshot - the honor-cipher-order is not in that jar. I think there was a mistake in the SCM checkin or Scott may have built the archive to soon. We'll try to put up a new snapshot today/soon, but I'm not certain it's possible with various other bug fixes in progress. Thanks, Paul Thanks, Aaron From: mailto:resin-interest-boun...@caucho.com resin-interest-boun...@caucho.com [mailto:resin- mailto:interest-boun...@caucho.com interest-boun...@caucho.com] On Behalf Of Aaron Freeman Sent: Monday, January 14, 2013 2:01 PM To: 'General Discussion for the Resin application server' Subject: Re: [Resin-interest] BEAST SSL Attack Still needing a little assistance on this one. Thanks, Aaron From: mailto:resin-interest-boun...@caucho.com resin-interest-boun...@caucho.com [mailto:resin- mailto:interest-boun...@caucho.com interest-boun...@caucho.com] On Behalf Of Aaron Freeman Sent: Thursday, January 10, 2013 2:12 PM To: 'General Discussion for the Resin application server' Subject: Re: [Resin-interest] BEAST SSL Attack Hmm, we were able to swap out jsse for openssl and get that working without any issues using the snapshot you recommend below. However when we add honor-cipher-order under the openssl node, we get this error: [root@alpha bin]# ./www.sh start /opt/sendthisfile/server/conf/www.xml:80: honor-cipher-order is an unexpected tag (parent openssl starts at 75). 78: passwordpassword/password 79: cipher-suite!aNULL:!eNULL:!EXPORT:!DSS:!DES:RC4-SHA:RC4-MD5:ALL/cipher-su ite 80: honor-cipher-ordertrue/honor-cipher-order 81: /openssl 82: /http openssl syntax: ( (@ca-certificate-file | ca-certificate-file)? (@ca-certificate-path | ca-certificate-path)? (@ca-revocation-file | ca-revocation-file)? (@ca-revocation-path | ca-revocation-path)? (@certificate-file | certificate-file) (@certificate-chain-file | certificate-chain-file)? (@certificate-key-file | certificate-key-file)? (@cipher-suite | cipher-suite)? (@crypto-device | crypto-device)? (@password | password) (@protocol | protocol)? (@session-cache | session-cache)? (@session-cache-timeout | session-cache-timeout)? (@unclean-shutdown | unclean-shutdown)? (@verify-client | verify-client)? (@verify-depth | verify-depth)?) From the configuration, this is the version of OpenSSL we are on: OPENSSL : OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008 include : /usr/include lib : libraries : -lssl -lcrypto Any ideas? Thanks, Aaron ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] BEAST SSL Attack
We're getting scanned today. Any hope on this? Thanks, Aaron From: resin-interest-boun...@caucho.com [mailto:resin-interest-boun...@caucho.com] On Behalf Of Aaron Freeman Sent: Monday, January 14, 2013 2:01 PM To: 'General Discussion for the Resin application server' Subject: Re: [Resin-interest] BEAST SSL Attack Still needing a little assistance on this one. Thanks, Aaron From: resin-interest-boun...@caucho.com [mailto:resin-interest-boun...@caucho.com] On Behalf Of Aaron Freeman Sent: Thursday, January 10, 2013 2:12 PM To: 'General Discussion for the Resin application server' Subject: Re: [Resin-interest] BEAST SSL Attack Hmm, we were able to swap out jsse for openssl and get that working without any issues using the snapshot you recommend below. However when we add honor-cipher-order under the openssl node, we get this error: [root@alpha bin]# ./www.sh start /opt/sendthisfile/server/conf/www.xml:80: honor-cipher-order is an unexpected tag (parent openssl starts at 75). 78: passwordpassword/password 79: cipher-suite!aNULL:!eNULL:!EXPORT:!DSS:!DES:RC4-SHA:RC4-MD5:ALL/cipher-su ite 80: honor-cipher-ordertrue/honor-cipher-order 81: /openssl 82: /http openssl syntax: ( (@ca-certificate-file | ca-certificate-file)? (@ca-certificate-path | ca-certificate-path)? (@ca-revocation-file | ca-revocation-file)? (@ca-revocation-path | ca-revocation-path)? (@certificate-file | certificate-file) (@certificate-chain-file | certificate-chain-file)? (@certificate-key-file | certificate-key-file)? (@cipher-suite | cipher-suite)? (@crypto-device | crypto-device)? (@password | password) (@protocol | protocol)? (@session-cache | session-cache)? (@session-cache-timeout | session-cache-timeout)? (@unclean-shutdown | unclean-shutdown)? (@verify-client | verify-client)? (@verify-depth | verify-depth)?) From the configuration, this is the version of OpenSSL we are on: OPENSSL : OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008 include : /usr/include lib : libraries : -lssl -lcrypto Any ideas? Thanks, Aaron From: resin-interest-boun...@caucho.com [mailto:resin-interest-boun...@caucho.com] On Behalf Of Scott Ferguson Sent: Tuesday, January 08, 2013 7:42 PM To: resin-interest@caucho.com Subject: Re: [Resin-interest] BEAST SSL Attack On 1/5/13 5:14 PM, Keith Fetterman wrote: Hi Scott, We need this too. Can you try http://caucho.com/download/resin-pro-4_0-snap.tar.gz The configuration is honor-cipher-ordertrue/honor-cipher-order in openssl. -- Scott Thanks, Keith On 1/2/2013 1:36 PM, Scott Ferguson wrote: On 1/2/13 11:58 AM, Aaron Freeman wrote: We have now been scanned and been found to be non-compliant due to lack of the ability to order ciphers. Is there any timeframe we might expect even a snapshot to have this capability? I'll see if I can get a snapshot this week. -- Scott Thanks, Aaron From: resin-interest-boun...@caucho.com [mailto:resin-interest-boun...@caucho.com] On Behalf Of Aaron Freeman Sent: Wednesday, December 05, 2012 10:51 AM To: 'General Discussion for the Resin application server' Subject: Re: [Resin-interest] BEAST SSL Attack Very good, I appreciate the feedback. Thanks, Aaron From: resin-interest-boun...@caucho.com [mailto:resin-interest-boun...@caucho.com] On Behalf Of Paul Cowan Sent: Wednesday, December 05, 2012 9:02 AM To: General Discussion for the Resin application server Subject: Re: [Resin-interest] BEAST SSL Attack Hi Folks, Resin does not support SSLHonorCipherOrder yet. We already received a request from another customer and there is a feature request for this here: http://bugs.caucho.com/view.php?id=5282 This is an OpenSSL feature, not JSSE. We'll be implementing it in an upcoming release. Probably it will be in 4.0.44, as .43 is due for release soon. Thanks, Paul On Dec 5, 2012, at 8:13 AM, Aaron Freeman wrote: Knut, Thanks a bunch for your reply. I saw you referencing another email you sent, but this is the only one I saw come through the group. At any rate, we are already using the cipher-suites feature, but in this case that's not enough. They are telling us that we actually have to be able to prioritize the order that the suites are negotiated on the server side. The only cipher suites guaranteed not to have the BEAST attack issue are ones that aren't wide-spread yet (TLSv1.1) however if we can put TLSv1.0 in a specific order that will suffice for PCI compliance. This bug for Tomcat addresses the issue and gives
Re: [Resin-interest] BEAST SSL Attack
OK, just keep us posted. Thanks, Aaron From: resin-interest-boun...@caucho.com [mailto:resin-interest-boun...@caucho.com] On Behalf Of Paul Cowan Sent: Friday, January 18, 2013 10:01 AM To: General Discussion for the Resin application server Subject: Re: [Resin-interest] BEAST SSL Attack On Jan 18, 2013, at 10:18 AM, Aaron Freeman aaron.free...@layerz.com wrote: We're getting scanned today. Any hope on this? I just tested that Resin snapshot - the honor-cipher-order is not in that jar. I think there was a mistake in the SCM checkin or Scott may have built the archive to soon. We'll try to put up a new snapshot today/soon, but I'm not certain it's possible with various other bug fixes in progress. Thanks, Paul Thanks, Aaron From: mailto:resin-interest-boun...@caucho.com resin-interest-boun...@caucho.com [mailto:resin- mailto:interest-boun...@caucho.com interest-boun...@caucho.com] On Behalf Of Aaron Freeman Sent: Monday, January 14, 2013 2:01 PM To: 'General Discussion for the Resin application server' Subject: Re: [Resin-interest] BEAST SSL Attack Still needing a little assistance on this one. Thanks, Aaron From: mailto:resin-interest-boun...@caucho.com resin-interest-boun...@caucho.com [mailto:resin- mailto:interest-boun...@caucho.com interest-boun...@caucho.com] On Behalf Of Aaron Freeman Sent: Thursday, January 10, 2013 2:12 PM To: 'General Discussion for the Resin application server' Subject: Re: [Resin-interest] BEAST SSL Attack Hmm, we were able to swap out jsse for openssl and get that working without any issues using the snapshot you recommend below. However when we add honor-cipher-order under the openssl node, we get this error: [root@alpha bin]# ./www.sh start /opt/sendthisfile/server/conf/www.xml:80: honor-cipher-order is an unexpected tag (parent openssl starts at 75). 78: passwordpassword/password 79: cipher-suite!aNULL:!eNULL:!EXPORT:!DSS:!DES:RC4-SHA:RC4-MD5:ALL/cipher-su ite 80: honor-cipher-ordertrue/honor-cipher-order 81: /openssl 82: /http openssl syntax: ( (@ca-certificate-file | ca-certificate-file)? (@ca-certificate-path | ca-certificate-path)? (@ca-revocation-file | ca-revocation-file)? (@ca-revocation-path | ca-revocation-path)? (@certificate-file | certificate-file) (@certificate-chain-file | certificate-chain-file)? (@certificate-key-file | certificate-key-file)? (@cipher-suite | cipher-suite)? (@crypto-device | crypto-device)? (@password | password) (@protocol | protocol)? (@session-cache | session-cache)? (@session-cache-timeout | session-cache-timeout)? (@unclean-shutdown | unclean-shutdown)? (@verify-client | verify-client)? (@verify-depth | verify-depth)?) From the configuration, this is the version of OpenSSL we are on: OPENSSL : OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008 include : /usr/include lib : libraries : -lssl -lcrypto Any ideas? Thanks, Aaron ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] BEAST SSL Attack
Hmm, we were able to swap out jsse for openssl and get that working without any issues using the snapshot you recommend below. However when we add honor-cipher-order under the openssl node, we get this error: [root@alpha bin]# ./www.sh start /opt/sendthisfile/server/conf/www.xml:80: honor-cipher-order is an unexpected tag (parent openssl starts at 75). 78: passwordpassword/password 79: cipher-suite!aNULL:!eNULL:!EXPORT:!DSS:!DES:RC4-SHA:RC4-MD5:ALL/cipher-su ite 80: honor-cipher-ordertrue/honor-cipher-order 81: /openssl 82: /http openssl syntax: ( (@ca-certificate-file | ca-certificate-file)? (@ca-certificate-path | ca-certificate-path)? (@ca-revocation-file | ca-revocation-file)? (@ca-revocation-path | ca-revocation-path)? (@certificate-file | certificate-file) (@certificate-chain-file | certificate-chain-file)? (@certificate-key-file | certificate-key-file)? (@cipher-suite | cipher-suite)? (@crypto-device | crypto-device)? (@password | password) (@protocol | protocol)? (@session-cache | session-cache)? (@session-cache-timeout | session-cache-timeout)? (@unclean-shutdown | unclean-shutdown)? (@verify-client | verify-client)? (@verify-depth | verify-depth)?) From the configuration, this is the version of OpenSSL we are on: OPENSSL : OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008 include : /usr/include lib : libraries : -lssl -lcrypto Any ideas? Thanks, Aaron From: resin-interest-boun...@caucho.com [mailto:resin-interest-boun...@caucho.com] On Behalf Of Scott Ferguson Sent: Tuesday, January 08, 2013 7:42 PM To: resin-interest@caucho.com Subject: Re: [Resin-interest] BEAST SSL Attack On 1/5/13 5:14 PM, Keith Fetterman wrote: Hi Scott, We need this too. Can you try http://caucho.com/download/resin-pro-4_0-snap.tar.gz The configuration is honor-cipher-ordertrue/honor-cipher-order in openssl. -- Scott Thanks, Keith On 1/2/2013 1:36 PM, Scott Ferguson wrote: On 1/2/13 11:58 AM, Aaron Freeman wrote: We have now been scanned and been found to be non-compliant due to lack of the ability to order ciphers. Is there any timeframe we might expect even a snapshot to have this capability? I'll see if I can get a snapshot this week. -- Scott Thanks, Aaron From: resin-interest-boun...@caucho.com [mailto:resin-interest-boun...@caucho.com] On Behalf Of Aaron Freeman Sent: Wednesday, December 05, 2012 10:51 AM To: 'General Discussion for the Resin application server' Subject: Re: [Resin-interest] BEAST SSL Attack Very good, I appreciate the feedback. Thanks, Aaron From: resin-interest-boun...@caucho.com [mailto:resin-interest-boun...@caucho.com] On Behalf Of Paul Cowan Sent: Wednesday, December 05, 2012 9:02 AM To: General Discussion for the Resin application server Subject: Re: [Resin-interest] BEAST SSL Attack Hi Folks, Resin does not support SSLHonorCipherOrder yet. We already received a request from another customer and there is a feature request for this here: http://bugs.caucho.com/view.php?id=5282 This is an OpenSSL feature, not JSSE. We'll be implementing it in an upcoming release. Probably it will be in 4.0.44, as .43 is due for release soon. Thanks, Paul On Dec 5, 2012, at 8:13 AM, Aaron Freeman wrote: Knut, Thanks a bunch for your reply. I saw you referencing another email you sent, but this is the only one I saw come through the group. At any rate, we are already using the cipher-suites feature, but in this case that's not enough. They are telling us that we actually have to be able to prioritize the order that the suites are negotiated on the server side. The only cipher suites guaranteed not to have the BEAST attack issue are ones that aren't wide-spread yet (TLSv1.1) however if we can put TLSv1.0 in a specific order that will suffice for PCI compliance. This bug for Tomcat addresses the issue and gives good details about a directive, SSLHonorCipherOrder, that handles the problem: https://issues.apache.org/bugzilla/show_bug.cgi?id=53481 Any other ideas for Resin? Aaron From: resin-interest-boun...@caucho.com [mailto:resin-interest-boun...@caucho.com] On Behalf Of Knut Forkalsrud Sent: Tuesday, December 04, 2012 9:31 PM To: General Discussion for the Resin application server Subject: Re: [Resin-interest] BEAST SSL Attack Actually, I got it wrong in my previous mail. The feature should be working. There is a ticket describing the feature: http://bugs.caucho.com/view.php?id=3593 On Tue, Dec 4, 2012 at 7:00 PM, Knut Forkalsrud knut-cau
Re: [Resin-interest] BEAST SSL Attack
Awesome, looking forward to it! -a From: resin-interest-boun...@caucho.com [mailto:resin-interest-boun...@caucho.com] On Behalf Of Scott Ferguson Sent: Wednesday, January 02, 2013 3:37 PM To: General Discussion for the Resin application server Subject: Re: [Resin-interest] BEAST SSL Attack On 1/2/13 11:58 AM, Aaron Freeman wrote: We have now been scanned and been found to be non-compliant due to lack of the ability to order ciphers. Is there any timeframe we might expect even a snapshot to have this capability? I'll see if I can get a snapshot this week. -- Scott Thanks, Aaron From: resin-interest-boun...@caucho.com [mailto:resin-interest-boun...@caucho.com] On Behalf Of Aaron Freeman Sent: Wednesday, December 05, 2012 10:51 AM To: 'General Discussion for the Resin application server' Subject: Re: [Resin-interest] BEAST SSL Attack Very good, I appreciate the feedback. Thanks, Aaron From: resin-interest-boun...@caucho.com [mailto:resin-interest-boun...@caucho.com] On Behalf Of Paul Cowan Sent: Wednesday, December 05, 2012 9:02 AM To: General Discussion for the Resin application server Subject: Re: [Resin-interest] BEAST SSL Attack Hi Folks, Resin does not support SSLHonorCipherOrder yet. We already received a request from another customer and there is a feature request for this here: http://bugs.caucho.com/view.php?id=5282 This is an OpenSSL feature, not JSSE. We'll be implementing it in an upcoming release. Probably it will be in 4.0.44, as .43 is due for release soon. Thanks, Paul On Dec 5, 2012, at 8:13 AM, Aaron Freeman wrote: Knut, Thanks a bunch for your reply. I saw you referencing another email you sent, but this is the only one I saw come through the group. At any rate, we are already using the cipher-suites feature, but in this case that's not enough. They are telling us that we actually have to be able to prioritize the order that the suites are negotiated on the server side. The only cipher suites guaranteed not to have the BEAST attack issue are ones that aren't wide-spread yet (TLSv1.1) however if we can put TLSv1.0 in a specific order that will suffice for PCI compliance. This bug for Tomcat addresses the issue and gives good details about a directive, SSLHonorCipherOrder, that handles the problem: https://issues.apache.org/bugzilla/show_bug.cgi?id=53481 Any other ideas for Resin? Aaron From: resin-interest-boun...@caucho.com [mailto:resin-interest-boun...@caucho.com] On Behalf Of Knut Forkalsrud Sent: Tuesday, December 04, 2012 9:31 PM To: General Discussion for the Resin application server Subject: Re: [Resin-interest] BEAST SSL Attack Actually, I got it wrong in my previous mail. The feature should be working. There is a ticket describing the feature: http://bugs.caucho.com/view.php?id=3593 On Tue, Dec 4, 2012 at 7:00 PM, Knut Forkalsrud knut-cau...@forkalsrud.org wrote: In the days of Resin 2.1.4 and onwards http://www.caucho.com/resin-3.1/changes/changes-2.xtp there was such a feature, however it seems to have lapsed. I remember because there was a similar issue with MSIE http://support.microsoft.com/default.aspx?scid=kb;en-us;Q305217. I my good old copy of Resin 3.1.8 there are remains the feature. If you bring up the source code for com.caucho.vfs.JsseSSLFactory.create(host, port) you will find a block of code commented out. Then there was a second incarnation where you could specify cipher suites. That seems to have dies some time around Aug 2009 with the commit: https://github.com/mdaniel/svn-caucho-com-resin/commit/96de31370ffd0153eb45f c49725a9b796bc11224#modules/resin/src/com/caucho/vfs/JsseSSLFactory.java I suspect you could get it going again if you have the fortitude to play around with Resin's source code and build your own. Good luck, Knut Forkalsrud On Mon, Dec 3, 2012 at 7:53 AM, Aaron Freeman aaron.free...@layerz.com wrote: SSL BEAST ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest === Paul Cowan, Software Engineer Caucho Technology co...@caucho.com http://blog.caucho.com http://twitter.com/cauchoresin ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] BEAST SSL Attack
Knut, Thanks a bunch for your reply. I saw you referencing another email you sent, but this is the only one I saw come through the group. At any rate, we are already using the cipher-suites feature, but in this case that’s not enough. They are telling us that we actually have to be able to prioritize the order that the suites are negotiated on the server side. The only cipher suites guaranteed not to have the BEAST attack issue are ones that aren’t wide-spread yet (TLSv1.1) however if we can put TLSv1.0 in a specific order that will suffice for PCI compliance. This bug for Tomcat addresses the issue and gives good details about a directive, SSLHonorCipherOrder, that handles the problem: https://issues.apache.org/bugzilla/show_bug.cgi?id=53481 Any other ideas for Resin? Aaron From: resin-interest-boun...@caucho.com [mailto:resin-interest-boun...@caucho.com] On Behalf Of Knut Forkalsrud Sent: Tuesday, December 04, 2012 9:31 PM To: General Discussion for the Resin application server Subject: Re: [Resin-interest] BEAST SSL Attack Actually, I got it wrong in my previous mail. The feature should be working. There is a ticket describing the feature: http://bugs.caucho.com/view.php?id=3593 On Tue, Dec 4, 2012 at 7:00 PM, Knut Forkalsrud knut-cau...@forkalsrud.org wrote: In the days of Resin 2.1.4 and onwards http://www.caucho.com/resin-3.1/changes/changes-2.xtp there was such a feature, however it seems to have lapsed. I remember because there was a similar issue with MSIE http://support.microsoft.com/default.aspx?scid=kb;en-us;Q305217. I my good old copy of Resin 3.1.8 there are remains the feature. If you bring up the source code for com.caucho.vfs.JsseSSLFactory.create(host, port) you will find a block of code commented out. Then there was a second incarnation where you could specify cipher suites. That seems to have dies some time around Aug 2009 with the commit: https://github.com/mdaniel/svn-caucho-com-resin/commit/96de31370ffd0153eb45fc49725a9b796bc11224#modules/resin/src/com/caucho/vfs/JsseSSLFactory.java I suspect you could get it going again if you have the fortitude to play around with Resin's source code and build your own. Good luck, Knut Forkalsrud On Mon, Dec 3, 2012 at 7:53 AM, Aaron Freeman aaron.free...@layerz.com wrote: SSL BEAST ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] BEAST SSL Attack
For PCI compliance we are supposed to address the SSL BEAST attack by prioritizing SSL cipher suites. Any clue how to do that with JSSE? We are using JSSE because we run Resin uncompiled. Am I correct in thinking that in order to run OpenSSL we HAVE to compile Resin? Or is there a way to make it work running uncompiled? If so, we can prioritize the cipher suites with OpenSSL, correct? Thanks, Aaron ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] JSP encoding issues
We had that issue when using jsp:include (jsp:include content wouldn't get UTF-8 encoded), but switching it out for c:import worked. Not sure if this applies in your case, but if the copyright is jsp:include'd you might try to c:import and see if you get different results. No matter what you did in the highest level JSP (the controller if you will) it didn't encode stuff brought in via the jsp:include. I thought that had been fixed at one point, but possibly not. Aaron -Original Message- From: resin-interest-boun...@caucho.com [mailto:resin-interest- boun...@caucho.com] On Behalf Of Rick Mann Sent: Tuesday, August 28, 2012 3:50 PM To: General Discussion for the Resin application server Subject: Re: [Resin-interest] JSP encoding issues Sorry, I should've been more clear. The problem I'm experiencing is not that the headers aren't being properly set. It's that UTF-8 in my source page is getting mangled. In this case, a copyright symbol (C), while still rendered in the page, is preceded by a capital A with an accent (not sure of the exact character) when finally rendered in Safari or FireFox. Somewhere in the long chain of processing, a conversion is happening. -- Rick On Aug 28, 2012, at 10:15 , Scott Ferguson f...@caucho.com wrote: On 08/27/2012 05:04 PM, Rick Mann wrote: Oh, I can also put that empty page directive at the end of my include file, and it also triggers the correct behavior. What, exactly isn't working? The parsing of the page? Or the content-type header? I just created a filter and JSP to reproduce this, and in all cases the res.setCharacterEncoding or res.setContentType is passed through to the output. -- Scott On Aug 27, 2012, at 16:39 , Rick Mann rm...@latencyzero.com wrote: I'm trying to serve everything UTF-8. To this end, I wrote a request filter that sets the input and output encodings to UTF-8, and I've used that successfully in the past. I've been able to avoid putting a page encoding directive in each page. With resin 4.0.30, I'm seeing something odd. I only get the right behavior if the JSP page as an extra %@ page % at the top somewhere. The actual directive inside doesn't seem to matter. I had an import directive, but tried it without one and still got the right behavior. I also have, before that, at %@ include directive, which must also be present. It includes the following: %@ page contentType=text/html; charset=UTF-8 % Without that, the resulting encoding isn't correct, either. What's odd is the empty page directive required to make it work. Any ideas? -- Rick ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest -- Rick ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] EclipseLink Upgrade Question
We are using EclipseLink and cannot use the version that ships with resin-4.0.x due to a bug in that version. So we are having to install resin and then delete the jar file that's in the resin lib folder, which is less than desirable. We really don't want to have to modify the resin install at all. So two questions: 1) Is there any way to tell resin, via the resin.xml, to ignore the version found in resin-4.0.30/lib? 2) Is there any hope of you guys upgrading resin-4.0.30 to ship with version EclipseLink 2.4 instead? Thanks, Aaron ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Resin 4 stability
I just want to query the user community for what seems to be the most stable version of resin 4.0 out there? We have been developing and using Rein 4.0.23 and are pretty satisfied. Has anybody been using a later version in production and development and find it to be nice and stable? Thanks, Aaron ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin 4 stability
Ah, good to know -- that bug would also kick us in the grapes as well. I'll wait for your guys' feedback on 4.0.30 per Scott's comment. Thanks, Aaron -Original Message- From: resin-interest-boun...@caucho.com [mailto:resin-interest- boun...@caucho.com] On Behalf Of Mattias Jiderhamn Sent: Thursday, July 19, 2012 12:39 PM To: resin-interest@caucho.com Subject: Re: [Resin-interest] Resin 4 stability - Original Message - Subject: [Resin-interest] Resin 4 stability Date: Thu, 19 Jul 2012 09:53:47 -0500 From: Aaron Freeman aaron.free...@layerz.com I just want to query the user community for what seems to be the most stable version of resin 4.0 out there? We have been developing and using Rein 4.0.23 and are pretty satisfied. Has anybody been using a later version in production and development and find it to be nice and stable? We're still on 4.0.23 in production 4.0.28 looked really promising, especially for JSF development, but then there was http://bugs.caucho.com/view.php?id=5120 Looking forward to evaluating 4.0.29! -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Resin 4.0 Clustering and HTTP MULTIPART
Does Resin 4.0 have any notion of handling a situation where a large HTTP MULTIPART POST request has come in (a large file transfer for example), and then when one of the nodes of the cluster that is handling that MULTIPART POST were to go offline, another node would take over with no interruption between the client and the cluster? If not, is there any technology that handles large MULTIPART POSTs in some redundant form like that? Thanks, Aaron ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin 4.0 Clustering and HTTP MULTIPART
-Original Message- From: resin-interest-boun...@caucho.com [mailto:resin-interest- boun...@caucho.com] On Behalf Of Scott Ferguson Sent: Wednesday, February 22, 2012 1:17 PM To: resin-interest@caucho.com Subject: Re: [Resin-interest] Resin 4.0 Clustering and HTTP MULTIPART On 02/22/2012 11:08 AM, Aaron Freeman wrote: Does Resin 4.0 have any notion of handling a situation where a large HTTP MULTIPART POST request has come in (a large file transfer for example), and then when one of the nodes of the cluster that is handling that MULTIPART POST were to go offline, another node would take over with no interruption between the client and the cluster? If not, is there any technology that handles large MULTIPART POSTs in some redundant form like that? I'm not sure I understand the question. At the base level, a POST is just a stream of bytes. The multipart/mime handling is just a convenience parser on top so you don't have to parse it yourself. A half-parsed POST (or fully parsed, but not processed) isn't something that can be failed over automatically, because the individual Parts aren't really meaningful. But we also can't failover POSTs at all once the dispatch has begun, because there's no way for Resin to know if the application's POST handling is idempotent, safe to retry. We can failover on a load-balancer/app-server connection failure, or on a 503 response, but not on any other kind of response. Right, I had a hard time articulating the problem, but I think you did get the gist of it based on your response. I guess what I was hoping for is if there is a technology that can multicast (wrong word because multicast works on UDP, but I mean _conceptually_ multicast) an HTTP POST to multiple servers simultaneously such that both servers receive the inbound stream and can record it, then possibly only one sends back the response (perhaps both nodes send the response back, but the triad chooses one as the final response and ignores the other). I am architecting off the cuff here, but was just wondering if something like that or some alternative exists. Sounds like your answer is a clear no. But if you could multicast an HTTP POST like that, wouldn't it be conceptually feasible to have an automatic failover? Or is there something lower level going on that I am completely missing (probably the case). Thanks, Aaron ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Single Signon Questions
After more trial and error I was able to replace the resin:Forward with path-mapping and get the workaround working, but we still have to log in twice. Any thoughts on what I might be missing for single sign-on to work? Thanks, Aaron From: resin-interest-boun...@caucho.com [mailto:resin-interest-boun...@caucho.com] On Behalf Of Aaron Freeman Sent: Friday, December 09, 2011 12:19 AM To: General Discussion for the Resin application server Subject: [Resin-interest] Single Signon Questions Using Resin 4.0.23 we are trying to get single sign-on working per this link: http://www.caucho.com/resin-4.0/admin/security-overview.xtp#SingleSignon I have placed the resin:XmlAuthenticator at the host level. Per the example. Also tried this at both the host and cluster level: web-app-default resin:FormLogin form-login-page=/login.jsp/ session-config reuse-session-id='true' enable-cookies='true' enable-url-rewriting='false' cookie-domain='.mydomain.com'/ /web-app-default We are able to log into: web-app id=/ . But when we go to the next webapp which is defined as: web-app id=/birt . It doesn't see that we are logged in and tries to send us to /birt/login.jsp which obviously doesn't exist. I have tried putting in resin:Forward to redirect to absolute-target=/login.jsp, but it appears the internal redirect from j_security_check doesn't honor resin:Forward rules. I don't believe it should be redirecting in the first place though, if single signon works. Any hints at what I am missing to get single signon working, or if it's not possible a work around to the fact that the /birt webapp is trying to call /birt/login.jsp instead of /login.jsp as defined in resin:FormLogin? Thanks, Aaron ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] 4.0.24 configuration notes
I hope so. Since it's new, this is a great time for feedback
For the first time, Resin 4.0.24 doesn't work out of the box when added to
Eclipse as a new server.
I go through this process pain free for each new release, but now
immediately see the message 'default' is an unknown server in the
configuration file and the server doesn't start.
To recreate, use Servers | New | Server | Resin 4.0 | (Create runtime
specifying the new Resin home) | Next | Finish (add apps as necessary) |
try
to start the server.
In fact the 4.0.23 server is still present which I'm sticking with for
now.
I had a similar issue with 4.0.23 (though it was my fault), and by switching
out:
-conf ${resin.configuration.file}
with:
-conf /path/to/resin.xml
it went away. I have always set that explicitly though and have never tried
to figure out how ${resin.configuration.file} gets set.
Not sure that helps much, but thought I would throw it out there as
something to try.
Aaron
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Database Conflict
With the latest resin-pro-4.0.23 plugin we are now getting an error when
trying to start multiple instances of Resin within a single Eclipse
environment:
java.sql.SQLException: CREATE for path
'C:\opt\project\ext\resin-pro-4.0.23\resin-data\default\tmp\temp_file'
failed, because the file already exists. CREATE can not override an
existing table.
We were able to get around the issue by adding a -data-directory argument to
the Resin plugin's Program arguments section, but why do we have to do
that suddenly?
What is the best practice for starting multiple VMs?Is there some
setting we can use to get it to use WEB-INF (not sure that is a good idea),
or ${resin.root}/${server}/tmp or something?
Any other options that would be better than having to explicitly add that
extra program argument with a hardcoded path?
Thanks,
-a
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] 4.0.24 configuration notes
-Original Message-
If you look at the new default resin.xml, it has a
resin:properties path=${__DIR__}/resin.properties
and several uses of rvar like http port=${rvar('http')}/. The
resin:properties is similar to the resin:import, but loads a properties
file
and saves the values in EL expressions which are then available to the
resin.xml. Basically, this means that many sites will only need to change
the
resin.properties and may never need to touch the resin.xml.
This could be awesome!
Will modifying the resin.properties force your resin instance to restart?
The resin.xml also includes a
resin:import fileset=${__DIR__}/local.d/*.xml/
which will let you add configuration such as database tags in a separate
*.xml without needing to modify the standard one.
Same question as above, will modifying the *.xml files force your resin
instance to restart?
Thanks,
Aaron
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Obfuscating Password in resin.xml
The following password xmlns ... technique works great for database
definitions:
database
jndi-namejdbc/oracle/jndi-name
driver
typeoracle.jdbc.pool.OracleConnectionPoolDataSource/type
urljdbc:oracle:thin:@${com.database.server}:${com.database.port}:${com.dat
abase.sid}/url
user${com.database.username}/user
password
xmlns:encryption=urn:java:com.company.encryption
encryption:Passwordabcdef/encryption:Password
/password
/driver
max-connections20/max-connections
max-idle-time60s/max-idle-time
/database
However this same technique does not work for jsse-ssl definitions.
jsse-ssl
key-store-typejks/key-store-type
key-store-file/opt/some/server/keys/some.kdb/key-store-file
password
xmlns:encryption=urn:java:com.company.encryption
encryption:Passwordabcdef/encryption:Password
/password
cipher-suitesSSL_RSA_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_SHA,SSL_RSA_WIT
H_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CB
C_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA/cipher-suites
/jsse-ssl
I get the following error at startup:
/opt/company/server/conf/resin.xml:76: unable to create attribute
SetterAttribute[public void
com.caucho.vfs.JsseSSLFactory.setPassword(java.lang.String)] for
com.caucho.vfs.JsseSSLFactory@176f5261 and
QName[{http://caucho.com/ns/resin}password]
Once upon a time ago there was discussion that this would be added to a
future release. Any thoughts as to if that can happen easily?
Thanks,
Aaron
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Possible Bug Fix?
If there is agreement that this is a bug, and the fix can be rolled into a
snapshot, I can test further to find out where the next gotcha is with large
valued contentLengths.
Thanks,
Aaron
From: resin-interest-boun...@caucho.com
[mailto:resin-interest-boun...@caucho.com] On Behalf Of Aaron Freeman
Sent: Monday, October 17, 2011 5:09 PM
To: General Discussion for the Resin application server
Subject: [Resin-interest] Possible Bug Fix?
In AbstractHttpRequest I am seeing that the global variable _contentLength
it appropriately a long. Love that. Been a thorn in our side for a long
time.
However in looking at this method (also inside of AbstractHttpRequest):
protected void setContentLength(CharSegment value)
{
int contentLength = 0;
int ch;
int i = 0;
int length = value.length();
for (;
i length (ch = value.charAt(i)) = '0' ch = '9';
i++) {
contentLength = 10 * contentLength + ch - '0';
}
if (i 0)
_contentLength = contentLength;
}
The method is internally using an int, so the values get truncated or
wrapped to negative values. Internally I believe that method should use a
long for the local contentLength variable.
This should help prevent HttpRequest from incorrectly throwing this for
request larger than 2GB (which is what the user community would see in their
logs if they are dumping exceptions):
throw new com.caucho.server.dispatch.BadRequestException(POST
requires content-length);
Thanks,
Aaron
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Possible Bug Fix?
Okidoke, no problem.
- Aaron
From: resin-interest-boun...@caucho.com
[mailto:resin-interest-boun...@caucho.com] On Behalf Of Scott Ferguson
Sent: Thursday, October 20, 2011 11:58 AM
To: resin-interest@caucho.com
Subject: Re: [Resin-interest] Possible Bug Fix?
On 10/20/2011 08:25 AM, Aaron Freeman wrote:
If there is agreement that this is a bug, and the fix can be rolled into a
snapshot, I can test further to find out where the next gotcha is with large
valued contentLengths.
Thanks. I've filed this as http://bugs.caucho.com/view.php?id=4819.
There's a little bit of a bug backlog, so it'll probably be another week or
two.
-- Scott
Thanks,
Aaron
From: resin-interest-boun...@caucho.com
[mailto:resin-interest-boun...@caucho.com] On Behalf Of Aaron Freeman
Sent: Monday, October 17, 2011 5:09 PM
To: General Discussion for the Resin application server
Subject: [Resin-interest] Possible Bug Fix?
In AbstractHttpRequest I am seeing that the global variable _contentLength
it appropriately a long. Love that. Been a thorn in our side for a long
time.
However in looking at this method (also inside of AbstractHttpRequest):
protected void setContentLength(CharSegment value)
{
int contentLength = 0;
int ch;
int i = 0;
int length = value.length();
for (;
i length (ch = value.charAt(i)) = '0' ch = '9';
i++) {
contentLength = 10 * contentLength + ch - '0';
}
if (i 0)
_contentLength = contentLength;
}
The method is internally using an int, so the values get truncated or
wrapped to negative values. Internally I believe that method should use a
long for the local contentLength variable.
This should help prevent HttpRequest from incorrectly throwing this for
request larger than 2GB (which is what the user community would see in their
logs if they are dumping exceptions):
throw new com.caucho.server.dispatch.BadRequestException(POST
requires content-length);
Thanks,
Aaron
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin 4.0 Questions
Is anybody using resin:import successfully that could advise on this? I am still struggling with it. Thanks, Aaron From: resin-interest-boun...@caucho.com [mailto:resin-interest-boun...@caucho.com] On Behalf Of Aaron Freeman Sent: Monday, October 17, 2011 3:53 PM To: General Discussion for the Resin application server Subject: [Resin-interest] Resin 4.0 Questions We are on the latest and greatest Resin 4.0, and would like to have a single resin.xml file that: 1) imports host.xml, which defines: - a keystore to use and the passwords for the keystore 2) on different servers we would like to overwrite the host.xml so we can change: - host aliases - reference a different keystore - add additional host sections Is all of this possible with resin:import, or is it not possible to pull this off? Thanks, Aaron ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin 4.0 Questions
Oh geez, that's so obvious. * smack myself *
Thanks,
Aaron
From: resin-interest-boun...@caucho.com
[mailto:resin-interest-boun...@caucho.com] On Behalf Of Scott Ferguson
Sent: Wednesday, October 19, 2011 11:46 AM
To: resin-interest@caucho.com
Subject: Re: [Resin-interest] Resin 4.0 Questions
On 10/19/2011 08:19 AM, Aaron Freeman wrote:
Is anybody using resin:import successfully that could advise on this? I am
still struggling with it.
You can use EL variables like
resin:import path=host-${ext}.xml/
where you've defined -Dext=foo.
Is that what you're looking for?
-- Scott
Thanks,
Aaron
From: resin-interest-boun...@caucho.com
[mailto:resin-interest-boun...@caucho.com] On Behalf Of Aaron Freeman
Sent: Monday, October 17, 2011 3:53 PM
To: General Discussion for the Resin application server
Subject: [Resin-interest] Resin 4.0 Questions
We are on the latest and greatest Resin 4.0, and would like to have a single
resin.xml file that:
1) imports host.xml, which defines:
- a keystore to use and the passwords for the keystore
2) on different servers we would like to overwrite the host.xml so we can
change:
- host aliases
- reference a different keystore
- add additional host sections
Is all of this possible with resin:import, or is it not possible to pull
this off?
Thanks,
Aaron
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Resin 4.0 Questions
We are on the latest and greatest Resin 4.0, and would like to have a single resin.xml file that: 1) imports host.xml, which defines: - a keystore to use and the passwords for the keystore 2) on different servers we would like to overwrite the host.xml so we can change: - host aliases - reference a different keystore - add additional host sections Is all of this possible with resin:import, or is it not possible to pull this off? Thanks, Aaron ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Possible Bug Fix?
In AbstractHttpRequest I am seeing that the global variable _contentLength
it appropriately a long. Love that. Been a thorn in our side for a long
time.
However in looking at this method (also inside of AbstractHttpRequest):
protected void setContentLength(CharSegment value)
{
int contentLength = 0;
int ch;
int i = 0;
int length = value.length();
for (;
i length (ch = value.charAt(i)) = '0' ch = '9';
i++) {
contentLength = 10 * contentLength + ch - '0';
}
if (i 0)
_contentLength = contentLength;
}
The method is internally using an int, so the values get truncated or
wrapped to negative values. Internally I believe that method should use a
long for the local contentLength variable.
This should help prevent HttpRequest from incorrectly throwing this for
request larger than 2GB (which is what the user community would see in their
logs if they are dumping exceptions):
throw new com.caucho.server.dispatch.BadRequestException(POST
requires content-length);
Thanks,
Aaron
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Something interesting for People using Resin with Oracle
Alan, No, I assumed that a URL versus a file declaration would be the same. I will use the URL version instead and try it. Also interesting idea as regards JDBC driver swap out. We are using ojdbc6.jar for an 11g R1 database. What combination are you using? Thanks, Aaron -Original Message- From: resin-interest-boun...@caucho.com [mailto:resin-interest- boun...@caucho.com] On Behalf Of Alan Wright Sent: Saturday, October 01, 2011 4:32 AM To: General Discussion for the Resin application server Subject: Re: [Resin-interest] Something interesting for People using Resin with Oracle Have you typed jvm-arg exactly as it is in your resin.xml? I think it is important that it should be file:///dev/urandom I was frequently getting the long delays on startup like yourself. Also you could try an older jdbc driver version to see if the problem goes away either as a solution, or just to more clearly isolate the problem. Regards Alan On 30/09/2011 19:49, Aaron Freeman wrote: We are currently experiencing a problem when we restart where the ConnectionPools to Oracle take a long time to be established and cause a long delay for our production machine to start. It almost feels like the old ConnectionPools have to timeout, even though we have shut the entire Resin instance down and restarted the entire JVM. When I saw your post below I got excited because it's very similar to the issue we are having, but we don't have the SQLRecoverableException anywhere that I am seeing. Also it's not really undeterministic -- it always happens. How long the connections to Oracle take are sort of random, but it's way too long. When I went into /resin-admin/ I see that this is implicitly being set: jvm-arg-Djava.security.egd=/dev/urandom/jvm-arg So adding your argument won't help us. Any other ideas on what could cause resin-4.0.18 to take so darn long to fire up as regards connection to Oracle 11g? Thanks, -a -- Alan Wright Athene Systems tel 0845 230 9803 Athene Systems Limited Registered Office: Shieling House Invincible Road Farnborough GU14 7QU Registered in England and Wales No. 3156080 ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Something interesting for People using Resin with Oracle
We are currently experiencing a problem when we restart where the ConnectionPools to Oracle take a long time to be established and cause a long delay for our production machine to start. It almost feels like the old ConnectionPools have to timeout, even though we have shut the entire Resin instance down and restarted the entire JVM. When I saw your post below I got excited because it's very similar to the issue we are having, but we don't have the SQLRecoverableException anywhere that I am seeing. Also it's not really undeterministic -- it always happens. How long the connections to Oracle take are sort of random, but it's way too long. When I went into /resin-admin/ I see that this is implicitly being set: jvm-arg-Djava.security.egd=/dev/urandom/jvm-arg So adding your argument won't help us. Any other ideas on what could cause resin-4.0.18 to take so darn long to fire up as regards connection to Oracle 11g? Thanks, -a -Original Message- From: resin-interest-boun...@caucho.com [mailto:resin-interest- boun...@caucho.com] On Behalf Of Daniel López Sent: Wednesday, September 28, 2011 10:13 AM To: General Discussion for the Resin application server Subject: Re: [Resin-interest] Something interesting for People using Resin with Oracle Good to know Alan, thanks. Who would have thought servers accessing databases might be located in dedicated machines? Way to go, Oracle! :D S! D. El 28/09/2011 16:19, Alan Wright escribió: At the same time as upgrading to Resin 4 we are upgrading to Oracle 11gR2. Starting/stopping resin was very non-deterministic seeming to hang sometimes during application startup with references to connection timeouts in the error logs. SQLRecoverableException: IO Error: Connection reset The problem was traced to a drying up of the entropy poll preventing oracle jdbc from allocating connections until the pool was replenished The following article explains in full http://www.usn-it.de/index.php/2009/02/20/oracle-11g-jdbc-driver-hangs -blocked-by-devrandom-entropy-pool-empty The solution was to add the following to resin.xml !-- Deal with problems associated with 11G JDBC driver new connection requires random number but generator uses entropy pool filled by random user actions - server has no connected user so entropy pool often empty -- jvm-arg-Djava.security.egd=file:///dev/urandom/jvm-arg Hope this helps someone. Alan -- --- Daniel Lopez Janariz (d.lo...@uib.es) Web Services Centre for Information and Technology Balearic Islands University (SPAIN) --- ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Resin 4.0 equivalent for notfound
I know this is obvious and I am just overlooking it, but what would be the Resin 4.0 equivalent to the Resin 3.0 rewrite-dispatch not-found regexp=^.*/\.svn/.*$//not-found /rewrite-dispatch syntax? I don't see a resin:NotFound option. I don't want to resin:Deny because I don't even want people knowing we are using subversion. Thanks, Aaron ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin 4.0 equivalent for notfound
On 8/9/2011 11:09 AM, Scott Ferguson wrote: resin:SendError code=404/ Oh cool, I'll give that a go. I should have updated to teh Resin 4.0 equivalents long ago! An interesting point ... if you still have rewrite-dispatch.../rewrite-dispatch it can completely take precedence over the resin:... rules if you aren't careful -- causing the resin: rules not to work properly even if they come before the rewrite-dispatch rules. I just ran into that .. not a single one of the resin: stuff would work, then when I commented out all of my rewrite-dispatch rules suddenly ALL the resin: rules started working properly. I think it was just matching on the rewrite-dispatch stuff first regardless of whether there were resin: rules before or after it and I have a catch-all in the rewrite-dispatch rules. -a ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Disabling HTTP Methods
I could use some help on this, even if it's just a hint or some ideas what else to try. Thanks, Aaron I'd like to disabled the HTTP CONNECT method. I don't know the best way to do that, but I tried this and it's not working: resin:Forbidden regexp='.*' resin:IfMethod value=CONNECT/ /resin:Forbidden The request is passed on and I receive a 200 OK response when I telnet and test the CONNECT. What is the most efficient way to get Resin to deny those requests? Thanks, Aaron ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Disabling HTTP Methods
On 7/21/2011 12:27 PM, Scott Ferguson wrote: On 07/20/2011 10:39 AM, Aaron Freeman wrote: I'd like to disabled the HTTP CONNECT method. I don't know the best way to do that, but I tried this and it's not working: resin:Forbidden regexp='.*' resin:IfMethod value=CONNECT/ /resin:Forbidden The request is passed on and I receive a 200 OK response when I telnet and test the CONNECT. What is the most efficient way to get Resin to deny those requests? That config works for me. (You don't need the regexp if you're matching everything, but it doesn't matter for this issue.) There is theresin:Forbidden tag? -- Scott The config doesn't bomb, but in resin-pro-4.0.18 when I run this: telnet localhost 80 then CONNECT http://localhost/ HTTP/1.0 I then get the home page and a 200 OK, instead of a 403 FORBIDDEN. You are able to get it to throw an appropriate HTTP 403? Thanks, Aaron ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Disabling HTTP Methods
On 7/21/2011 4:12 PM, Scott Ferguson wrote: On 07/21/2011 02:01 PM, Aaron Freeman wrote: On 7/21/2011 12:27 PM, Scott Ferguson wrote: On 07/20/2011 10:39 AM, Aaron Freeman wrote: I'd like to disabled the HTTP CONNECT method. I don't know the best way to do that, but I tried this and it's not working: resin:Forbidden regexp='.*' resin:IfMethod value=CONNECT/ /resin:Forbidden The request is passed on and I receive a 200 OK response when I telnet and test the CONNECT. What is the most efficient way to get Resin to deny those requests? That config works for me. (You don't need the regexp if you're matching everything, but it doesn't matter for this issue.) There is theresin:Forbiddentag? -- Scott The config doesn't bomb, but in resin-pro-4.0.18 when I run this: telnet localhost 80 then CONNECT http://localhost/ HTTP/1.0 I then get the home page and a 200 OK, instead of a 403 FORBIDDEN. You are able to get it to throw an appropriate HTTP 403? Where is theresin:Forbidden tag? (cluster,host,web-app, resin-web.xml?) -- Scott Ah now I get your question. :) I was confused. I tried in the web-app-default and web-app based on the regex, but I am guessing you are going to tell me that's too late and I need to put it at the host level -- so I just tried that and it's working great. Sorry for being slow and not thinking this one through more. Thanks, Aaron ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Disabling HTTP Methods
I'd like to disabled the HTTP CONNECT method. I don't know the best way to do that, but I tried this and it's not working: resin:Forbidden regexp='.*' resin:IfMethod value=CONNECT/ /resin:Forbidden The request is passed on and I receive a 200 OK response when I telnet and test the CONNECT. What is the most efficient way to get Resin to deny those requests? Thanks, Aaron ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] resin:MovedPermanently questions
Trying this: http://www.caucho.com/resin-4.0/reference.xtp#resinMovedPermanently Use case: I need to do a 301 redirect for all links to http://blog.X/* to http://www.X/blog/ I found this documentation which is very similar, but does a forward: http://www.caucho.com/resin-4.0/admin/http-rewrite.xtp#Forwardbasedonhostname Two questions: 1) Does MovedPermanently do a 301? If not, this is all moot. 2) I don't think MovedPermanently works at the cluster level -- thinking it may only work at the host level, making this use case not possible. Can someone verify that? Any reason why it couldn't work at the cluster level in future releases? Thanks, Aaron ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] resin:MovedPermanently questions
On 6/15/2011 3:30 PM, Scott Ferguson wrote: On 06/15/2011 01:25 PM, Aaron Freeman wrote: Trying this: http://www.caucho.com/resin-4.0/reference.xtp#resinMovedPermanently Use case: I need to do a 301 redirect for all links to http://blog.X/* to http://www.X/blog/ I found this documentation which is very similar, but does a forward: http://www.caucho.com/resin-4.0/admin/http-rewrite.xtp#Forwardbasedonhostname Two questions: 1) Does MovedPermanently do a 301? If not, this is all moot. It uses HttpServletResponse.SC_MOVED_PERMANENTLY which is a 301. Perfect. 2) I don't think MovedPermanently works at the cluster level -- thinking it may only work at the host level, making this use case not possible. Can someone verify that? Any reason why it couldn't work at the cluster level in future releases? You can always usehost-default to apply a rule across all virtual hosts. Interesting, I will give that a shot. URL dispatching is owned by the virtual host. The cluster level doesn't understand URLs, so it doesn't make sense to dispatch a URL in the cluster level. Does that mean the example, http://www.caucho.com/resin-4.0/admin/http-rewrite.xtp#Forwardbasedonhostname, is fundamentally different then? Maybe it's doing something other than dispatching for Forward to work by MovedPermanently to not work? I can see why both wouldn't work at the cluster level and was surprised to see that example, actually, but just assumed that if Forward could work then MovedPermanently -- Scott Thanks, Aaron ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] resin:MovedPermanently questions
On 6/15/2011 4:04 PM, Scott Ferguson wrote: On 06/15/2011 01:51 PM, Aaron Freeman wrote: URL dispatching is owned by the virtual host. The cluster level doesn't understand URLs, so it doesn't make sense to dispatch a URL in the cluster level. Does that mean the example, http://www.caucho.com/resin-4.0/admin/http-rewrite.xtp#Forwardbasedonhostname, is fundamentally different then? Maybe it's doing something other than dispatching for Forward to work by MovedPermanently to not work? I can see why both wouldn't work at the cluster level and was surprised to see that example, actually, but just assumed that if Forward could work then MovedPermanently Hmm. I've filed a bug report for this. Ok in the meantime I am just going to create virtual hosts with MovedPermanently inside of 'em. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Shutdown Issues
Starting with resin-4.0.16 and persisting with Resin-4.0.18 we can no
longer shutdown the Resin process properly. When I attempt to do so I
get this:
-
Resin/4.0.18 can't shutdown watchdog at 127.0.0.1:10080.
com.caucho.bam.RemoteConnectionFailedException:
BamError[type=cancel,group=remote-connection-failed,
text=Cannot connect to http://127.0.0.1:10080/hmtp
java.io.IOException: Unexpected response HTTP/1.1 500 Internal Server
Error
html
titleServer Error/title
body
h1Server Error/h1
pThe server is temporarily unavailable due to an
internal error. Please notify the system administrator
of this problem./p
precode
Date: 2011-05-26T09:04:56.897+00:00
/code/pre
p /hr /
small
Resin/4.0.18
Server: 'default'
/small
/body/html
---
The jvm log didn't output anything, but when I dump the
watchdog-manager.log I get the clue below. I Googled and found a
reference to adding the sec:AdminAuthenticator, which I tried to get
working, but I could never get the below error to go away.
I am really not thinking I should have to modify our current resin.xml
to simply shutdown the Resin process properly, and perhaps the below
message is misleading?
Currently to shut down resin we are issuing a kill on the non-watchdog
Resin process, which isn't a feel good.
Here is the watchdog-manager.log:
[2011/05/26 03:55:37.854] {http://127.0.0.1:10080-1}
HmtpServlet[WebApp[production/webapp/admin.resin/ROOT]] requires an
active com.caucho.security.Authenticator because HMTP messaging requires
authenticated login for security. In the resin.xml, add an
sec:AdminAuthenticator
[2011/05/26 03:55:37.857] {http://127.0.0.1:10080-1}
javax.enterprise.inject.AmbiguousResolutionException: Too many beans
match, because they all have equal precedence. See the @Stereotype and
enable tags to choose a precedence. Beans:
SingletonBean[Authenticator, {@Default(), @Any()}]
SingletonBean[Authenticator, {@Default()}]
for InjectManager[web-app:production/webapp/admin.resin/ROOT]
at
com.caucho.config.inject.InjectManager.ambiguousException(InjectManager.java:2593)
at
com.caucho.config.inject.InjectManager.resolve(InjectManager.java:1766)
at
com.caucho.config.inject.InjectManager.getReference(InjectManager.java:2101)
at
com.caucho.hemp.servlet.ServerAuthManager.init(ServerAuthManager.java:76)
at com.caucho.remote.HmtpServlet.init(HmtpServlet.java:132)
at javax.servlet.GenericServlet.init(GenericServlet.java:70)
at
com.caucho.server.dispatch.ServletConfigImpl.createServletImpl(ServletConfigImpl.java:1351)
at
com.caucho.server.dispatch.ServletConfigImpl.createServlet(ServletConfigImpl.java:1199)
at
com.caucho.server.dispatch.ServletFilterChain.doFilter(ServletFilterChain.java:98)
at
com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:156)
at
com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:287)
at
com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:792)
at
com.caucho.network.listen.TcpSocketLink.dispatchRequest(TcpSocketLink.java:730)
at
com.caucho.network.listen.TcpSocketLink.handleRequest(TcpSocketLink.java:689)
at
com.caucho.network.listen.TcpSocketLink.handleRequestsImpl(TcpSocketLink.java:669)
at
com.caucho.network.listen.TcpSocketLink.handleRequests(TcpSocketLink.java:617)
at com.caucho.network.listen.AcceptTask.doTask(AcceptTask.java:104)
at
com.caucho.network.listen.ConnectionReadTask.runThread(ConnectionReadTask.java:98)
at
com.caucho.network.listen.ConnectionReadTask.run(ConnectionReadTask.java:81)
at com.caucho.network.listen.AcceptTask.run(AcceptTask.java:67)
at com.caucho.env.thread.ResinThread.runTasks(ResinThread.java:164)
at com.caucho.env.thread.ResinThread.run(ResinThread.java:130)
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Shutdown Issues
I have tried each version, starting with 4.0.18 and going back, and the
shutdown problem begins with resin-pro-4.0.14 and up. I noticed this on
the change log for version 4.0.14:
resin: CLI added deploy, undeploy, list, start-webapp, stop-webapp,
restar-webapp commands (#4316, rep by Patrick Brigger)
So I am guessing either the functionality changed in that version and I
don't know how to upgrade my resin.xml properly. Or there is some issue
in that version and up with just doing a simple shutdown from the
command line (on a Linux system)?
Thanks,
Aaron Freeman
On 5/26/2011 4:29 AM, Aaron Freeman wrote:
Starting with resin-4.0.16 and persisting with Resin-4.0.18 we can no
longer shutdown the Resin process properly. When I attempt to do so I
get this:
-
Resin/4.0.18 can't shutdown watchdog at 127.0.0.1:10080.
com.caucho.bam.RemoteConnectionFailedException:
BamError[type=cancel,group=remote-connection-failed,
text=Cannot connect to http://127.0.0.1:10080/hmtp
java.io.IOException: Unexpected response HTTP/1.1 500 Internal Server
Error
html
titleServer Error/title
body
h1Server Error/h1
pThe server is temporarily unavailable due to an
internal error. Please notify the system administrator
of this problem./p
precode
Date: 2011-05-26T09:04:56.897+00:00
/code/pre
p /hr /
small
Resin/4.0.18
Server: 'default'
/small
/body/html
---
The jvm log didn't output anything, but when I dump the
watchdog-manager.log I get the clue below. I Googled and found a
reference to adding the sec:AdminAuthenticator, which I tried to get
working, but I could never get the below error to go away.
I am really not thinking I should have to modify our current resin.xml
to simply shutdown the Resin process properly, and perhaps the below
message is misleading?
Currently to shut down resin we are issuing a kill on the non-watchdog
Resin process, which isn't a feel good.
Here is the watchdog-manager.log:
[2011/05/26 03:55:37.854] {http://127.0.0.1:10080-1}
HmtpServlet[WebApp[production/webapp/admin.resin/ROOT]] requires an
active com.caucho.security.Authenticator because HMTP messaging requires
authenticated login for security. In the resin.xml, add an
sec:AdminAuthenticator
[2011/05/26 03:55:37.857] {http://127.0.0.1:10080-1}
javax.enterprise.inject.AmbiguousResolutionException: Too many beans
match, because they all have equal precedence. See the @Stereotype and
enable tags to choose a precedence. Beans:
SingletonBean[Authenticator, {@Default(), @Any()}]
SingletonBean[Authenticator, {@Default()}]
for InjectManager[web-app:production/webapp/admin.resin/ROOT]
at
com.caucho.config.inject.InjectManager.ambiguousException(InjectManager.java:2593)
at
com.caucho.config.inject.InjectManager.resolve(InjectManager.java:1766)
at
com.caucho.config.inject.InjectManager.getReference(InjectManager.java:2101)
at
com.caucho.hemp.servlet.ServerAuthManager.init(ServerAuthManager.java:76)
at com.caucho.remote.HmtpServlet.init(HmtpServlet.java:132)
at javax.servlet.GenericServlet.init(GenericServlet.java:70)
at
com.caucho.server.dispatch.ServletConfigImpl.createServletImpl(ServletConfigImpl.java:1351)
at
com.caucho.server.dispatch.ServletConfigImpl.createServlet(ServletConfigImpl.java:1199)
at
com.caucho.server.dispatch.ServletFilterChain.doFilter(ServletFilterChain.java:98)
at
com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:156)
at
com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:287)
at
com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:792)
at
com.caucho.network.listen.TcpSocketLink.dispatchRequest(TcpSocketLink.java:730)
at
com.caucho.network.listen.TcpSocketLink.handleRequest(TcpSocketLink.java:689)
at
com.caucho.network.listen.TcpSocketLink.handleRequestsImpl(TcpSocketLink.java:669)
at
com.caucho.network.listen.TcpSocketLink.handleRequests(TcpSocketLink.java:617)
at com.caucho.network.listen.AcceptTask.doTask(AcceptTask.java:104)
at
com.caucho.network.listen.ConnectionReadTask.runThread(ConnectionReadTask.java:98)
at
com.caucho.network.listen.ConnectionReadTask.run(ConnectionReadTask.java:81)
at com.caucho.network.listen.AcceptTask.run(AcceptTask.java:67)
at com.caucho.env.thread.ResinThread.runTasks(ResinThread.java:164)
at com.caucho.env.thread.ResinThread.run(ResinThread.java:130)
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman
[Resin-interest] Resin Compatible Forum
Is there any forum software out there that runs nicely/reliably under Resin and/or Quercus? Thanks, Aaron ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Automatic Restart Question
We have multiple webapps in our 4.0.16 configuration and would like to be able make changes to our resin.xml file without causing all of the webapps to restart. Can we somehow disable the automatic restart after detecting a change to the resin.xml? If we do that, we can stop/start the individual webapps from the admin screens, but will restarting an individual webapp reload the resin.xml just for that webapp (without interrupting service on the other webapps)? Or will it continue to use whatever resin.xml configuration parameters are loaded into memory? Thanks, Aaron ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Automatic Restart Question
Ah I wasn't using good search criteria on Google. After more searching I found that it's about setting these properly: web-app-default redeploy-modemanual/redeploy-mode jspauto-compiletrue/auto-compile/jsp /web-app-default Still not sure if this will allow a restarted webapp to see the new conf settings independently but at least I can test that now. Thanks, Aaron On 4/7/2011 9:56 AM, Aaron Freeman wrote: We have multiple webapps in our 4.0.16 configuration and would like to be able make changes to our resin.xml file without causing all of the webapps to restart. Can we somehow disable the automatic restart after detecting a change to the resin.xml? If we do that, we can stop/start the individual webapps from the admin screens, but will restarting an individual webapp reload the resin.xml just for that webapp (without interrupting service on the other webapps)? Or will it continue to use whatever resin.xml configuration parameters are loaded into memory? Thanks, Aaron ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Simple documentation fixes
- http://caucho.com/resin-4.0/admin/http-rewrite.xtp#Servlet%20Filters Header should say something like: Example: Servlet Filter Just a copy/paste error from the example above it. - http://caucho.com/resin-4.0/reference.xtp#resin:SetHeader The resin:SetHeader Attributes section is missing a regex attribute. Also, is it required? - http://caucho.com/resin-4.0/reference.xtp#resin:SetVary Same as above. The resin:SetVary Attributes section is missing a regex attribute. Also, is it required? ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Performance issue with Resin Eclipse Plugin Solved
So we were having all kinds of performance issues with the Resin Eclipse plugin (which may or may not be supported, but we use it like crazy now). The performance problem we were all having is that every time we would change some JSP source, we would have to wait WAY too long for the JSP to recompile. It was painful, but we have been living with it. After much head scratching one of our guys figured out that when you set up a new server, there is a default setting that is causing the problem. This may be well documented, but three of us independently couldn't Google a resolution, so I thought I'd post it here. In the Servers view, on the Open -- Open launch configuration -- Arguments tab, this VM argument is set by default: -Djava.library.path=C:/[path-to-resin]/resin-pro-4.0.x/libexec:C:/[path-to-resin]/resin-pro-4.0.x/libexec64 We always ignored that. Turns out that's the problem. For windows 64-bit machines change that to: -Djava.library.path=C:/[path-to-resin]/resin-pro-4.0.x/win64 And for 32-bit machines change it to: -Djava.library.path=C:/[path-to-resin]/resin-pro-4.0.x/win32 Presto it all starts compiling very quickly, as it should. This may be obvious, and nobody else but us are stupid enough not to swap that out, but we just let the defaults be what they are and it bit us. -Aaron ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] AppScope variable in Resin.XML
Is there a simple way to set an applicationScope variable from within
the resin.xml?
I see how to set system properties, but I'd like something I can
reference from a JSP like:
${applicationScope.var}
Or can I reference the system properties similarly?
Thanks,
Aaron
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] AppScope variable in resin.xml
Bah I stumbled on this, but it doesn't appear to do what I was hoping:
context-param
param-namebaz/param-name
param-valuevalue/param-value
/context-param
When I tried to reference that in a test.jsp like this, it is empty:
%@ taglib uri=http://java.sun.com/jsp/jstl/core; prefix=c %
html
p-${applicationScope.baz}-/p
/html
Any other way to do this?
Thanks,
Aaron
On 10/20/2010 12:09 PM, Aaron Freeman wrote:
Is there a simple way to set an applicationScope variable from within
the resin.xml?
I see how to set system properties, but I'd like something I can
reference from a JSP like:
${applicationScope.var}
Or can I reference the system properties similarly?
Thanks,
Aaron
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] AppScope variable in resin.xml
On 10/20/2010 12:39 PM, Scott Ferguson wrote:
Aaron Freeman wrote:
Bah I stumbled on this, but it doesn't appear to do what I was hoping:
context-param
param-namebaz/param-name
param-valuevalue/param-value
/context-param
When I tried to reference that in a test.jsp like this, it is empty:
%@ taglib uri=http://java.sun.com/jsp/jstl/core; prefix=c %
html
p-${applicationScope.baz}-/p
/html
Any other way to do this?
Hmm. I'd forgotten that context-param is application.getInitParam.
You can use ${initParam.baz} to get the context-param value.
I can't remember any way to set the application attributes directly from
the config file, although we could enhance resin:set to allow for
var=#{application.bar}.
-- Scott
A coworker stumbled upon ${initParam.baz} -- the only unfortunate thing
about that is, we are trying to do this:
context-param baz=${varWePassedIn}/
And when we dump ${initParam.baz} it renders literally as
${varWePassedIn} instead of the value of ${varWePassedIn}.
The resin:set solution sounds great. Would this be more intuitive:
resin:set var=bar value=${passedInValue} scope=application/
Where you reference a scope instead of have the #{application.bar} syntax?
Thanks,
Aaron
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] JSTL c:import on Resin 4.0
What version of Resin 4.0 are you using? I can reproduce this easily
on resin-pro-4.0.10 by doing this:
-- create test.jsp:
%@ taglib uri=http://java.sun.com/jsp/jstl/core; prefix=c %
c:import url=test2.jsp var=debug/
${debug}
--
-- create test2.jsp
%@ taglib uri=http://java.sun.com/jsp/jstl/core; prefix=c %
c:import url=test3.jsp var=debug/
${debug}
--
-- create test3.jsp
%@ taglib uri=http://java.sun.com/jsp/jstl/core; prefix=c %
Some output.
--
Then just call: http://localhost/test.jsp
And it will throw your error. It only happens when one c:import calls
another one.
This behavior is completely fixed in resin-pro-4.0.12 though (and was
working in resin-4.0.6, so it broke some time after that release).
Aaron
On 10/18/2010 7:14 PM, Matthew Serrano wrote:
I seem to have issues using JSTL c:import within Resin 4.0. Below is
my code and the error. Any ideas? Does Resin 4.0 no longer support the
import tag?
FYI...my:frame is a custom tag that eventually executes jsp:doBody.
matt
CODE
my:frame title=${title}
c:set var=defaultJsp/common/termsAndConditions_en.jsp/c:set
c:import var=content url=${defaultJsp} /
c:out value=${content} escapeXml=false /
/my:frame
ERROR
javax.servlet.jsp.JspException: unimplemented
at com.caucho.jstl.rt.CoreImportTag.doEndTag(CoreImportTag.java:246)
at
_jsp._common._termsAndConditions__jsp$_CauchoFragment_0._jsp_invoke(_termsAndConditions__jsp.java:157)
at com.caucho.jsp.JspFragmentSupport.invoke(JspFragmentSupport.java:93)
at _jsp._WEB_22dINF._tags._frame__tag.doTag(_frame__tag.java:407)
at
_jsp._common._termsAndConditions__jsp._jspService(_termsAndConditions__jsp.java:102)
at
_jsp._common._termsAndConditions__jsp._jspService(_termsAndConditions__jsp.java:29)
at com.caucho.jsp.JavaPage.service(JavaPage.java:64)
at com.caucho.jsp.Page.pageservice(Page.java:542)
at
com.caucho.server.dispatch.PageFilterChain.doFilter(PageFilterChain.java:194)
at com.caucho.filters.GzipFilter.doFilter(GzipFilter.java:149)
at
com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:89)
at
com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:183)
at
com.caucho.server.webapp.AccessLogFilterChain.doFilter(AccessLogFilterChain.java:95)
at
com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:287)
at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:792)
at
com.caucho.network.listen.TcpSocketLink.dispatchRequest(TcpSocketLink.java:675)
at
com.caucho.network.listen.TcpSocketLink.handleRequestsImpl(TcpSocketLink.java:637)
at
com.caucho.network.listen.TcpSocketLink.handleRequests(TcpSocketLink.java:588)
at
com.caucho.network.listen.TcpSocketLink$AcceptTask.doTask(TcpSocketLink.java:1175)
at
com.caucho.network.listen.TcpSocketLink$ConnectionReadTask.runThread(TcpSocketLink.java:1108)
at
com.caucho.network.listen.TcpSocketLink$AcceptTask.run(TcpSocketLink.java:1142)
at com.caucho.env.thread.ResinThread.runTasks(ResinThread.java:182)
at com.caucho.env.thread.ResinThread.run(ResinThread.java:126)
Caused by: java.lang.UnsupportedOperationException: unimplemented
at
com.caucho.filters.CauchoResponseWrapper.getStatus(CauchoResponseWrapper.java:343)
at
com.caucho.server.http.ResponseAdapter.getStatus(ResponseAdapter.java:385)
at
com.caucho.jstl.rt.CoreImportTag$JstlImportResponseWrapper.init(CoreImportTag.java:466)
at com.caucho.jstl.rt.CoreImportTag.handleBody(CoreImportTag.java:380)
at com.caucho.jstl.rt.CoreImportTag.doEndTag(CoreImportTag.java:222)
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] JSTL c:import on Resin 4.0
Yes, that's exactly what I was doing that was failing in
resin-pro.4.0.10, but not in resin-pro-4.0.12. Try deleting your entire
WEB-INF folder and let resin-pro-4.0.12 reconstruct it, just to make
sure you don't have old 4.0.10 compilations hanging around. There is
definitely a behavior change in chaining imports from 10 to 12, and it's
working for me in 12.
I am also doing a c:import on an xml document in the final c:import, so
we are doing the same thing.
Aaron
On 10/19/2010 11:30 AM, Matthew Serrano wrote:
I just upgraded to resin-pro-4.0.12 and it is still happening...at
least on OS X. It also happens for non JSPs. I have some pages that
import XSL and XML files so I can parse them with the x tag library
and those imports also fail. There is no chaining of imports that I
can see.
matt
On Oct 19, 2010, at 9:24 AM, Aaron Freeman wrote:
What version of Resin 4.0 are you using? I can reproduce this easily
on resin-pro-4.0.10 by doing this:
-- create test.jsp:
%@ taglib uri=http://java.sun.com/jsp/jstl/core; prefix=c %
c:import url=test2.jsp var=debug/
${debug}
--
-- create test2.jsp
%@ taglib uri=http://java.sun.com/jsp/jstl/core; prefix=c %
c:import url=test3.jsp var=debug/
${debug}
--
-- create test3.jsp
%@ taglib uri=http://java.sun.com/jsp/jstl/core; prefix=c %
Some output.
--
Then just call: http://localhost/test.jsp
And it will throw your error. It only happens when one c:import
calls another one.
This behavior is completely fixed in resin-pro-4.0.12 though (and was
working in resin-4.0.6, so it broke some time after that release).
Aaron
On 10/18/2010 7:14 PM, Matthew Serrano wrote:
I seem to have issues using JSTL c:import within Resin 4.0. Below is
my code and the error. Any ideas? Does Resin 4.0 no longer support
the import tag?
FYI...my:frame is a custom tag that eventually executes jsp:doBody.
matt
CODE
my:frame title=${title}
c:set var=defaultJsp/common/termsAndConditions_en.jsp/c:set
c:import var=content url=${defaultJsp} /
c:out value=${content} escapeXml=false /
/my:frame
ERROR
javax.servlet.jsp.JspException: unimplemented
at com.caucho.jstl.rt.CoreImportTag.doEndTag(CoreImportTag.java:246)
at
_jsp._common._termsAndConditions__jsp$_CauchoFragment_0._jsp_invoke(_termsAndConditions__jsp.java:157)
at com.caucho.jsp.JspFragmentSupport.invoke(JspFragmentSupport.java:93)
at _jsp._WEB_22dINF._tags._frame__tag.doTag(_frame__tag.java:407)
at
_jsp._common._termsAndConditions__jsp._jspService(_termsAndConditions__jsp.java:102)
at
_jsp._common._termsAndConditions__jsp._jspService(_termsAndConditions__jsp.java:29)
at com.caucho.jsp.JavaPage.service(JavaPage.java:64)
at com.caucho.jsp.Page.pageservice(Page.java:542)
at
com.caucho.server.dispatch.PageFilterChain.doFilter(PageFilterChain.java:194)
at com.caucho.filters.GzipFilter.doFilter(GzipFilter.java:149)
at
com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:89)
at
com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:183)
at
com.caucho.server.webapp.AccessLogFilterChain.doFilter(AccessLogFilterChain.java:95)
at
com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:287)
at
com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:792)
at
com.caucho.network.listen.TcpSocketLink.dispatchRequest(TcpSocketLink.java:675)
at
com.caucho.network.listen.TcpSocketLink.handleRequestsImpl(TcpSocketLink.java:637)
at
com.caucho.network.listen.TcpSocketLink.handleRequests(TcpSocketLink.java:588)
at
com.caucho.network.listen.TcpSocketLink$AcceptTask.doTask(TcpSocketLink.java:1175)
at
com.caucho.network.listen.TcpSocketLink$ConnectionReadTask.runThread(TcpSocketLink.java:1108)
at
com.caucho.network.listen.TcpSocketLink$AcceptTask.run(TcpSocketLink.java:1142)
at com.caucho.env.thread.ResinThread.runTasks(ResinThread.java:182)
at com.caucho.env.thread.ResinThread.run(ResinThread.java:126)
Caused by: java.lang.UnsupportedOperationException: unimplemented
at
com.caucho.filters.CauchoResponseWrapper.getStatus(CauchoResponseWrapper.java:343)
at
com.caucho.server.http.ResponseAdapter.getStatus(ResponseAdapter.java:385)
at
com.caucho.jstl.rt.CoreImportTag$JstlImportResponseWrapper.init(CoreImportTag.java:466)
at com.caucho.jstl.rt.CoreImportTag.handleBody(CoreImportTag.java:380)
at com.caucho.jstl.rt.CoreImportTag.doEndTag(CoreImportTag.java:222)
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com mailto:resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest
Re: [Resin-interest] Resin and javamail
Ah, this is excellent info. Aaron On 9/21/2010 12:07 PM, Scott Ferguson wrote: Aaron Freeman wrote: Out of curiosity, why does Resin distribute with javamail-141.jar? Is there some built-in mailing functionality that Resin ships with? If so, is there a URL pointing to some documentation on how to take advantage of it? It's primarily a JavaEE requirement that we ship with JavaMail. We do have three things that use JavaMail: Quercus, the mail log-handler, and the PingMailer. I've put up a wiki link for the mail log-handler at http://wiki.caucho.com/Cookbook:_Mail_Log-Handler using CanDI-style syntax (although, you'll need to wait for 4.0.11 for that syntax to work, since I checked the example and the log-handler needed an update for the CanDI syntax.) The mail log-handler is a standard java.util logging handler that sends log messages to a mail address. Since log-handles are additive, the messages will continue to be sent to the log file. The ping mailer is being revamped and folded into Resin's health check system (http://wiki.caucho.com/Admin:_Health), so we're not ready to document the new form of capability yet. -- Scott Thanks, Aaron ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] java.io.IOException: can't clear response after writing headers
This is unrelated, but worth mentioning to other people converting over from Resin 3.0.x: We had this problem when converting over from Resin 3.0.x.: The problem is that Resin 4.0.x now outputs white space in each iteration of c:forEach .../c:forEach loops, and other places where Resin 3.0.x did not. That causes problems with Resin 3.0.x and older code that has c:redirect, sendRedirect, jsp:forward, response.reset(), and any other calls that rely on the response not being committed. The reason is that the buffer used to cache up a response prior to writing out to response's outputStream can fill up very quickly compared with earlier versions and causes the response to commit very fast (with a ton of white space to boot). The fix is, if you are doing jsp:include page= with loops in it, to do: c:import url= var=debug .. /c:import instead. Instead of the output being dumped directly to response's output buffer, the white space will go to a variable that you can ignore (and comes in handy a development environment). If you are not including/importing anything and have a bunch of c:forEach in your code prior to your redirect/clear/reset, try throwing those in a second JSP and doing a c:import .. var=debug in order to trap the white space. This way your response.buffer won't commit prematurely and you can still do redirects/resets. I know this is unrelated but we had issues with it, and I thought I would post it for others searching for redirect/clear/reset issues. Aaron On 8/30/2010 10:33 AM, Morawetz, Martin wrote: wMorawetz, Martin wrote: Hi all, Some JSPs produce following error Stacktrace in our Java-log: java.io.IOException: can't clear response after writing headers at com.caucho.server.http.ResponseStream.clear(ResponseStream.java:233) at com.caucho.server.http.HttpServletResponseImpl.getOutputStream(HttpServ letResponseImpl.java:137) : : The Exception gets thrown at the line sosOut = response.getOutputStream(); This code work on all other resin installations (for years now) The only difference to our other resin installations that I'm aware of, is that resin and apache are on two separate machines now. We use Resin Pro 4.0.9. Any ideas what might cause this exception? Resin is being more strict about conforming to the servlet/JSP spec. Is there an output flush() anywhere before that clear()? -- Scott Yes there is, and removing the out.flush() resolves the issue. Was that 'being more strict' a recent change? The same code works on a different server with Resin 4.0.0 installed. Regards, Martin The information in this e-mail and in any attachments is confidential and intended solely for the attention and use of the named addressee(s). This information may be subject to legal, professional or other privilege and further distribution of it is strictly prohibited without our authority. If you are not the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it, and should notify us immediately. This footnote also confirms that this email has been automatically scanned for the presence of computer viruses, profanities and certain file types. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] ConcurrentModificationException when InjectManager.findByName
This is an error in your JSP/JSTL, not with Resin -- you are trying to
modify (add to) a HashMap that you are iterating over.
Here is a more detailed explanation:
http://forums.sun.com/thread.jspa?threadID=5335803
Aaron
On 8/19/2010 4:20 AM, Wesley Wu wrote:
Often happened at 30 seconds after appserver start.
[10-08-19 17:11:44.378] {server://*:6801-487}
java.util.ConcurrentModificationException
at
java.util.HashMap$HashIterator.nextEntry(HashMap.java:977)
at
java.util.HashMap$KeyIterator.next(HashMap.java:1012)
at
java.util.HashMap.buildCache(HashMap.java:590)
at
java.util.HashMap.resize(HashMap.java:576)
at
java.util.HashMap.addEntry(HashMap.java:939)
at
java.util.HashMap.put(HashMap.java:477)
at
com.caucho.config.inject.InjectManager.findByName(InjectManager.java:759)
at
com.caucho.config.inject.InjectManager.getBeans(InjectManager.java:1254)
at
com.caucho.config.inject.InjectManager.getReferenceFactory(InjectManager.java:1268)
at
com.caucho.config.el.CandiElResolver.getValue(CandiElResolver.java:125)
at
com.caucho.el.EnvironmentLevelELResolver.getValue(EnvironmentLevelELResolver.java:154)
at
com.caucho.el.EnvironmentELResolver.getValue(EnvironmentELResolver.java:151)
at
com.caucho.el.StackELResolver.getValue(StackELResolver.java:143)
at
com.caucho.jsp.InitPageContextImpl.resolveVariable(InitPageContextImpl.java:88)
at
com.caucho.jsp.PageContextImpl$PageVariableMapper.resolveVariable(PageContextImpl.java:2183)
at
com.caucho.el.ELParser.parseSimpleTerm(ELParser.java:702)
at
com.caucho.el.ELParser.parseTerm(ELParser.java:460)
at
com.caucho.el.ELParser.parseExpr(ELParser.java:231)
at
com.caucho.el.ELParser.parseInterpolate(ELParser.java:194)
at
com.caucho.el.ELParser.parse(ELParser.java:113)
at
com.caucho.jsp.JspUtil.createExpr(JspUtil.java:69)
at
_jsp._WEB_22dINF._templates._default._home._album._view__jsp.caucho_init(_view__jsp.java:752)
at
com.caucho.jsp.JspManager.loadPage(JspManager.java:422)
at
com.caucho.jsp.JspManager.preload(JspManager.java:357)
at
com.caucho.jsp.JspManager.compile(JspManager.java:236)
at
com.caucho.jsp.JspManager.createPage(JspManager.java:191)
at
com.caucho.jsp.JspManager.createPage(JspManager.java:170)
at
com.caucho.jsp.PageManager.getPage(PageManager.java:339)
at
com.caucho.jsp.PageManager.getPage(PageManager.java:269)
at
com.caucho.jsp.PageManager.getPage(PageManager.java:252)
at
com.caucho.jsp.QServlet.getSubPage(QServlet.java:295)
at
com.caucho.jsp.QServlet.getPage(QServlet.java:210)
at
com.caucho.server.dispatch.PageFilterChain.compilePage(PageFilterChain.java:237)
at
com.caucho.server.dispatch.PageFilterChain.doFilter(PageFilterChain.java:144)
at
com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:287)
at
com.caucho.server.webapp.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:289)
-Wesley
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin 4.0.9 release
Out of curiosity do you have multiple instances of Resin (separate JVMs)
running on that same virtual machine? If so do you use different ports
for the watchdog on both instances? We had a similar situation and it
was fixed by just running the watchdog on separate ports for each
instance of Resin. Probably not your situation, but thought I'd ask.
Aaron
On 8/13/2010 12:27 AM, Jan Kriesten wrote:
Hi Scott,
I've put up a new snapshot. On a restart, you should see additional
logging information in both the watchdog-manager.log and the
jvm-default.log that should help narrow this down.
the only new entry in the log on restart in the jvm-default.log is this:
06:44:16.969] {main} ProResin[id=] started in 81883ms
WarningService: Stopping Resin because ping did not complete in time.
[07:13:56.772] {resin-shutdown} ProServer[id=,cluster=app-tier] stopping
Shutdown Resin reason: HEALTH
Almost the same is showing up in watchdog-manager.log:
[2010/08/13 07:13:56.816] Watchdog received warning from Resin[1,pid=32039]:
Stopping Resin because ping did not complete
in time.
[2010/08/13 07:13:58.579] Watchdog detected close of Resin[,pid=32039]
exit reason: HEALTH (exit code=8)
[2010/08/13 07:13:58.579] Watchdog starting Resin[]
It's really strange, though, that it happens almost exactly every 30
minutes. The behavior didn't occor with 4.0.7 or previous versions.
Best regards, --- Jan.
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Quercus Question
I was thinking it's possible to do something like this in a php file:
?php
if((include '../www/_header.jsp') == 'OK') {
echo 'OK';
}
?
Where the www folder has a path-mapping entry in the resin.xml.
It includes the file, but the file isn't processed by the JSP engine, so
I literally see strings like ${param.var} in the output of the call to
test.php. How do I include a .jsp in from a .php but get the JSP engine
to process it before it returns? I know I could do something like:
include( 'http:///www/_header.jsp')
but then cookies are lost as the client is the php engine, not the browser.
Is it possible to reuse the JSP code from within the PHP environment?
Is there a link someone could shoot me that explains this?
Thanks,
Aaron
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Quercus Question
The silence is deafening, so I guess I was completely wrong-headed in
thinking you could call a .jsp as in include from a .php?
Bummer, I was hoping that was part of the benefit of having php-based
apps running under full blown Resin, instead of Quercus in stand alone mode.
Thanks,
Aaron
On 8/12/2010 1:36 AM, Aaron Freeman wrote:
I was thinking it's possible to do something like this in a php file:
?php
if((include '../www/_header.jsp') == 'OK') {
echo 'OK';
}
?
Where the www folder has a path-mapping entry in the resin.xml.
It includes the file, but the file isn't processed by the JSP engine, so
I literally see strings like ${param.var} in the output of the call to
test.php. How do I include a .jsp in from a .php but get the JSP engine
to process it before it returns? I know I could do something like:
include( 'http:///www/_header.jsp')
but then cookies are lost as the client is the php engine, not the browser.
Is it possible to reuse the JSP code from within the PHP environment?
Is there a link someone could shoot me that explains this?
Thanks,
Aaron
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Wordpress Under Resin
I saw a wiki for running WordPress under Quercus 3.1.x -- is anybody out there successfully running WordPress under Resin 4.0.x? Thanks, Aaron ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Wordpress Under Resin
Ah, thanks for the confidence builder. Based on your feedback we will take the time to try and get it working with a straight Resin install then. I didn't want us to spin our wheels if someone else failed at doing so. :) Thanks, Aaron On 8/11/2010 12:02 PM, Matthew Serrano wrote: Aaron, I am successfully running WordPress 3.0 in Resin 4.0.7. It is behind Apache 2.2 with permalinks which took a while to configure mod_rewrite but otherwise it works great. matt On Aug 11, 2010, at 7:00 AM, Aaron Freeman wrote: I saw a wiki for running WordPress under Quercus 3.1.x -- is anybody out there successfully running WordPress under Resin 4.0.x? Thanks, Aaron ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Wordpress Under Resin
Ah, I faintly remember your posts about that now. Good to know. We will start with the latest and greatest and work our way backward stopping at 4.0.6, if necessary. :) Aaron On 8/11/2010 2:03 PM, Rick Mann wrote: On Aug 11, 2010, at 10:02:21, Matthew Serrano wrote: Aaron, I am successfully running WordPress 3.0 in Resin 4.0.7. It is behind Apache 2.2 with permalinks which took a while to configure mod_rewrite but otherwise it works great. I had serious problems under certain versions of Resin. I finally settled on 4.0.6 as having a sufficiently-working Quercus and not having other issues (not sure I remember exactly what those were). Prior to 4.0.6, WordPress titles would not render across most of the site. I run Resin directly, no Apache in front. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Wordpress Under Resin
Ok so you want us to try getting it running on 4.0.9, then see if we can just drop it in 4.0.6 and 4.0.5 just to see what happens? Should be easy -- there shouldn't be any config changes on those minor releases -- if that's what you are after. -a On 8/11/2010 3:40 PM, Rick Mann wrote: Let me know how it goes. I kinda wish you'd work back 'till you see the same problem, just so we can be sure it reproduces everywhere ;-) On Aug 11, 2010, at 13:29:04, Aaron Freeman wrote: Ah, I faintly remember your posts about that now. Good to know. We will start with the latest and greatest and work our way backward stopping at 4.0.6, if necessary. :) Aaron On 8/11/2010 2:03 PM, Rick Mann wrote: On Aug 11, 2010, at 10:02:21, Matthew Serrano wrote: Aaron, I am successfully running WordPress 3.0 in Resin 4.0.7. It is behind Apache 2.2 with permalinks which took a while to configure mod_rewrite but otherwise it works great. I had serious problems under certain versions of Resin. I finally settled on 4.0.6 as having a sufficiently-working Quercus and not having other issues (not sure I remember exactly what those were). Prior to 4.0.6, WordPress titles would not render across most of the site. I run Resin directly, no Apache in front. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Firewall Question
Just wondering if anybody has ever worked through a scenario where you could automatically firewall off an IP address that requested a poisoned URL? There is an attacker continuously scanning all of our servers for a specific URL, but from several different IPs. It would be nice to be able to automatically firewall them off. Has anybody done anything like that before? Thanks, Aaron ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Firewall Question
Jon, Right, so far that's been our tact. This one particular attack is a bit annoying because it's inflating our logs. I was just curious if this was a capability within Resin. We wouldn't take the time to write a custom tag or anything like that to stop it. Aaron On 7/21/2010 10:27 AM, Jon Stevens wrote: Having run very very large porn sites for a number of years, I've seen all sorts of automated 'attacks' like that. If you don't have anything responding to those url's, then you don't have any problems. =) Anyway, why bother? Just ignore it. I'm sure you have better things to do with your time than play whack-a-mole. jon On Wed, Jul 21, 2010 at 7:14 AM, Aaron Freemanaaron.free...@layerz.com wrote: Just wondering if anybody has ever worked through a scenario where you could automatically firewall off an IP address that requested a poisoned URL? There is an attacker continuously scanning all of our servers for a specific URL, but from several different IPs. It would be nice to be able to automatically firewall them off. Has anybody done anything like that before? Thanks, Aaron ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Bug in Resin 4.0.x (and 3.1.x)?
Sorry to bump this question, but any idea if this will be fixed in 4.0.7
or 4.0.8 (or if's even a bug or something I am doing wrong)?
Thanks,
Aaron
Scott,
Still struggling with the issue where we cannot encrypt passwords in
our resin.xml file. As you have indicated, there is now a better clue:
C:\opt\. . .\conf\admin.xml:41: unable to create attribute
SetterAttribute[public void
com.caucho.vfs.JsseSSLFactory.setPassword(java.lang.String)] for
com.caucho.vfs.jssesslfact...@79f03d7 and
QName[{http://caucho.com/ns/resin}password]
39: key-store-typejks/key-store-type
40: key-store-file/opt/. . ./keys.kdb/key-store-file
41: password xmlns:encryption=urn:java:com.encryption
42: encryption:Passwordabcdf/encryption:Password
43: /password
Thanks,
Aaron
On 3/22/2010 6:09 PM, Scott Ferguson wrote:
Aaron Freeman wrote:
O
Man, I don't see how I am blowing it then. Does this look right:
password xmlns:encryption=urn:java:[full package, not including the
class]
encryption:[class name]abcdefg/encryption:[class name]
/password
Where the [full package, not including the class] would be something
like java.util and the class name would be something like Hashmap
with an uppercase first character like classes normally are capitalized?
If so, I am a bit baffled.
That looks fine. I'll have a snapshot in a day or two with the improved
error messages. That may give a better idea of the issue.
You could also try removing the whitespace around the
encryption:Password (it shouldn't matter, but then again your example
should work.)
-- Scott
Aaron
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
No virus found in this incoming message.
Checked by AVG -www.avg.com
Version: 9.0.791 / Virus Database: 271.1.1/2764 - Release Date: 03/22/10
14:44:00
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Bug in Resin 4.0.x (and 3.1.x)?
Awesome -- also note that the exact same syntax DOES work in place of
the password in the
databasedriverpassword../password/driver/database nodes.
Aaron
On 5/28/2010 2:14 PM, Scott Ferguson wrote:
Aaron Freeman wrote:
Sorry to bump this question, but any idea if this will be fixed in
4.0.7 or 4.0.8 (or if's even a bug or something I am doing wrong)?
I've added is as a bug report at http://bugs.caucho.com/view.php?id=4054.
Since your syntax is correct for 4.0.x, this looks like a Resin bug. It
should be possible to fix in 4.0.8.
-- Scott
Thanks,
Aaron
Scott,
Still struggling with the issue where we cannot encrypt passwords in
our resin.xml file. As you have indicated, there is now a better clue:
C:\opt\. . .\conf\admin.xml:41: unable to create attribute
SetterAttribute[public void
com.caucho.vfs.JsseSSLFactory.setPassword(java.lang.String)] for
com.caucho.vfs.jssesslfact...@79f03d7 and
QName[{http://caucho.com/ns/resin}password]
39:key-store-typejks/key-store-type
40:key-store-file/opt/. . ./keys.kdb/key-store-file
41:password xmlns:encryption=urn:java:com.encryption
42:encryption:Passwordabcdf/encryption:Password
43:/password
Thanks,
Aaron
On 3/22/2010 6:09 PM, Scott Ferguson wrote:
Aaron Freeman wrote:
O
Man, I don't see how I am blowing it then. Does this look right:
password xmlns:encryption=urn:java:[full package, not including the
class]
encryption:[class name]abcdefg/encryption:[class name]
/password
Where the [full package, not including the class] would be something
like java.util and the class name would be something like Hashmap
with an uppercase first character like classes normally are capitalized?
If so, I am a bit baffled.
That looks fine. I'll have a snapshot in a day or two with the improved
error messages. That may give a better idea of the issue.
You could also try removing the whitespace around the
encryption:Password (it shouldn't matter, but then again your example
should work.)
-- Scott
Aaron
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.791 / Virus Database: 271.1.1/2764 - Release Date: 03/22/10
14:44:00
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Bug in Resin 4.0.x (and 3.1.x)?
Scott,
Still struggling with the issue where we cannot encrypt passwords in our
resin.xml file. As you have indicated, there is now a better clue:
C:\opt\. . .\conf\admin.xml:41: unable to create attribute
SetterAttribute[public void
com.caucho.vfs.JsseSSLFactory.setPassword(java.lang.String)] for
com.caucho.vfs.jssesslfact...@79f03d7 and
QName[{http://caucho.com/ns/resin}password]
39: key-store-typejks/key-store-type
40: key-store-file/opt/. . ./keys.kdb/key-store-file
41: password xmlns:encryption=urn:java:com.encryption
42: encryption:Passwordabcdf/encryption:Password
43: /password
Thanks,
Aaron
On 3/22/2010 6:09 PM, Scott Ferguson wrote:
Aaron Freeman wrote:
O
Man, I don't see how I am blowing it then. Does this look right:
password xmlns:encryption=urn:java:[full package, not including the
class]
encryption:[class name]abcdefg/encryption:[class name]
/password
Where the [full package, not including the class] would be something
like java.util and the class name would be something like Hashmap
with an uppercase first character like classes normally are capitalized?
If so, I am a bit baffled.
That looks fine. I'll have a snapshot in a day or two with the improved
error messages. That may give a better idea of the issue.
You could also try removing the whitespace around the
encryption:Password (it shouldn't matter, but then again your example
should work.)
-- Scott
Aaron
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.791 / Virus Database: 271.1.1/2764 - Release Date: 03/22/10
14:44:00
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Bug in Resin 4.0.x (and 3.1.x)?
Oooh, I should have mentioned .. this exact syntax works with the
database connection, but NOT for the SSL setup. So the class exists,
Resin can find it, and it works great -- but only for database
connections and not within the JSSE configuration node.
Thanks,
Aaron
On 5/17/2010 10:45 AM, Aaron Freeman wrote:
Scott,
Still struggling with the issue where we cannot encrypt passwords in
our resin.xml file. As you have indicated, there is now a better clue:
C:\opt\. . .\conf\admin.xml:41: unable to create attribute
SetterAttribute[public void
com.caucho.vfs.JsseSSLFactory.setPassword(java.lang.String)] for
com.caucho.vfs.jssesslfact...@79f03d7 and
QName[{http://caucho.com/ns/resin}password]
39: key-store-typejks/key-store-type
40: key-store-file/opt/. . ./keys.kdb/key-store-file
41: password xmlns:encryption=urn:java:com.encryption
42: encryption:Passwordabcdf/encryption:Password
43: /password
Thanks,
Aaron
On 3/22/2010 6:09 PM, Scott Ferguson wrote:
Aaron Freeman wrote:
O
Man, I don't see how I am blowing it then. Does this look right:
password xmlns:encryption=urn:java:[full package, not including the
class]
encryption:[class name]abcdefg/encryption:[class name]
/password
Where the [full package, not including the class] would be something
like java.util and the class name would be something like Hashmap
with an uppercase first character like classes normally are capitalized?
If so, I am a bit baffled.
That looks fine. I'll have a snapshot in a day or two with the improved
error messages. That may give a better idea of the issue.
You could also try removing the whitespace around the
encryption:Password (it shouldn't matter, but then again your example
should work.)
-- Scott
Aaron
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
No virus found in this incoming message.
Checked by AVG -www.avg.com
Version: 9.0.791 / Virus Database: 271.1.1/2764 - Release Date: 03/22/10
14:44:00
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Question about Resin 4.0.6
This isn't in the UI layer. This is in a controller. At any rate there
is a simple work around, but this sure doesn't seem like it should be
generating an error. If a property doesn't exist on an object it sure
seems like the test for empty=true should work, and not throw a runtime
error.
At any rate there are easy workarounds in this case but workarounds make
the code uglier.
Aaron
On 5/7/2010 3:57 PM, Jon Stevens wrote:
I don't know if there is a way and it isn't something I'd depend on in
the UI layer. Think of [class] like you'd think of an interface. You
really should only put implementations of interfaces into the context.
Otherwise, I'd consider putting a Map in there for the effect you want.
jon
On Fri, May 7, 2010 at 1:43 PM, Aaron Freeman
aaron.free...@layerz.com mailto:aaron.free...@layerz.com wrote:
Bummer, what's the proper way to test if a property exists then,
since ${!empty [class].[property]} isn't the correct way?
Thanks,
Aaron
On 5/7/2010 3:07 PM, Jon Stevens wrote:
That is what JBoss does, so I'd say that Caucho fixed a bug.
jon
On Fri, May 7, 2010 at 12:59 PM, Aaron Freeman
aaron.free...@layerz.com mailto:aaron.free...@layerz.com wrote:
We are system testing Resin 4.0.6 with our old code base and
found a
curiosity. The following code used to work, regardless of
what type
receipt is:
c:if test=${!empty receipt.details}
Under Resin 3.0.x if receipt was a HashMap and had a
details property
then it would return true. If it was a HashMap and did not
have a
details property, it would correctly return false. And (most
importantly), if receipt was _any_ other class, including
built in java
classes, it would just return false. With Resin 4.0.6 it now
throws an
error:
'details' is an unknown bean property of 'java.math.BigDecimal'
That's not the expected behavior is it?
Thanks,
Aaron
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Question about Resin 4.0.6
Yes, that's exactly right. In several instances we have many
controllers that are written in JSP (pure JSTL code), that c:import
our models (also in this case JSPs) and also c:import our views.
Works great!
The upside to it is: a) easier to code -- people with limited Java
expertise can modify the controllers if they are not too complex (and
rarely are), and b) you can change your controllers on the fly without
having to restart Resin (primary reason we do this).
Aaron
On 5/7/2010 5:05 PM, Rachel McConnell wrote:
This comment isn't helpful I know but I am very curious about this.
The code you quoted is a tag library call using the EL. How is that
not part of the UI? Are you writing controllers in JSP somehow?
Rachel
On Fri, May 7, 2010 at 2:47 PM, Aaron Freemanaaron.free...@layerz.com
wrote:
This isn't in the UI layer. This is in a controller. At any rate there is
a simple work around, but this sure doesn't seem like it should be
generating an error. If a property doesn't exist on an object it sure seems
like the test for empty=true should work, and not throw a runtime error.
At any rate there are easy workarounds in this case but workarounds make the
code uglier.
Aaron
On 5/7/2010 3:57 PM, Jon Stevens wrote:
I don't know if there is a way and it isn't something I'd depend on in the
UI layer. Think of [class] like you'd think of an interface. You really
should only put implementations of interfaces into the context. Otherwise,
I'd consider putting a Map in there for the effect you want.
jon
On Fri, May 7, 2010 at 1:43 PM, Aaron Freemanaaron.free...@layerz.com
wrote:
Bummer, what's the proper way to test if a property exists then, since
${!empty [class].[property]} isn't the correct way?
Thanks,
Aaron
On 5/7/2010 3:07 PM, Jon Stevens wrote:
That is what JBoss does, so I'd say that Caucho fixed a bug.
jon
On Fri, May 7, 2010 at 12:59 PM, Aaron Freemanaaron.free...@layerz.com
wrote:
We are system testing Resin 4.0.6 with our old code base and found a
curiosity. The following code used to work, regardless of what type
receipt is:
c:if test=${!empty receipt.details}
Under Resin 3.0.x if receipt was a HashMap and had a details property
then it would return true. If it was a HashMap and did not have a
details property, it would correctly return false. And (most
importantly), if receipt was _any_ other class, including built in java
classes, it would just return false. With Resin 4.0.6 it now throws an
error:
'details' is an unknown bean property of 'java.math.BigDecimal'
That's not the expected behavior is it?
Thanks,
Aaron
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Question about Resin 4.0.6
On 5/7/2010 5:39 PM, Jeff Schnitzer wrote: I doublechecked the spec and the current Resin behavior is the proper behavior. I don't think this behavior has changed in the spec, so the old behavior was a bug. You can't use the empty operator to test for the existence of fields (or methods). Okidoke. As to the rationale for the spec... it does make some amount of sense, helping to reduce one very common type of bug (I'm getting properties of a ThingA and the object turns out to be a ThingB). I'm sure all the arguments for static typing vs duck typing apply here. That's a bummer. I preferred the old behavior as it's closer to JavaScript associative arrays, which are nice and flexible. But mainly because we were relying on that behavior. :) Note: There is nothing special about the empty operator; expressions are resolved as normal and then the result is tested for null or empty collection. If expression evaluation ever tries to access a field or method that doesn't exist on an object, the EL resolver throws PropertyNotFoundException or MethodNotFoundException. Jeff ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Caching issue? with resin pro 3.1.9
Marco, If you are repeating that pattern every time, it sounds more like your _brower's_ cache being the culprit. Instead of calling: http://my-server.com/newfolder/ with an empty folder, place the index.html in there and _then_ call it so your browser doesn't cache up the 404 not found result. You can alternatively hold down the *shift key* while refreshing to see if it's your browser. We would actually test this making the first call in IE and then the second test in FireFox to rule that browser cache issue out, but that sounds like what you are up against. If you find this is the problem, then I am not sure what Resin's default cache settings are for the 404 not found (I bet they don't even address it), but you can replace their 404 not found with your own user-friendlier one and set your own cache settings. Do this in your resin.xml: error-page error-code='404' location='/notfound.jsp' / And set whatever meta tags, and browser cache settings you want in your /notfound.jsp. Aaron On 4/14/2010 4:03 AM, Marco Wingartz wrote: Hello folks, I need some helping hands with a puzzler, we ran into recently... We are using the licensed resin pro 3.1.9 to handle all our servlets and .jsps and additionally we kicked apache and also use resin to spread the static .html contents to the world. While we are aware how to influence max-age in our servlets and .jsps, we still have a strange issue with folders, where content was added after someone already called the empty folder generating a 404 response. Even if we put the index.html into the folder resin will not recognize this and still give the 404 error. Last time this happens it lasted more than 16 hours, until we restarted resin to get rid of this effect. Now my question is, where can I influence cache times of such responses, when I call a folder? Just to give better example... I put a new folder in my doc tree. Then a call of http://my-server.com/newfolder/ will give me 404 page as I have not filled folder yet. When I now put my static index.html into newfolder I can directly call the index.html and page will show. But the call of http://my-server.com/newfolder/ still gives me the 404 error page for hours and days. How can I avoid this without need to restart resin? Any clues, ideas, hints? Best regards, m.w. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] jsp:param behavior change from 3.0.22 to 4.0.5
Oh, you will have to swap out the httputil with whatever you use to
URLEncode strings in order to test it.
Thanks,
Aaron
On 3/31/2010 2:46 PM, Aaron Freeman wrote:
We are experiencing a fundamental change in how data is being passed as
a jsp:param between 3.0.22 and 4.0.5. We need to know if this change is
intentional as it has a work-heavy impact on converting our code base
over which currently relies on the behavior of 3.0.x.
It appears that a call to jsp:include was automatically URL decoding any
strings that were passed in, and that that behavior has changed.
I have included source to two files that will demonstrate the behavior
change (in case it's not intentional). And here are the results of
running it:
on resin-pro-3.0.22
URL encoded before pass to jsp:include:
Test%3A+1+%3C+2+and+width%3D%22100%25%22+and+ampersand%3D%26.
Test: 1 2 and width=100ïand ampersand=
Here it is as seen inside of test-process.jsp:
Test: 1 2 and width=100% and ampersand=.
on resin-pro-4.0.5
URL encoded before pass to jsp:include:
Test%3A+1+%3C+2+and+width%3D%22100%25%22+and+ampersand%3D%26.
Test: 1 2 and width=100ïand ampersand=
Here it is as seen inside of test-process.jsp:
Test:+1++2+and+width=100%+and+ampersand=.
%- BEGIN test.jsp -%
%@ taglib uri=http://java.sun.com/jsp/jstl/core; prefix=c %
%@ taglib uri=http://www.sendthisfile.com/taglib/httputil;
prefix=httputil %
c:if test=${!empty param.textarea}
textarea param exists:br/
${param.textarea}br/br/
c:set var=textareaUrlEncodedBefore
value=${httputil:urlEncode(param.textarea)}/
URL encoded before pass to jsp:include:br/
${textareaUrlEncodedBefore}br/br/
/c:if
%-- Set some requestscope variable in test.jsp --%
jsp:include page=/test-process.jsp
jsp:param name=textarea value=${param.textarea}/
jsp:param name=textareaUrlEncoded value=${textareaUrlEncodedBefore}/
/jsp:include
form action=/test.jsp
textarea name=textarea${requestScope.processedTextarea}/textarea
input type=submit/input
/form
c:if test=${!empty requestScope.urlEncoded}
Here it is as seen inside of test-process.jsp:br/
${requestScope.urlEncoded}
/c:if
%- END test.jsp -%
%- BEGIN test-process.jsp -%
%@ taglib uri=http://java.sun.com/jsp/jstl/core; prefix=c %
c:choose
c:when test=${empty param.textarea}
c:set var=processedTextarea scope=requestTest: 1 2 and
width=100% and ampersand=./c:set
/c:when
c:otherwise
c:set var=processedTextarea scope=request${param.textarea}/c:set
/c:otherwise
/c:choose
c:set var=urlEncoded scope=request${param.textareaUrlEncoded}/c:set
%- END test-process.jsp -%
Thanks for your thoughts on this,
Aaron
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.791 / Virus Database: 271.1.1/2781 - Release Date: 03/31/10
01:32:00
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Resin-4.0.5 Watchdog on Shutdown
When we try to stop the resin-4.0.5 processes using:
$JAVA_HOME/bin/java \
-server \
-Djava.util.logging.manager=com.caucho.log.LogManagerImpl \
-Djava.security.egd=/dev/urandom \
-Dhost=${SERVER} \
-Dresin.home=${RESIN_HOME} \
-jar ${RESIN_HOME}/lib/resin.jar \
-conf ${SERVER_ROOT}/conf/resin.xml \
$*
Where we pass in start to start it and stop to stop the server. The
main resin java process stops, but the watchdog does not. Is that
expected behavior (and thus a change from 3.0.x)? If so, how do we stop
the watchdog java process? I believe Rick Mann reported the same
issue. Also we are running uncompiled, if that matters.
Thanks,
Aaron
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin-4.0.5 Watchdog on Shutdown
Perfect, thanks!
Aaron
On 3/30/2010 1:49 PM, Emil Ong wrote:
Hi Aaron,
This is the correct behavior. In 4.0.x, we changed the watchdog to be a
long-lived process. If you'd like to shut it down, along with all
running resin instances, use the shutdown command. We're in the
process of updating the documentation this week to reflect the change.
Thanks,
Emil
On Tue, Mar 30, 2010 at 11:01:23AM -0500, Aaron Freeman wrote:
When we try to stop the resin-4.0.5 processes using:
$JAVA_HOME/bin/java \
-server \
-Djava.util.logging.manager=com.caucho.log.LogManagerImpl \
-Djava.security.egd=/dev/urandom \
-Dhost=${SERVER} \
-Dresin.home=${RESIN_HOME} \
-jar ${RESIN_HOME}/lib/resin.jar \
-conf ${SERVER_ROOT}/conf/resin.xml \
$*
Where we pass in start to start it and stop to stop the server. The
main resin java process stops, but the watchdog does not. Is that
expected behavior (and thus a change from 3.0.x)? If so, how do we stop
the watchdog java process? I believe Rick Mann reported the same
issue. Also we are running uncompiled, if that matters.
Thanks,
Aaron
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Resin 4.0.5 Buffer Commit Point
We take some fairly lengthy queries (lengthy row based on row count),
and push the data into hashmaps in JSTL pages. After that sometimes we
evaluate the hashmap and sometimes have to redirect the request to
another page. In 3.0.23 it works with no problems. In 4.0.5 we get
java.lang.IllegalStateException: Can't sendRedirect() after data has
committed to the client.
The reason being, that the for loop is causing a ton of white space to
be sent to be buffered up, and at some point a buffer size limit has
been hit with only whitespace, causing Resin to then send the HTTP
headers and commit the request.
So in the for loop I can do this to fix the problem:
c:forEach items=${requestScope.getRewriteUrlsQuery.rows}
var=rewriteUrlsQuery
% response.reset(); %
/c:forEach
The question is, is there a setting in the resin.xml where I can change
the buffer size globally, or do we have to go to modify all JSPs that
potentially have this problem? Was the default commit point changed
between 3.0.x and
4.0.x, or some other architecture change, as we have never seen this
until now?*
*
Thanks,
Aaron*
*
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin 4.0.5 Buffer Commit Point
It's not in the view layer. We segregate our controller JSPs from our
view JSPs. So you will change your argument to say that we should not
use JSPs at the control layer, and of course _most_ of our control logic
is in pure Java, but there are cases where having our controller logic
written in JSTL (and separated from other model/view JSP pages) is a
substantial advantage for us.
So the question still stands, is there a global way to change the commit
point so we don't have to constantly reset a connection to clear the buffer?
Aaron
On 3/25/2010 10:02 AM, Jon Stevens wrote:
This is why you don't put application logic into the view layer.
Before you 'push' your data into the view, figure out if you want to
do the redirect or not.
jon
On Thu, Mar 25, 2010 at 7:49 AM, Aaron Freeman
aaron.free...@layerz.com mailto:aaron.free...@layerz.com wrote:
We take some fairly lengthy queries (lengthy row based on row
count), and push the data into hashmaps in JSTL pages. After that
sometimes we evaluate the hashmap and sometimes have to redirect
the request to another page. In 3.0.23 it works with no
problems. In 4.0.5 we get java.lang.IllegalStateException: Can't
sendRedirect() after data has committed to the client.
The reason being, that the for loop is causing a ton of white
space to be sent to be buffered up, and at some point a buffer
size limit has been hit with only whitespace, causing Resin to
then send the HTTP headers and commit the request.
So in the for loop I can do this to fix the problem:
c:forEach items=${requestScope.getRewriteUrlsQuery.rows}
var=rewriteUrlsQuery
% response.reset(); %
/c:forEach
The question is, is there a setting in the resin.xml where I can
change the buffer size globally, or do we have to go to modify all
JSPs that potentially have this problem? Was the default commit
point changed between 3.0.x and
4.0.x, or some other architecture change, as we have never seen
this until now?*
*
Thanks,
Aaron*
*
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin 4.0.5 Buffer Commit Point
On 3/25/2010 10:31 AM, Jon Stevens wrote:
I don't mind using JSP's for some of the (separated) control logic.
For example, you have a form action:
form action=email_confirm_submit.jsp
Inside of it, it looks like this:
http://code.google.com/p/subetha/source/browse/trunk/web/email_confirm_submit.jsp
That said, look at that code. The logic for determining the next page
to redirect to is either in the t:action or within the JSTL within
the email_confirm_submit.jsp. Generally, it is nice to have it in JSTL
because a UI person can change the location of the final page without
having to modify java code to do so.
The point being that by the time you get to the view layer (ie: a jsp
that doesn't have _submit.jsp at the end), you don't do a redirect.
You are depending on what is effectively a bug in Resin that has now
been fixed in a newer version. You should modify your code to change
that dependency because you can (and should) be doing it differently.
jon
On Thu, Mar 25, 2010 at 8:18 AM, Aaron Freeman
aaron.free...@layerz.com mailto:aaron.free...@layerz.com wrote:
It's not in the view layer. We segregate our controller JSPs from
our view JSPs. So you will change your argument to say that we
should not use JSPs at the control layer, and of course _most_ of
our control logic is in pure Java, but there are cases where
having our controller logic written in JSTL (and separated from
other model/view JSP pages) is a substantial advantage for us.
So the question still stands, is there a global way to change the
commit point so we don't have to constantly reset a connection to
clear the buffer?
Aaron
On 3/25/2010 10:02 AM, Jon Stevens wrote:
This is why you don't put application logic into the view layer.
Before you 'push' your data into the view, figure out if you want
to do the redirect or not.
jon
On Thu, Mar 25, 2010 at 7:49 AM, Aaron Freeman
aaron.free...@layerz.com mailto:aaron.free...@layerz.com wrote:
We take some fairly lengthy queries (lengthy row based on row
count), and push the data into hashmaps in JSTL pages. After
that sometimes we evaluate the hashmap and sometimes have to
redirect the request to another page. In 3.0.23 it works
with no problems. In 4.0.5 we get
java.lang.IllegalStateException: Can't sendRedirect() after
data has committed to the client.
The reason being, that the for loop is causing a ton of white
space to be sent to be buffered up, and at some point a
buffer size limit has been hit with only whitespace, causing
Resin to then send the HTTP headers and commit the request.
So in the for loop I can do this to fix the problem:
c:forEach items=${requestScope.getRewriteUrlsQuery.rows}
var=rewriteUrlsQuery
% response.reset(); %
/c:forEach
The question is, is there a setting in the resin.xml where I
can change the buffer size globally, or do we have to go to
modify all JSPs that potentially have this problem? Was the
default commit point changed between 3.0.x and
4.0.x, or some other architecture change, as we have never
seen this until now?*
*
Thanks,
Aaron*
*
So the code example, from a style stand-point, is almost spot on with
how have laid our model/view/controller JSPs. I don't know what a t:
library, is but I am sure its some custom way to call your model code.
We do a jsp:include instead, but it's stylistically the same -- the
model is separated from your example controller.
In a JSP-based controller we are parsing the results of the model data
into a hashmap and then processing the elements in the hashmap to
determine if we need to redirect before we call the view. So our
controller looks like:
jsp:include page=/model/grab-data.sql/
%-- Process the results of the model --%
c:forEach items=${requestScope.hashMap.values()} var=rewriteUrlsQuery
/c:forEach
c:choose
c:when test=${redirect == 'true'}
c:redirect ...
/c:when
c:otherwise
jsp:include page=/view/.../
/c:otherwise
/c:choose
So I am not quite tracking with you on what we need to differently in
our controller? We are trying to do a redirect before we get to the
view layer, as you suggest, and as your code is suggesting.
Right or wrong, this is a style we have used in several places, and
instead of modifying a lot of code it would be much easier if we can
simply change the buffer size commit point. We definitely didn't intend
to exploit a bug, we are just trying to follow easy to maintain good MVC
practices and ran into this hiccup.
Fortunately through all of our testing this is the only show stopper for
us from rolling out to the newest version of Resin 4.0.5 with our
existing code base.
Thanks for you help,
Aaron
[Resin-interest] Resin-pro-4.0.5: JSSE + cipher-suites
Is there any documentation for using the cipher-suites tag? Instead of explicitly listing ciphers we do want, is there a way to list cipher-suites you want to exclude? Google isn't helping me find such an animal, so I am guess that it's not possible? Thanks, Aaron ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin-pro-4.0.5: JSSE + cipher-suites
Perfect. I was able to work out what seems to be a reasonable list, if anybody here needs it for PCI compliance. It's probably not perfect, so if anyone sees any issues with it, please let me know: cipher-suitesSSL_RSA_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA/cipher-suites Aaron On 3/25/2010 3:59 PM, Emil Ong wrote: Hi Aaron, Not at the moment, but it's certainly possible. I filed a feature bug for it: http://bugs.caucho.com/view.php?id=3970 Thanks, Emil On Thu, Mar 25, 2010 at 02:34:33PM -0500, Aaron Freeman wrote: Is there any documentation for using the cipher-suites tag? Instead of explicitly listing ciphers we do want, is there a way to list cipher-suites you want to exclude? Google isn't helping me find such an animal, so I am guess that it's not possible? Thanks, Aaron ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Resin-Pro-4.0.5 Admin
Since we are upgrading from pro-3.0.23 to pro-4.0.5, we thought we would take advantage of the resin-admin stuff. However the docs aren't clear on how that's supposed to happen. This page says nothing about what to install: http://caucho.com/resin-4.0/admin/resin-admin.xtp And this page seems to elude that I have to install another product? I could have sworn we had this working in 4.0.0 without installing Quercus. http://caucho.com/resin-4.0/admin/resin-admin-console.xtp Since /resin-admin is just a web-app implemented with Quercus/PHP, enabling it is just adding an appropriate web-app tag. Hopefully this is just a documentation error? If so how do we get the admin running? If not, is it really worth installing and working through a whole new package and all the configuration overhead and learning curve that comes with it? Thanks, Aaron ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin-Pro-4.0.5 Admin
On 3/24/2010 1:15 PM, Rick Mann wrote:
On Mar 24, 2010, at 09:07:07, Aaron Freeman wrote:
Since we are upgrading from pro-3.0.23 to pro-4.0.5, we thought we would
take advantage of the resin-admin stuff. However the docs aren't clear
on how that's supposed to happen. This page says nothing about what to
install: http://caucho.com/resin-4.0/admin/resin-admin.xtp
And this page seems to elude that I have to install another product? I
could have sworn we had this working in 4.0.0 without installing
Quercus. http://caucho.com/resin-4.0/admin/resin-admin-console.xtp
Odd, when I untar resin-pro-4.0.5 and look in the php/admin directory
from the example block on the second link above:
web-app id=/resin-admin root-directory=${resin.home}/php/admin
The php directory doesn't exist. Let me hunt around a bit now that I know it
should be there somewhere.
Aaron
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin-Pro-4.0.5 Admin
On 3/24/2010 2:00 PM, Bill Au wrote:
It is part of resin 4.x. Make sure you have the following in your
resin.xml:
web-app id=/resin-admin root-directory=${resin.root}/doc/admin
prologue
resin:set var=resin_admin_external value=false/
resin:set var=resin_admin_insecure value=true/
/prologue
/web-app
If you want to use a hostname other than localhost to access the UI,
then you will have to set resin_admin_external to true.
I have been looking at it since I am upgrading from 3.0 to 4 too. It
looks very good. Be sure to check it out. It is nice that a lot of
monitoring stuff that we have had to add on top of resin is now part
of it.
Bill
On Wed, Mar 24, 2010 at 2:15 PM, Rick Mann rm...@latencyzero.com
mailto:rm...@latencyzero.com wrote:
On Mar 24, 2010, at 09:07:07, Aaron Freeman wrote:
Since we are upgrading from pro-3.0.23 to pro-4.0.5, we thought
we would
take advantage of the resin-admin stuff. However the docs
aren't clear
on how that's supposed to happen. This page says nothing about
what to
install: http://caucho.com/resin-4.0/admin/resin-admin.xtp
And this page seems to elude that I have to install another
product? I
could have sworn we had this working in 4.0.0 without installing
Quercus. http://caucho.com/resin-4.0/admin/resin-admin-console.xtp
Quercus is part of Resin 4.x. You get it for free.
--
Rick
Ahhh ... that's slightly different than the documentation. It says
/php/admin and yours says /doc/admin. Let me try that.
Scott, you might want to have the documentation updated if that's the
difference.
Thanks,
Aaron
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] CanDI unable to inject @Stateless
Can you show your resin-web.xml?
The first thing that leaps out at me (and may be okay, but looks odd)
is: com.caucho.config.ConfigException:
*foo.HelloServlet.personService*:
javax.enterprise.inject.UnsatisfiedResolutionException: Can't find a
bean for 'interface *foo.PersonService*'.
Aaron
On 3/23/2010 12:52 PM, smallufo wrote:
In Resin 4.0.4
I follow this step :
http://www.caucho.com/resin/doc/resin-ejb.xtp#Hello, World
http://www.caucho.com/resin/doc/resin-ejb.xtp#Hello,%20World
public interface PersonDao {
//... methods...
}
@Stateless
public class PersonServiceImpl implements PersonService , Serializable {
@Inject
private PersonDao personDao;
...
}
The dao can be injected to Servlet WITHOUT a @Stateless annotation ,
but when add @Stateless , it throws :
com.caucho.config.ConfigException: foo.HelloServlet.personService:
javax.enterprise.inject.UnsatisfiedResolutionException: Can't find a
bean for 'interface foo.PersonService' because no beans implementing
that class have been registered with the injection manager
InjectManager[web-app:http://test.smallufo.com/testapp-1].
at
com.caucho.config.ConfigException.create(ConfigException.java:102)
at
com.caucho.config.ConfigException.create(ConfigException.java:125)
at
com.caucho.config.inject.InjectionTargetImpl$FieldInjectProgram.inject(InjectionTargetImpl.java:809)
at
com.caucho.config.inject.InjectionTargetImpl.inject(InjectionTargetImpl.java:266)
at
com.caucho.server.dispatch.ServletConfigImpl.createServletImpl(ServletConfigImpl.java:1260)
at
com.caucho.server.dispatch.ServletConfigImpl.createServlet(ServletConfigImpl.java:1142)
at
com.caucho.server.dispatch.ServletFilterChain.doFilter(ServletFilterChain.java:98)
at
com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:183)
at
com.caucho.server.webapp.AccessLogFilterChain.doFilter(AccessLogFilterChain.java:103)
at
com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:286)
at
com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:780)
at
com.caucho.server.connection.TcpConnection.dispatchRequest(TcpConnection.java:600)
at
com.caucho.server.connection.TcpConnection.handleRequestsImpl(TcpConnection.java:566)
at
com.caucho.server.connection.TcpConnection.handleRequests(TcpConnection.java:519)
at
com.caucho.server.connection.TcpConnection$AcceptTask.doTask(TcpConnection.java:1100)
at
com.caucho.server.connection.TcpConnection$ConnectionReadTask.runThread(TcpConnection.java:1037)
at
com.caucho.server.connection.TcpConnection$AcceptTask.run(TcpConnection.java:1068)
at
com.caucho.util.ThreadPool$PoolThread.runTasks(ThreadPool.java:901)
at com.caucho.util.ThreadPool$PoolThread.run(ThreadPool.java:866)
Caused by: javax.enterprise.inject.UnsatisfiedResolutionException:
Can't find a bean for 'interface foo.PersonService' because no beans
implementing that class have been registered with the injection
manager InjectManager[web-app:http://test.smallufo.com/testapp-1].
at
com.caucho.config.inject.InjectManager.unsatisfiedException(InjectManager.java:1389)
at
com.caucho.config.inject.InjectManager.resolveByInjectionPoint(InjectManager.java:1545)
at
com.caucho.config.inject.InjectManager.resolveByInjectionPoint(InjectManager.java:1523)
at
com.caucho.config.inject.InjectManager.getInjectableReference(InjectManager.java:1476)
at
com.caucho.config.inject.InjectionTargetImpl$FieldInjectProgram.inject(InjectionTargetImpl.java:805)
... 16 more
Http[2] HTTP/1.1 500 Internal Server Error
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] New 4.0.5 install constantly dropping connections on unloaded server
Rick, Out of curiosity did you trying running a vanilla version of 4.0.5 without compiling (using Java sockets instead of the native sockets)? I am curious if you still have the issue with it uncompiled. Aaron On 3/23/2010 2:15 PM, Rick Mann wrote: On Mar 23, 2010, at 12:10:35, Scott Ferguson wrote: Rick Mann wrote: Scott, I've opened a bug for my 4.0.5 woes, including the config file and logs from my much more modern Open Solaris machine: http://bugs.caucho.com/view.php?id=3960 Thanks for the detailed bug report. We're not seeing the behavior here yet, but the details should help track down the differences. Did the way I built and installed it have anything to do with the flakiness? No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.791 / Virus Database: 271.1.1/2765 - Release Date: 03/23/10 02:33:00 ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Conditionalizing rewrite rules based on file/directory?
On this link there is resin:IfFileExists tag, but I am thinking what you want to do is more simple than that, if you want to elaborate: http://caucho.com/resin-4.0/admin/http-rewrite.xtp Aaron On 3/21/2010 3:03 PM, Rick Mann wrote: With my WordPress installation, I need to redirect some kinds of posts to /index.php. I currently have these two rules: forward regexp=[0-9]+/.* target=/index.php/ forward regexp=^/about/? target=/index.php/ The first redirects URIs that match /year/month/post-name The second redirects the one and only page I have currently, the about page. Under Apache, the rewrite rules can be conditionalized to say, redirect according to this rule only if the resource pointed to by they URI is not an actual file or directory. Is there any way to do that in Resin? TIA, ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Classpath Question
Ah excellent catch. I just copied those from my 3.0 startup script and
what you said makes complete sense. I will revisit each parameter
carefully.
Thanks,
Aaron
On 3/22/2010 10:20 AM, Bill Au wrote:
The command line arguments for starting Resin 4.0.x only applied to
the watchdog and NOT the actual resin process itself. JVM command
line arguments are specified in resin.xml. For example, in the
command above, $JAVA_MX and $JAVA_MS applies to the watchdog only. I
wouldn't increase the default 32m max heap size of the watchdog since
it does need much memory.
Bill
On Fri, Mar 19, 2010 at 5:53 PM, Aaron Freeman
aaron.free...@layerz.com mailto:aaron.free...@layerz.com wrote:
It's working now. For completeness and to help others moving from
3.0.x
to 3.1.x or 4.0.x you should change your startup script from this
style
(which relies on a wrapper.pl http://wrapper.pl):
$RESIN_HOME/bin/httpd.sh -verbose \
-J-server \
-J-Xmx$JAVA_MX \
-J-Xms$JAVA_MS \
-J-verbose:gc \
-J-XX:MaxGCPauseMillis=5000 \
-J-XX:GCTimeRatio=19 \
-J-XX:+PrintGCTimeStamps \
-J-Djava.security.egd=/dev/urandom \
-J-cp=/opt/server/java/test.jar \
-server-root $SERVER_ROOT \
-Dresin.home=/opt/resin-pro-3.1.9 \
-conf /opt/server/conf/resin.xml \
$1
To something like this:
$JAVA_HOME/bin/java \
-server \
-Xmx$JAVA_MX \
-Xms$JAVA_MS \
-Djava.util.logging.manager=com.caucho.log.LogManagerImpl \
-Djava.security.egd=/dev/urandom \
-Dresin.home=${RESIN_HOME} \
-jar ${RESIN_HOME}/lib/resin.jar \
-conf ${SERVER_ROOT}/conf/resin.xml \
$*
And by the way that magically fixed my resin:type problem as well.
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Resin 4.0.5 production/stable?
I just noticed that resin-pro-3.1.10 no longer says latest stable, or whatever it used to say. Is 4.0.5 now considered stable and production ready? Aaron ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Bug in Resin 4.0.x (and 3.1.x)?
On 3/22/2010 1:11 PM, Scott Ferguson wrote:
Aaron Freeman wrote:
This page says that I can obfuscate a password in the resin.xml file,
but doesn't appear to work. It works in 3.0.23, but stopped working in
3.1.x and 4.0.x. We use this feature, not to protect the password on
the server, but to make sure it isn't accidentally transmitted in
clear-text by mistake when sharing our resin.xml files with consultants,
via email, etc:
http://www.caucho.com/resin/admin/database-pool-config.xtp#Protecting%20the%20database%20password
Here is the error I am getting. I have tried in resin-pro-4.0.2,.4, and
.5, and resin-pro-3.1.9:
/opt/server/conf/resin.xml:44: resin:type=com.encryption.Password is
an unexpected attribute inpassword.
42:key-store-typejks/key-store-type
43:key-store-file/opt/sendthisfile/server/ssl.kdb/key-store-file
44:password resin:type=com.encryption.Passwordabcdefg/password
45:/jsse-ssl
46:/http
Any thoughts?
Thanks. That's a documentation issue.
The resin:type has been replaced by a more general CanDI syntax, which
looks like:
password xmlns:encryption=urn:java:com.encryption
encryption:Passwordabcdefg/encryption:password
/password
In other words, the custom class now has its own XML tag instead of the
resin:type syntax.
(Unfortunately, it was not possible for us to keep the old resin:type
for backwards compatibility, because that would have complicated the key
underlying configuration too much.
Ok, so I thought what you were saying is that this:
password xmlns:encryption=urn:java:com.encryption
encryption:Passwordabcdefg/encryption:password
/password
is a drop-in replacement for this:
password resin:type=com.encryption.Passwordabcdefg/password
but apparently I think you are trying to tell me that we need to change
our Java source code somehow, based on getting this when trying to start
Resin:
/opt/server/conf/resin.xml:47: unable to create attribute
SetterAttribute[public void
com.caucho.vfs.JsseSSLFactory.setPassword(java.lang.String)] for
com.caucho.vfs.jssesslfact...@6779e6 and
QName[{http://caucho.com/ns/resin}password]
So is there a link that you can point me to in order to give me a clue
in what I need to do to modify our source to handle this new syntax?
Thanks,
Aaron
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin 4.0.5 production/stable?
I noticed that, which was another reason I thought I should ask before going nuts on 4.0.5. Aaron On 3/22/2010 2:08 PM, Rick Mann wrote: I'm sure having a lot of problems with 4.0.5 that I don't have with 4.0.4 (which has different problems). I haven't been able to determine if I'm just doing something wrong, but it seems flaky, at best. On Mar 22, 2010, at 11:59:33, Aaron Freeman wrote: I just noticed that resin-pro-3.1.10 no longer says latest stable, or whatever it used to say. Is 4.0.5 now considered stable and production ready? Aaron ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Bug in Resin 4.0.x (and 3.1.x)?
On 3/22/2010 2:29 PM, Scott Ferguson wrote:
Aaron Freeman wrote:
Ok, so I thought what you were saying is that this:
password xmlns:encryption=urn:java:com.encryption
encryption:Passwordabcdefg/encryption:password
/password
is a drop-in replacement for this:
password resin:type=com.encryption.Passwordabcdefg/password
Yes, it should be a direct replacement. (The internal implementation is
a bit tricky, though.)
but apparently I think you are trying to tell me that we need to change
our Java source code somehow, based on getting this when trying to start
Resin:
/opt/server/conf/resin.xml:47: unable to create attribute
SetterAttribute[public void
com.caucho.vfs.JsseSSLFactory.setPassword(java.lang.String)] for
com.caucho.vfs.jssesslfact...@6779e6 and
QName[{http://caucho.com/ns/resin}password]
So is there a link that you can point me to in order to give me a clue
in what I need to do to modify our source to handle this new syntax?
Let me check. I tested the replacement againstdatabase. I'll see why
it's causing trouble with jsse.
Ok, here is the full http block I am using, in case its out of date for
some reason (I am using the block directly from our working 3.0.23
implementation verbatim, with your recommended tweak):
http address=* port=443
jsse-ssl
key-store-typejks/key-store-type
key-store-file/opt/server/security/ssl.kdb/key-store-file
password xmlns:encryption=urn:java:com.encryption
encryption:Passwordabcdefg/encryption:Password
/password
/jsse-ssl
/http
- Aaron
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Bug in Resin 4.0.x (and 3.1.x)?
On 3/22/2010 3:44 PM, Scott Ferguson wrote: Aaron Freeman wrote: Ok, here is the full http block I am using, in case its out of date for some reason (I am using the block directly from our working 3.0.23 implementation verbatim, with your recommended tweak): http address=* port=443 jsse-ssl key-store-typejks/key-store-type key-store-file/opt/server/security/ssl.kdb/key-store-file password xmlns:encryption=urn:java:com.encryption encryption:Passwordabcdefg/encryption:Password /password /jsse-ssl /http What I've found is that if the XML namespace forencryption:* isn't right, i.e. not urn:java:..., you'll get that cryptic error message. If it's right, it's working for me. I'm working on first getting a better error message, and second seeing if there are other failure cases. Man, I don't see how I am blowing it then. Does this look right: password xmlns:encryption=urn:java:[full package, not including the class] encryption:[class name]abcdefg/encryption:[class name] /password Where the [full package, not including the class] would be something like java.util and the class name would be something like Hashmap with an uppercase first character like classes normally are capitalized? If so, I am a bit baffled. Aaron ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Classpath Question
Resin version: resin-pro-3.1.9 I am trying to convert my resin-pro-3.0.23 startup scripts and resin.conf file to work with resin-pro-3.1.9. It's close, but there is a small error. I am trying to build a start script similar to: $RESIN_HOME/bin/httpd.sh -verbose \ -J-server \ -J-Xmx$JAVA_MX \ -J-Xms$JAVA_MS \ -J-verbose:gc \ -J-XX:MaxGCPauseMillis=5000 \ -J-XX:GCTimeRatio=19 \ -J-XX:+PrintGCTimeStamps \ -J-Djava.security.egd=/dev/urandom \ -J-cp=/opt/server/java/test.jar \ -server-root $SERVER_ROOT \ -Dresin.home=/opt/resin-pro-3.1.9 \ -conf /opt/server/conf/resin.xml \ $1 But when I launch it, it fails on this line in the resin.xml: /opt/server/conf/resin.xml:41: java.lang.ClassNotFoundException: com.encryption. Password in EnvironmentClassLoader[] 39: key-store-typejks/key-store-type 40: key-store-file/opt/server/security/ssl.kdb/key-store-file 41: password resin:type=com.encryption.Passwordabcdefgh/password 42: /jsse-ssl 43: /http How do I set my classpath such that Resin can find the com.encryption.Password class we have written, which resides in the test.jar? I have tried adding -J-cp=... and just setting the CLASSPATH environment variable in our start script, but not having any luck. I also have this in my resin.xml: resin xmlns=http://caucho.com/ns/resin; xmlns:resin=http://caucho.com/ns/resin/core; log name= level=info path=stdout:/ cluster id= library-loader path=/opt/server/java/test.jar/ Thanks, Aaron ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Classpath Question
It's working now. For completeness and to help others moving from 3.0.x
to 3.1.x or 4.0.x you should change your startup script from this style
(which relies on a wrapper.pl):
$RESIN_HOME/bin/httpd.sh -verbose \
-J-server \
-J-Xmx$JAVA_MX \
-J-Xms$JAVA_MS \
-J-verbose:gc \
-J-XX:MaxGCPauseMillis=5000 \
-J-XX:GCTimeRatio=19 \
-J-XX:+PrintGCTimeStamps \
-J-Djava.security.egd=/dev/urandom \
-J-cp=/opt/server/java/test.jar \
-server-root $SERVER_ROOT \
-Dresin.home=/opt/resin-pro-3.1.9 \
-conf /opt/server/conf/resin.xml \
$1
To something like this:
$JAVA_HOME/bin/java \
-server \
-Xmx$JAVA_MX \
-Xms$JAVA_MS \
-Djava.util.logging.manager=com.caucho.log.LogManagerImpl \
-Djava.security.egd=/dev/urandom \
-Dresin.home=${RESIN_HOME} \
-jar ${RESIN_HOME}/lib/resin.jar \
-conf ${SERVER_ROOT}/conf/resin.xml \
$*
And by the way that magically fixed my resin:type problem as well.
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin 3.0.x and PCI Compliance
Knut, Good idea on the 2.1 try. It didn't work though. I found a link for converting the cert to something compatible with OpenSSL, so I will drudge through that murky water and see what happens as a next try. Or maybe I should spend time getting the application running 4.0.2 -- assuming that I can still use the JSSE cert with it and limit the weak ciphers? Thanks, Aaron Back in the 2.1 days you could choose which to enable with attributes on the HTTP tag: http://www.caucho.com/resin-2.1/ref/port-config.xtp#http You could try, with a little luck it may still work with 3.0.x If you want to switch to OpenSSL you can extract your JSSE key/cert, although last time I tried the keytool shipped with the JDK did not offer an easy way. The solution was to use the java libraries to extract the key directly and some openssl utility to convert to the typical ascii format. -Knut On Tue, Dec 29, 2009 at 05:49, Aaron Freeman aaron.free...@layerz.com mailto:aaron.free...@layerz.com wrote: I am a bit baffled. For PCI compliance we must restrict weak ciphers, but I see no mechanism to do that with JSSE, which we have been using for years. It appears we can do this with openssl on Resin 3.0.x Is that correct? Does that mean I need to purchase a new certificate or can we easily switch to openssl using the certificate we already have. Did the person's query about fixing JSSE's cipher-suite issue in Resin 3.1.x get resolved in Resin 4.0.2? Thanks, Aaron ___ resin-interest mailing list resin-interest@caucho.com mailto:resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin 3.1: resin:import of jvm-args
Alex wrote: I've got this, which is a slightly different but equivalent technique that doesn't require the jvm-arg tag (applicable bits only, my startup script does other things too): Just for the benefit of understanding the use case: is this to support n environments that are identical but serve two distinct purposes e.g. - development - testing - production where let's suppose 'testing' runs on a different set of servers and therefor needs different bindings and jvm arguments? Alex Yes, very close. We have several servers, a couple are web servers, a few of them are file servers, we have a remote development system and we run locally. Each of those configurations has a different set of memory constraints. Development might have 2GB, local has 500MB, web servers have 4GB, file-servers 2GB, for example. Each configuration has its own host.xml and those are loading great via resin:import--fileset, but the jvm-args can't be pushed into those classes. So I guess I just have to push them in via command line or use resin:choose in the main resin configuration file, I guess. Aaron ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Resin 3.1: resin:import of jvm-args
I have a situation where different servers should have different jvm-args, but I would like to have a single resin.xml. I tried doing a resin:import on a jvm.xml file that has just jvm-args in it, but I haven't found a combination that works. I have tried surrounding the jvm-arg tags like this: Try1: server ...jvm-args.. /server Try 2: server-default...jvm-args../server-default Try 3: server server-default...jvm-args../server-default /server Try 4: cluster server-default...jvm-args../server-default /cluster None of these are working. Any thoughts? Thanks, Aaron ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin 3.1: resin:import of jvm-args
I have a situation where different servers should have different jvm-args, but I would like to have a single resin.xml. You should be able to achieve this by using jvm-arg inside the server server id=a address=127.0.0.1 port=6800 jvm-arg-Dserver=A/jvm-arg /server server id=b address=127.0.0.1 port=6801 jvm-arg-Dserver=B/jvm-arg /server Regards, Alex Hmm, that's exactly what I tried first, as mentioned below. Can you have jvm-arg inside a resin:import'ed file? Aaron I tried doing a resin:import on a jvm.xml file that has just jvm-args in it, but I haven't found a combination that works. I have tried surrounding the jvm-arg tags like this: Try1: server ...jvm-args.. /server Try 2: server-default...jvm-args../server-default Try 3: server server-default...jvm-args../server-default /server Try 4: cluster server-default...jvm-args../server-default /cluster None of these are working. Any thoughts? Thanks, Aaron ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin 3.1: resin:import of jvm-args
You should be able to achieve this by using jvm-arg inside the server server id=a address=127.0.0.1 port=6800 jvm-arg-Dserver=A/jvm-arg /server server id=b address=127.0.0.1 port=6801 jvm-arg-Dserver=B/jvm-arg /server Regards, Alex Hmm, that's exactly what I tried first, as mentioned below. Did it work for you? What version of Resin 3.1 did you try it with if it did not work? No, none of those scenarios worked. It is with Resin 3.1.9. I was trying to resin:import the jvm-args, so I guess that's why it was failing. I have unique jvm-arg needs for different servers so I was hoping I could pull that off. Can you have jvm-arg inside a resin:import'ed file? Nope, the server does not allow resin:import tag. Alex Bummer. Thanks for clarifying. Aaron ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin 3.1: resin:import of jvm-args
The excerpt below should work and it will allow you to have all the
configuration in one file.
server id=a address=127.0.0.1 port=6800
jvm-arg-Dserver=A/jvm-arg
/server
server id=b address=127.0.0.1 port=6801
jvm-arg-Dserver=B/jvm-arg
/server
Thanks Alex. My problem isn't with multiple servers on a single machine
though. I have multiple machines, each with one server, and a few of
the machines need a different set of jvm-args. I was trying to get by
with one Resin configuration file where I could pass in a
-Dconfiguration={something} and then resin:import
path=.../${configuration}/*.xml (not literally, I was using the
fileset option of resin:import). It's working great except the one
little snafu of not being able to import jvm-arg settings.
I think I will just have to throw some resin:choose around the jvm-arg
stuff.
Aaron
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin 3.1: resin:import of jvm-args
Aaron, Maybe I am missing something, but if you can pass in -Dconfiguration=wherever to your individual machines (in your /etc/init.d/resin script or wherever, I assume?), can't you pass in your server specific JVM args there too? Rachel Probably. The configuration is passed in via an environment variable, but I could pass those in dynamically too if I have too. If we set those from our resin script will the ResinWatchdogManager pass the same values to the actual Resin server, when it launches it? I wasn't sure, so I was just going by the example resin.conf file that comes with Resin 3.1.9. Aaron ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] resin:import (3.1)
I am working with 3.1, was wondering if there is a trick to allowing recursive resin:imports? In other words I would like to resin:import a file from within another file that was already resin:imported. Thanks, Aaron ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
