from:"Steve"

I've noticed the following disparity between using two different versions of 
Tomcat when setting system properties using -D.
If I pass in -Dfoo=bar into Tomcat, and then look up the value of the 'foo' 
system property, I get different results depending on which version of Tomcat I 
use.
Tomcat 7.0.37:
System.getProperty(foo) returns bar (with quotes)
Tomcat 7.0.27:
System.getProperty(foo) returns bar (without quotes)
What is the 'correct' behaviour of this and should a bug be raised?
For reference, I'm doing this on AWS Elasticbeanstalk, so it's using 64-bit 
architecture and AWS's default distribution (which uses yum repositories though 
I don't know exactly which distro it is based on). AWS sets the parameters 
automatically form me via a nice web UI so I can't just pass in -Dfoo=bar as 
that is hidden from me.

RE: Different handling of -Dfoo=bar between versions

OK, thanks. Bug has been raised with AWS:

https://forums.aws.amazon.com/message.jspa?messageID=492286#492286

-Original Message-
From: Mikolaj Rydzewski [mailto:m...@ceti.pl] 
Sent: Thursday, October 03, 2013 3:29 PM
To: Tomcat Users List
Subject: Re: Different handling of -Dfoo=bar between versions

On 03.10.2013 16:21, Steve Arch (sarch) wrote:

 If I pass in -Dfoo=bar into Tomcat, and then look up the value of

I believe, that one has to use quotes in command line parameters to surround 
whole parameter, not only its part. Thus following are correct:

-Dfoo=bar -Dfoo=bar bar

while these are not:

-Dfoo=bar bar

Its shell's job to parse quotes, wildcards, etc.

You have to verify quotes/parameters handling on bare tomcat instance. 
Otherwise, you should raise a bug to maintainers of third party tool you use to 
manage tomcat with.

--
Mikolaj Rydzewski m...@ceti.pl

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Different handling of -Dfoo=bar between versions

AWS's tools pass the values to tomcat. I supply a set of key:value pairs and 
AWS (ElasticBeanstalk) passes them to tomcat via the command line. I can find 
out how they are set with ps and it shows that they are getting passed as:
  -Dfoo=bar

The System.getProperty call was just to demonstrate how I can retrieve them. 
Something has changed between version 24 and 37 in Tomcat when it parses the 
JVM options (-D). Mikolaj's response says that the input was illegal anyway 
(quotes have to surround the whole string: -Dfoo=bar or -Dfoo=bar bar 
rather than -Dfoo=bar bar).

As long as I know that -Dfoo=bar is illegal syntax for passing options into 
the JVM/tomcat then I can contact AWS and raise a bug with them. I just assumed 
it was something to do with tomcat as that was the only thing that had changed.

-Original Message-
From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] 
Sent: Thursday, October 03, 2013 3:44 PM
To: Tomcat Users List
Subject: RE: Different handling of -Dfoo=bar between versions

 From: Steve Arch (sarch) [mailto:sa...@cisco.com]
 Subject: Different handling of -Dfoo=bar between versions

 I've noticed the following disparity between using two different 
 versions of Tomcat when setting system properties using -D.

On the face of it, this is not related to Tomcat.

 If I pass in -Dfoo=bar into Tomcat

Exactly how are you passing this to Tomcat?

 System.getProperty(foo)

The System class is part of the JRE, not Tomcat - Tomcat itself has absolutely 
nothing to do with retrieval of system properties.  Whatever mechanism you're 
using to create the system property may have changed (e.g., different versions 
of the JRE or the JSVC/procrun wrapper).

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Different handling of -Dfoo=bar between versions

AWS's tools pass the values to tomcat.

This is not an adequate description. Tomcat must be launched by some
mechanism, such as the java executable, JSVC service wrapper, class loading
from some already running Java application, etc. What's being used here?

OK, in this case 'magic' is being used. The running process is:
/usr/lib/jvm/jre/bin/java -Dfoo=bar -XX:MaxPermSize=64m -Xmx256m -Xms256m
-classpath
/usr/share/tomcat7/bin/bootstrap.jar:/usr/share/tomcat7/bin/tomcat-juli.jar:/usr/share/java/commons-daemon.jar
-Dcatalina.base=/usr/share/tomcat7 -Dcatalina.home=/usr/share/tomcat7
-Djava.endorsed.dirs= -Djava.io.tmpdir=/var/cache/tomcat7/temp
-Djava.util.logging.config.file=/usr/share/tomcat7/conf/logging.properties
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
org.apache.catalina.startup.Bootstrap start

I supply a set of key:value pairs and AWS (ElasticBeanstalk) passes
them to tomcat via the command line.

Exactly what command line? Tomcat itself is just a set of class files, not an
executable.

Tomcat is launched by some magic which may as well boil down to launching from
the command line:
/usr/lib/jvm/jre/bin/java -Dfoo=bar -XX:MaxPermSize=64m -Xmx256m -Xms256m
-classpath
/usr/share/tomcat7/bin/bootstrap.jar:/usr/share/tomcat7/bin/tomcat-juli.jar:/usr/share/java/commons-daemon.jar
-Dcatalina.base=/usr/share/tomcat7 -Dcatalina.home=/usr/share/tomcat7
-Djava.endorsed.dirs= -Djava.io.tmpdir=/var/cache/tomcat7/temp
-Djava.util.logging.config.file=/usr/share/tomcat7/conf/logging.properties
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
org.apache.catalina.startup.Bootstrap start

Something has changed between version 24 and 37 in Tomcat when it
parses the JVM options (-D).

Again, Tomcat does not parse command line options and has absolutely nothing
to do with the JRE-supplied System class. The launcher used to start Tomcat
does parse the command line; Tomcat has no built-in launcher.

Whatever parses the command line has not changed between versions of tomcat. At
some stage, part or all of -Dfoo=bar makes its way through to Tomcat. On
tomcat 7.0.24, this results in the environment parameter 'foo' being set to
'bar'. On Tomcat 7.0.37, this results in the environment parameter 'foo' being
set to 'bar'.

Mikolaj's response says that the input was illegal anyway (quotes have
to surround the whole string: -Dfoo=bar or -Dfoo=bar bar rather
than -Dfoo=bar bar).

As long as I know that -Dfoo=bar is illegal syntax

It's not illegal (and Mikolaj never said it was), but it may not be what you
want. When quotes come after the equals sign, they are part of the value;
quotes surrounding the entire expression are stripped off by the shell when
creating the argument list for the executable.

Maybe should have said 'wrong' rather than 'illegal' but if the correct
behaviour of -Dfoo=bar is for the system parameter 'foo' to be set to 'bar'
(with the quotes) then I can raise a bug with AWS. If the correct behaviour of
is for 'foo' to be set to 'bar' (without the quotes) then I'll raise a bug with
Tomcat. TBH I don't care which is 'correct' as long as I know which one is and
can chase up the bug with someone.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Different handling of -Dfoo=bar between versions

I've found a bit more explanation. You are indeed correct - AWS has their own 
custom tomcat startup scripts that override the default tomcat startup scripts 
to handle the quotes. The yum update reverts to the default tomcat scripts and 
introduces the ambiguity.

Thanks for the help.

Steve

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Thursday, October 03, 2013 4:25 PM
To: Tomcat Users List
Subject: Re: Different handling of -Dfoo=bar between versions

Steve,

On 10/3/13 11:12 AM, Steve Arch (sarch) wrote:
 AWS's tools pass the values to tomcat.
 
 This is not an adequate description.  Tomcat must be launched by some 
 mechanism, such as the java executable, JSVC service wrapper, class 
 loading from some already running Java application, etc.  What's 
 being used here?
 
 OK, in this case 'magic' is being used. The running process is:
 
 /usr/lib/jvm/jre/bin/java -Dfoo=bar -XX:MaxPermSize=64m -Xmx256m 
 -Xms256m -classpath 
 /usr/share/tomcat7/bin/bootstrap.jar:/usr/share/tomcat7/bin/tomcat-jul
 i.jar:/usr/share/java/commons-daemon.jar

 
-Dcatalina.base=/usr/share/tomcat7 -Dcatalina.home=/usr/share/tomcat7
 -Djava.endorsed.dirs= -Djava.io.tmpdir=/var/cache/tomcat7/temp
 -Djava.util.logging.config.file=/usr/share/tomcat7/conf/logging.proper
 ties

 
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
 org.apache.catalina.startup.Bootstrap start

It's clear that Tomcat's bundled startup scripts are not in use, here.
Id so, there would be a -Dnop on the command line that is a hack to prevent a 
broken command-line when no logging configuration has been specified (which is 
the case above).

I don't have enough experience with jsvc to know what the command-line looks 
like when its in use... you can easily check for the parent process for the JVM 
and see if it's something like jsvc -- though it could have been re-renamed 
by Amazon.

 Something has changed between version 24 and 37 in Tomcat when it 
 parses the JVM options (-D).
 
 Again, Tomcat does not parse command line options and has absolutely 
 nothing to do with the JRE-supplied System class.  The launcher used 
 to start Tomcat does parse the command line; Tomcat has no built-in 
 launcher.
 
 Whatever parses the command line has not changed between versions of 
 tomcat. At some stage, part or all of -Dfoo=bar makes its way 
 through to Tomcat. On tomcat 7.0.24, this results in the environment 
 parameter 'foo' being set to 'bar'. On Tomcat 7.0.37, this results in 
 the environment parameter 'foo' being set to 'bar'.

Given that it's not Tomcat scripts, it's unlikely to have been affected 
directly by the upgrade in Tomcat version. Instead, you are probably seeing 
some environmental change that you may otherwise be unaware of: Amazon changed 
something, and it happened at the same time the Tomcat upgrade occurred.

I think logging a bug with Amazon was appropriate.

-chris
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Different handling of -Dfoo=bar between versions

I meant to. For some reason when I hit 'reply' it replied to only you rather 
than the whole mailing list as it had previously done. Apologies.

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Thursday, October 03, 2013 6:00 PM
To: Steve Arch (sarch); Tomcat Users List
Subject: Re: Different handling of -Dfoo=bar between versions

Steve,

Please post-back to the list instead of individual members of the community. 
The Tomcat users' list isn't a place to get hooked-up with people who can help 
you... it's to get help from the community. By replying to me privately you are 
1) robbing yourself of the wisdom of other members and b) robbing those other 
members of your own comments.

On 10/3/13 12:42 PM, Steve Arch (sarch) wrote:
 Your guess was correct. AWS uses a custom launch script that gets 
 configured after tomcat is installed. When an update is installed, it 
 trashes the customisation (renaming the start script in
 /etc/init.d/tomcat7) and reverts to tomcat's default behaviour.
 That’s why I (incorrectly) believed that it was a change in the tomcat 
 versions.

 Full explanation (and fix for EB users at the bottom) here: 
 https://forums.aws.amazon.com/message.jspa?messageID=460080

It looks like the real solution can be found here:
https://forums.aws.amazon.com/message.jspa?messageID=418307#460080

-chris

RE: TCNative with FIPS OpenSSL throws fingerprint error in FIPS mode

2013-06-28 Thread Steve Nickels

  I ran the openssl utility on the same system as Tomcat, and Process
  Explorer shows that its copy of libeay32.dll stays at the correct
  address. Additionally, I tested the FIPS-compatible libeay32.dll on
  a different server with Tomcat, and had the same problem. This seems
  to indicate that the memory address issue is specific to Tomcat, not
  the server.
 
  Or running within a JVM which has a significant amount of native code
  that gets loaded first, which may cause the loader to re-locate the
  library when it finally gets loaded.
 
  Any interest in trying some Java-based testing using libtcnative?
 
  I'm game, if you let me know what you'd like me to do. : )
 
 All you should have to do is write a small Java program that calls
 AprLifecycleListener.lifecycleEvent with an event of type
 BEFORE_INIT_EVENT.
 
 You'll of course have to call things like setFIPSMode(true), etc.
 
 I wonder if you did that without the rest of Tomcat loaded if anything would
 change. I would bet that it's more likely that the bulk of the JVM is causing
 the re-location of the library than anything else.

You are right. Even with that simple program the OpenSSL library gets rebased.


  I'm curious: what base address did you use when you changed it?
 
  The one that worked for me was 0x6FB0.
 
 Did you just choose one randomly?

Most of the other memory addresses in the process seemed to be at the 
0x6xxx range, so I just tried adding 6 to the beginning of the default 
memory address, and it worked.


 I wonder if you follow the suggestions from the aforementioned thread for
 re-building everything with the /FIXED switch. That seems to have fixed
 everyone's issues, but you have to be sure to build everything very carefully
 or one component can still be relocatable. tcnative of course does not care.

I may still be doing something wrong, but I still haven't been able to get this 
switch to work. I added it to the LFLAGS set in the OpenSSL build, but 
libeay32.dll still gets rebased when running through tcnative.


--Steve Nickels
Ipswitch, Inc.

RE: TCNative with FIPS OpenSSL throws fingerprint error in FIPS mode

2013-06-18 Thread Steve Nickels

  Do you think there are ways it could be improved? Better error
  checking, etc.? I implemented it as simply as I possibly could.
 
  The biggest problem seems to be that something in Tomcat on Windows
  is interfering with OpenSSL's normal base address request (0xFB0).
  Normally this doesn't matter, but with the FIPS build, if the base
  address of the library is moved from what it expects, the result is a
  fingerprint error when FIPS mode is enabled.
 
 This could be a problem on *NIX as well -- any library may be re-located by
 the loader for any reason.

It's possible this could be a problem on *NIX, but it's my understanding that 
this error is pretty specific to Windows. The documentation for OpenSSL FIPS 
says that the FIPS_R_FINGERPRINT_DOES_NOT_MATCH_NONPIC_RELOCATED error code is 
a Microsoft Windows specific error.


  I ran the openssl utility on the same system as Tomcat, and Process
  Explorer shows that its copy of libeay32.dll stays at the correct
  address. Additionally, I tested the FIPS-compatible libeay32.dll on a
  different server with Tomcat, and had the same problem. This seems to
  indicate that the memory address issue is specific to Tomcat, not the
  server.
 
 Or running within a JVM which has a significant amount of native code that
 gets loaded first, which may cause the loader to re-locate the library when it
 finally gets loaded.
 
 Any interest in trying some Java-based testing using libtcnative?

I'm game, if you let me know what you'd like me to do. : )


  I can't tell from Process Explorer why libeay32.dll is being rebased
  (I didn't see any other libraries under tomcat7.exe that were
  obviously taking up the same address space). I think it's going to
  take someone with more experience with both Windows and Tomcat than
 I
  to figure that one out. I suppose it might be worthy of a bug report,
  at least.
 
 That would be good -- bug reports have more visibility than mailing list 
 posts,
 and it's a good place to collect information all in one place.

I submitted bug 55113 for this. 
(https://issues.apache.org/bugzilla/show_bug.cgi?id=55113)


 I'm curious: what base address did you use when you changed it?

The one that worked for me was 0x6FB0.


  If the fix for the memory rebasing issue ends up being that OpenSSL
  needs to be configured with a different base address, that would be
  good to include in the build documentation for tcnative.
  The file \jni\native\srclib\BUILDING would be a good place for such a
  note. But, if the interfering Tomcat piece were to be found and
  resolved, you wouldn't need it.
 
 I suspect this is an OS-related thing that Tomcat can't really affect.
 Note that (other than tcnative and the win32 service-launcher), Tomcat
 doesn't have any native code at all, so it can't really affect this kind of 
 stuff.
 Tomcat just issues a System.loadLibrary() call and lets the JVM and OS take
 over.
 
  With my test application, the original base address was not being
  changed by the OS, according to process explorer, which is why it
  worked with the original build.
 
  Thanks for your help!
 
  No problem. If there were any other gotchas you found when building
  tcnative/FIPS/win32 could you let us know? Actually, creating a Wiki
  page is easy to do and you could help others who are trying to do the
  same thing.
 
  One minor issue I found when building tcnative on Windows was that
  the BUILDING file in the \jni\native directory in
  tomcat-native-1.1.27-win32-src.zip appears to contain UNIX build
  instructions. This probably isn't appropriate, since the zip file is
  specific to win32.
 
 That's a good point. Could you log that in Bugzilla as well? There are
 (brief) building instructions on http://tomcat.apache.org/native-doc/
 but they should probably also be in the BUILDING file.

Submitted bug 55114 for this. 
(https://issues.apache.org/bugzilla/show_bug.cgi?id=55114)


  If there's a good place to put a wiki page about this, let me know,
  and I can try to add something.
 
 Really anywhere under http://wiki.apache.org/tomcat/FAQ would be great.
 If I were looking for information about this, I'm not sure where I'd look 
 first.
 Perhaps under Security?

If I get a chance, I'll try and add something here.


--Steve Nickels
Ipswitch, Inc.

RE: TCNative with FIPS OpenSSL throws fingerprint error in FIPS mode

2013-06-13 Thread Steve Nickels

  I notice that Tomcat distributes openssl.exe and not openssl.dll (or
  similar). Are you building openssl.exe or openssl.dll when you build
  OpenSSL?
 
  Building OpenSSL on Windows results in three distributable files:
  libeay32.dll, ssleay32.dll, and openssl.exe. I copy the first two into
  Tomcat\bin, along with tcnative-1.dll, in order to make OpenSSL
  available to tcnative. It also results in libeay32.lib and
  ssleay32.lib, which are used in the tcnative compile process.
 
 What happens is you put openssl.exe in there alongside the .dll files?

Nothing different. Openssl.exe is simply the openssl utility program, and it is 
the libeay32.dll and ssleay32.dll libraries that provide the underlying 
functionality.


 With your test program, was anything in the PATH (or current
 directory) other than the two .dll files? (I'm just trying to figure out why
 Tomcat ships with openssl.exe at all... I thought it was all 
 statically-linked).

Only libeay32.dll and ssleay32.dll were in the same directory as my test 
program.

My guess is that openssl.exe ships with Tomcat to allow users to create and 
manage SSL server certificates, as a helpful utility. I believe you are correct 
that the tcnative build that ships with Tomcat statically links the OpenSSL 
libraries, as my copy of Tomcat did not have libeay32.dll or ssleay32.dll, but 
still was able to provide SSL services through the original tcnative library.


 I presume you are not building a statically-linked tcnative.dll (which would
 include the OpenSSL code), right?

I believe so, but am not positive. It seems the Visual Studio tcnative build 
statically links the APR library, but it doesn't seem to work unless 
libeay32.dll and ssleay32.dll are present, so I think that means OpenSSL is not 
statically linked.


--Steve Nickels
Ipswitch, Inc.

RE: TCNative with FIPS OpenSSL throws fingerprint error in FIPS mode

2013-06-13 Thread Steve Nickels

I figured out the problem. The error was due to my system rebasing the 
libeay32.dll library from its desired base address of 0xFB0. According to 
OpenSSL documents, this is supposed to generate a specific error message of 
FIPS_R_FINGERPRINT_DOES_NOT_MATCH_NONPIC_RELATED, but because I wasn't seeing 
that, I didn't think that was the problem.

However, process explorer showed that the base address of libeay32.dll in the 
tomcat7.exe process was not at its correct base address. I recompiled OpenSSL 
with a new base address, verified that the new dll wasn't being rebased, and 
then turned on FIPS mode, and it worked.

With my test application, the original base address was not being changed by 
the OS, according to process explorer, which is why it worked with the original 
build.

Thanks for your help!

--Steve Nickels,
Ipswitch, Inc.



 -Original Message-
 From: Christopher Schultz [mailto:ch...@christopherschultz.net]
 Sent: Thursday, June 13, 2013 9:17 AM
 To: Tomcat Users List
 Subject: Re: TCNative with FIPS OpenSSL throws fingerprint error in FIPS
 mode
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 Steve,
 
 On 6/12/13 6:54 PM, Steve Nickels wrote:
  I'm fairly confident that the OpenSSL library I'm using is valid and
  uncorrupted (I've used a couple different copies: an existing set of
  binaries being used successfully in another product internally, and
  a newly built version which I have successfully used the openssl
  utility against, without error).
 
  Can you write a simple C program to link against OpenSSL and try to
  start it in FIPS mode? Does that work without error? Feel free to
  just steal code from tcnative to put-together a Frankenstein's
  monster of code just to see if it works.
 
  I've done so, and verified that my OpenSSL build seems to be working
  correctly, both in FIPS mode and not. My test program creates SHA-1
  and MD5 hashes of a simple string value. With FIPS mode off, both
  hashes are returned. With FIPS mode on, the SHA-1 hash is returned,
  and the MD5 hash generates the expected disabled for fips error.
  There was no error at the point of FIPS_mode_set(1), which seems to
  indicate that the self tests passed. This matches what I saw when I
  used the openssl.exe utility that was compiled with OpenSSL (version
  OpenSSL 1.0.1c-fips 10 May 2012).
 
  Using this same OpenSSL build in tcnative, however, results in the
  fingerprint error when Tomcat starts up with FIPS mode enabled.
 
 
  My assumption is that I'm not building/linking OpenSSL correctly
  into tcnative.
 
  ...and you are building tcnative by hand because the OpenSSL Tomcat
  provides is not build with FIPS compatibility, right? You will have
  to make sure you have a FIPS-compatible OpenSSL (please post the
  result of openssl.exe version) and you will definitely have to
  re-build tcnative against it because otherwise all the FIPS stuff
  will generate errors before even trying to call FIPS_mode_set on
  OpenSSL.
 
  Correct. I get the expected FIPS not available error when I turn on
  FIPS mode using the stock tcnative-1.dll library that comes with
  Tomcat. The FIPS-compatible OpenSSL build I have reports as OpenSSL
  1.0.1c-fips 10 May 2012.
 
 
  I notice that Tomcat distributes openssl.exe and not openssl.dll (or
  similar). Are you building openssl.exe or openssl.dll when you build
  OpenSSL?
 
  Building OpenSSL on Windows results in three distributable files:
  libeay32.dll, ssleay32.dll, and openssl.exe. I copy the first two into
  Tomcat\bin, along with tcnative-1.dll, in order to make OpenSSL
  available to tcnative. It also results in libeay32.lib and
  ssleay32.lib, which are used in the tcnative compile process.
 
 What happens is you put openssl.exe in there alongside the .dll files?
 
 With your test program, was anything in the PATH (or current
 directory) other than the two .dll files? (I'm just trying to figure out why
 Tomcat ships with openssl.exe at all... I thought it was all 
 statically-linked).
 
 I presume you are not building a statically-linked tcnative.dll (which would
 include the OpenSSL code), right?
 
 - -chris
 -BEGIN PGP SIGNATURE-
 Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
 Comment: GPGTools - http://gpgtools.org
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
 
 iQIcBAEBCAAGBQJRudRfAAoJEBzwKT+lPKRYeaAP/3DLdVl6BBLAAqKMANzQE
 4rv
 uz44hZh6kpAyfE6ZKdmmm9WOw0X2g6Fq/rYDlYJlX0V/357AXQ33CttDXauU5
 eGs
 N0gjbe9E75mIm7HJlXoKnK3U4HjU2/Pc16q1jCdcu8YW3NYVyztglMbOd/hjYc+
 Z
 GRGk6Q+/qsI42As7GGMltLiO6FS+e4sgZ4fOlsppcn/w9g9GTCdENifKX1Dl851j
 8mqfNEVSrMJy1kxbXmVyvE/Nmv2eLsVZGyOAkqIMEeZFuloLuRBAK9o+EGJiL
 8Ff
 /ewNsn1G2otNVi+8TyFFrOLZPV2MyveBzNw53umjYyVkmfxKIorm5LP2peeN
 0/53
 Zg6HrF1fV4LtAsqU/GWsa3j7O87kP4f1ZyYvYb+0BEMBeZtq/XNVWhzvADj9IV9
 s
 x9QiPMVZTwZRaBO11p+mlRsam3tWWJpIGzxmUke9GHYOunKHKLed7S5ZGC
 ZV5yje
 4jozK+x5ueNHb3rh/HJIJlo4534wFTxB1L9Xuq1/WT39lYydJ4wcF+51+BYDwAM
 p

RE: TCNative with FIPS OpenSSL throws fingerprint error in FIPS mode

2013-06-13 Thread Steve Nickels

  I figured out the problem. The error was due to my system rebasing the
  libeay32.dll library from its desired base address of 0xFB0.
  According to OpenSSL documents, this is supposed to generate a
  specific error message of
  FIPS_R_FINGERPRINT_DOES_NOT_MATCH_NONPIC_RELATED, but
 because I wasn't
  seeing that, I didn't think that was the problem.
 
 Interesting. Do you think it was being swallowed-up somewhere? Like I said,
 tcnative/FIPS hasn't gotten a huge amount of exposure.

I think the error message issue might be a problem with OpenSSL itself. As far 
as I can tell, tcnative is simply parroting back the error message that OpenSSL 
gives it.


 Do you think there are ways it could be improved? Better error checking,
 etc.? I implemented it as simply as I possibly could.

The biggest problem seems to be that something in Tomcat on Windows is 
interfering with OpenSSL's normal base address request (0xFB0). Normally 
this doesn't matter, but with the FIPS build, if the base address of the 
library is moved from what it expects, the result is a fingerprint error when 
FIPS mode is enabled.

I ran the openssl utility on the same system as Tomcat, and Process Explorer 
shows that its copy of libeay32.dll stays at the correct address. Additionally, 
I tested the FIPS-compatible libeay32.dll on a different server with Tomcat, 
and had the same problem. This seems to indicate that the memory address issue 
is specific to Tomcat, not the server.

I can't tell from Process Explorer why libeay32.dll is being rebased (I didn't 
see any other libraries under tomcat7.exe that were obviously taking up the 
same address space). I think it's going to take someone with more experience 
with both Windows and Tomcat than I to figure that one out. I suppose it might 
be worthy of a bug report, at least.


 (I also noticed a small bug when checking the code around FIPS_mode_set in
 tcnative: the OpenSSL docs say that if
 FIPS_mode_set(x) is successful and x != 0, then the function returns x. The
 check in there is against 1 and not x. So that could afford to be fixed.)
 
  However, process explorer showed that the base address of libeay32.dll
  in the tomcat7.exe process was not at its correct base address. I
  recompiled OpenSSL with a new base address, verified that the new dll
  wasn't being rebased, and then turned on FIPS mode, and it worked.
 
 Wow, that could certainly confuse things.
 
 Again, I don't know anything about building on win32, but is that the kind of
 thing that we could better-document (or document /at all/) somewhere in
 the source bundle? Is there a project file that could contain such a hint 
 that a
 casual DIY user like you would have consulted?

If the fix for the memory rebasing issue ends up being that OpenSSL needs to be 
configured with a different base address, that would be good to include in the 
build documentation for tcnative. The file \jni\native\srclib\BUILDING would be 
a good place for such a note. But, if the interfering Tomcat piece were to be 
found and resolved, you wouldn't need it.


  With my test application, the original base address was not being
  changed by the OS, according to process explorer, which is why it
  worked with the original build.
 
  Thanks for your help!
 
 No problem. If there were any other gotchas you found when building
 tcnative/FIPS/win32 could you let us know? Actually, creating a Wiki page is
 easy to do and you could help others who are trying to do the same thing.

One minor issue I found when building tcnative on Windows was that the BUILDING 
file in the \jni\native directory in tomcat-native-1.1.27-win32-src.zip appears 
to contain UNIX build instructions. This probably isn't appropriate, since the 
zip file is specific to win32.

If there's a good place to put a wiki page about this, let me know, and I can 
try to add something.

--Steve Nickels
Ipswitch, Inc.

RE: TCNative with FIPS OpenSSL throws fingerprint error in FIPS mode

2013-06-12 Thread Steve Nickels

  I'm fairly confident that the OpenSSL library I'm using is valid and
  uncorrupted (I've used a couple different copies: an existing set of
  binaries being used successfully in another product internally, and a
  newly built version which I have successfully used the openssl utility
  against, without error).
 
 Can you write a simple C program to link against OpenSSL and try to start it 
 in
 FIPS mode? Does that work without error? Feel free to just steal code from
 tcnative to put-together a Frankenstein's monster of code just to see if it
 works.

I've done so, and verified that my OpenSSL build seems to be working correctly, 
both in FIPS mode and not. My test program creates SHA-1 and MD5 hashes of a 
simple string value. With FIPS mode off, both hashes are returned. With FIPS 
mode on, the SHA-1 hash is returned, and the MD5 hash generates the expected 
disabled for fips error. There was no error at the point of FIPS_mode_set(1), 
which seems to indicate that the self tests passed. This matches what I saw 
when I used the openssl.exe utility that was compiled with OpenSSL (version 
OpenSSL 1.0.1c-fips 10 May 2012).

Using this same OpenSSL build in tcnative, however, results in the fingerprint 
error when Tomcat starts up with FIPS mode enabled.


  My assumption is that I'm not building/linking OpenSSL correctly into
  tcnative.
 
 ...and you are building tcnative by hand because the OpenSSL Tomcat
 provides is not build with FIPS compatibility, right? You will have to make 
 sure
 you have a FIPS-compatible OpenSSL (please post the result of openssl.exe
 version) and you will definitely have to re-build tcnative against it because
 otherwise all the FIPS stuff will generate errors before even trying to call
 FIPS_mode_set on OpenSSL.

Correct. I get the expected FIPS not available error when I turn on FIPS mode 
using the stock tcnative-1.dll library that comes with Tomcat. The 
FIPS-compatible OpenSSL build I have reports as OpenSSL 1.0.1c-fips 10 May 
2012.


 I notice that Tomcat distributes openssl.exe and not openssl.dll (or similar).
 Are you building openssl.exe or openssl.dll when you build OpenSSL?

Building OpenSSL on Windows results in three distributable files: libeay32.dll, 
ssleay32.dll, and openssl.exe. I copy the first two into Tomcat\bin, along with 
tcnative-1.dll, in order to make OpenSSL available to tcnative. It also results 
in libeay32.lib and ssleay32.lib, which are used in the tcnative compile 
process.


--Steve Nickels
Ipswitch, Inc. 


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

TCNative with FIPS OpenSSL throws fingerprint error in FIPS mode

2013-06-11 Thread Steve Nickels

Hi all,

I've been trying to compile tcnative on Windows with a FIPS-compatible build of 
OpenSSL. I've been successful building and running tcnative this way, at least 
until I turn on FIPS mode on the AprLifecycleListener config in Tomcat.

When FIPSMode is set to off, Tomcat works fine, and SSL services operate 
correctly. When it is set to on, however, Tomcat refuses to start, and I get 
the following error in the catalina log file:

SEVERE: Failed to initialize the SSLEngine.
java.lang.Exception: error:2D06B06F:FIPS 
routines:FIPS_check_incore_fingerprint:fingerprint does not match

I'm fairly confident that the OpenSSL library I'm using is valid and 
uncorrupted (I've used a couple different copies: an existing set of binaries 
being used successfully in another product internally, and a newly built 
version which I have successfully used the openssl utility against, without 
error). My assumption is that I'm not building/linking OpenSSL correctly into 
tcnative.

So far I've tried building both the tcnative and libtcnative projects via the 
supplied Visual Studio workspace. In the former case, the APR library appears 
to statically linked into tcnative-1.dll, so I don't have to provide 
libapr-1.dll, however I do still need to provide libeay.dll and ssleay.dll. In 
the latter case, I provide libtcnative-1.dll, libapr-1.dll, and the two OpenSSL 
libraries. In both cases, it works when FIPS mode is off, but not when it is on.

Is there anything special I need to do to correctly build tcnative to support a 
FIPS-compatible OpenSSL build with FIPSMode turned on in Tomcat?

All this is using Tomcat 7.0.32, tcnative 1.1.27, APR 1.4.6, and OpenSSL both 
1.0.1c and 1.0.1e, on 32-bit Windows Server 2008.

Thanks!

--Steve Nickels
Ipswitch, Inc.

RE: Procrun and Tomcat service/OS shutdown on Windows

2013-03-21 Thread Thomas, Steve

Following up...

-Original Message-
From: Harris, Jeffrey E. [mailto:jeffrey.har...@mantech.com] 
Sent: Thursday, March 14, 2013 12:52 PM
To: Tomcat Users List
Subject: RE: Procrun and Tomcat service/OS shutdown on Windows

(snip)

Finally you might also want to try delaying the shutdown timer on the system to 
give Tomcat and/or HSQLDB more time to shutdown.  It might be possible that it 
is taking longer than the 12 seconds Windows allows by default for a service to 
shutdown.  That timer can be changed at 
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control (WaitToKillServiceTimeout 
value; the data is in milliseconds).  However, Windows 7 and Windows Server 
2008 R2 need a hotfix to change this setting (see 
http://support.microsoft.com/kb/2549760).

Jeffrey Harris
-

Jeffrey -

Thanks again for your suggestions.

Our customer is indeed running Win7 professional, so I passed this on.  The 
SERVICE_ACCEPT_PRESHUTDOWN is interesting for a longer-term fix, if we modified 
the commons-daemon code ourselves.  

On another note, I corresponded with the HSQLDB maintainer and he told me that 
if the shutdown is interrupted, the database can be corrupted.  He is plugging 
various holes in this area, but is not yet taking advantage of any native 
support for transactional disk writes that might prevent that sort of thing.  
Wondering if any of the other embedded db's (Derby or H2) use them...  'More to 
investigate.

Regards,

Steve
This message is intended only for the named recipient. If you are not the 
intended recipient, you are notified that disclosing, copying, distributing or 
taking any action based on the contents of this information is strictly 
prohibited.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Procrun and Tomcat service/OS shutdown on Windows

2013-03-18 Thread Thomas, Steve

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Friday, March 15, 2013 3:37 PM
To: Tomcat Users List
Subject: Re: Procrun and Tomcat service/OS shutdown on Windows

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Steve,

On 3/14/13 1:21 PM, Thomas, Steve wrote:
 Thanks, Jeffrey.  That may be a possibility for the long-term.
 --Steve

Did you read Jeffrey's entire reply? He started by top-posting, but then wrote 
some much more informative comments at the end of his post.

- -chris
---

Chris -

Thanks for calling that out.  That threw me off initially, but following the 
subsequent comments in the thread, I saw that he had more points to offer and 
will be checking into them.

Much appreciated,

Steve

This message is intended only for the named recipient. If you are not the 
intended recipient, you are notified that disclosing, copying, distributing or 
taking any action based on the contents of this information is strictly 
prohibited.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Procrun and Tomcat service/OS shutdown on Windows

2013-03-15 Thread Thomas, Steve

-Original Message-
From: Harris, Jeffrey E. [mailto:jeffrey.har...@mantech.com] 
Sent: Thursday, March 14, 2013 4:11 PM
To: Tomcat Users List
Subject: RE: Procrun and Tomcat service/OS shutdown on Windows

 -Original Message-
 From: Konstantin Kolinko [mailto:knst.koli...@gmail.com]
 Sent: Thursday, March 14, 2013 4:01 PM
 To: Tomcat Users List
 Subject: Re: Procrun and Tomcat service/OS shutdown on Windows

 2013/3/14 Thomas, Steve stho...@vocollect.com:
  Hi -

  Running Tomcat 7.0.23 or 7.0.37 (32 or 64-bit) installed as a 
  service (either via service.bat or the exe installer) on a Windows 7 
  64-bit OS, we are seeing an issue where the Windows shutdown kills 
  Tomcat before our webapp shutdown sequence has time to execute fully.
  (Specifically, we just want to make sure our instance of HSQLDB 
  shuts down correctly, otherwise corruption can ensue.)

  Details:

  Initially we were running with 32-bit Tomcat 7.0.23 and saw that our 
  shutdown sequence was not being logged at all when one of our 
  customers shut down his laptop.  It looked like the process was just 
  being killed.  I found a commons-daemon/procrun bug and 
  corresponding fix that seemed like it should address the issue, 
  namely

  http://stackoverflow.com/questions/13578196/how-to-gracefully-
 shutdown
  -procrun/14150785#14150785

  https://issues.apache.org/jira/browse/DAEMON-274

  I subsequently upgraded Tomcat to 7.0.36 (32-bit, zip) to get the
 updated commons-daemon (http://tomcat.apache.org/tomcat-7.0-
 doc/changelog.html), but to no avail.  I thought perhaps the 32-bit 
 Tomcat/64-bit OS might be a disconnect, so I installed the 64-bit 
 version, but got the same result.  In short, it looks like we're 
 either doing something wrong with our code, or there's a new wrinkle 
 in the OS-service handshaking, or the bug wasn't fixed 
 correctly...maybe in that order.

  Details below on how our code manifested the problem as well as 
  other
 steps to reproduce.

  Our database shutdown code is located in the destroy() function of a
 class implementing org.springframework.beans.factory.DisposableBean.  
 I added a Thread.sleep(5 min) call to reproduce it on my machine.  As 
 long as I shut down the service through the Services panel on Windows, 
 the shutdown sequence fully executes (and takes 5 min, as expected).
 But if I just shut down Windows, the sequence is interrupted.

 1. From the above I would say that is a Windows feature, that it does 
 not wait for service to shutdown properly.

 I'd look into Windows support and MSDN, whether it is a configuration 
 issue or something that be workaround by proper coding.

I proposed three options to Steve to change the Windows configuration to either 
allow more time, or to make Tomcat shutdown dependent on the database shutdown, 
or both.

 2. On the Shutdown tab of the procrun service configuration dialog
 (Tomcat7w.exe) there is Timeout field.

 I have 0 (sec) there.

A good option, but it will not necessarily override the Windows default of 12 
seconds to shut down a service.

Jeffrey Harris

This e-mail and any attachments are intended only for the use of the 
addressee(s) named herein and may contain proprietary information. If you are 
not the intended recipient of this e-mail or believe that you received this 
email in error, please take immediate action to notify the sender of the 
apparent error by reply e-mail; permanently delete the e-mail and any 
attachments from your computer; and do not disseminate, distribute, use, or 
copy this message and any attachments.

-

Sorry, Jeffrey -- and thanks for pointing out your suggestions again -- I only 
saw your topmost comment last time around establishing a dependency on HSQLDB.  
I will check out your other options.

Regards,

Steve
This message is intended only for the named recipient. If you are not the 
intended recipient, you are notified that disclosing, copying, distributing or 
taking any action based on the contents of this information is strictly 
prohibited.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Procrun and Tomcat service/OS shutdown on Windows

2013-03-15 Thread Thomas, Steve

-Original Message-
From: Howard W. Smith, Jr. [mailto:smithh032...@gmail.com] 
Sent: Friday, March 15, 2013 12:11 AM
To: Tomcat Users List
Subject: Re: Procrun and Tomcat service/OS shutdown on Windows

On Thu, Mar 14, 2013 at 12:00 PM, Thomas, Steve stho...@vocollect.comwrote:

 Running Tomcat 7.0.23 or 7.0.37 (32 or 64-bit) installed as a service 
 (either via service.bat or the exe installer) on a Windows 7 64-bit 
 OS, we are seeing an issue where the Windows shutdown kills Tomcat 
 before our webapp shutdown sequence has time to execute fully.

(Specifically, we just want to make sure our instance of HSQLDB shuts down
 correctly, otherwise corruption can ensue.)

Few months ago, my web app was running on Windows Server 2003 R2, 32-bit Client 
JVM and Tomcat versions 7.0.34 and 7.0.35. Within the last 3 months, my web app 
has been running on Windows Server 2008 R2, 64-bit Server JVM, and Tomcat 
version 7.0.35 and 7.0.37 (since I am running TomEE 1.5.2+).

anyway, Windows shutdown and restarted itself because of Windows Updates 
(automatic updates) and i have experienced at least 1 power outage due to 
storm(s), and my Apache Derby (embedded) has not corrupted yet, at all.

My manager has had our app and HSQLDB running for a while on his laptop and 
hasn't seen an issue, either.  Our customer had several shutdowns where 
everything was fine (even though the shutdown sequence wasn't even started) and 
then had a couple where we had gotten so far as to issue the SHUTDOWN command 
to HSQLDB and then the database came back corrupt on the next startup. 

Thanks for your input...still reviewing the posts today.

Regards,

Steve

This message is intended only for the named recipient. If you are not the 
intended recipient, you are notified that disclosing, copying, distributing or 
taking any action based on the contents of this information is strictly 
prohibited.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Procrun and Tomcat service/OS shutdown on Windows

2013-03-14 Thread Thomas, Steve

Hi -

Running Tomcat 7.0.23 or 7.0.37 (32 or 64-bit) installed as a service (either
via service.bat or the exe installer) on a Windows 7 64-bit OS, we are seeing
an issue where the Windows shutdown kills Tomcat before our webapp shutdown
sequence has time to execute fully. (Specifically, we just want to make sure
our instance of HSQLDB shuts down correctly, otherwise corruption can ensue.)

Details:

Initially we were running with 32-bit Tomcat 7.0.23 and saw that our shutdown
sequence was not being logged at all when one of our customers shut down his
laptop. It looked like the process was just being killed. I found a
commons-daemon/procrun bug and corresponding fix that seemed like it should
address the issue, namely

http://stackoverflow.com/questions/13578196/how-to-gracefully-shutdown-procrun/14150785#14150785

https://issues.apache.org/jira/browse/DAEMON-274

I subsequently upgraded Tomcat to 7.0.36 (32-bit, zip) to get the updated
commons-daemon (http://tomcat.apache.org/tomcat-7.0-doc/changelog.html), but to
no avail. I thought perhaps the 32-bit Tomcat/64-bit OS might be a disconnect,
so I installed the 64-bit version, but got the same result. In short, it looks
like we're either doing something wrong with our code, or there's a new wrinkle
in the OS-service handshaking, or the bug wasn't fixed correctly...maybe in
that order.

Details below on how our code manifested the problem as well as other steps to
reproduce.

Our database shutdown code is located in the destroy() function of a class
implementing org.springframework.beans.factory.DisposableBean. I added a
Thread.sleep(5 min) call to reproduce it on my machine. As long as I shut down
the service through the Services panel on Windows, the shutdown sequence fully
executes (and takes 5 min, as expected). But if I just shut down Windows, the
sequence is interrupted.

(As an aside, I don't expect the shutdown to take anywhere near that long in
practice, but wanted to make sure the problem manifested itself so that I could
address the bug. We are seeing this with a decent customer test machine, but I
can't reproduce it on my machine w/o changes.)

Thinking it might be Spring, I moved the shutdown delay to a
ServletContextListener. contextDestroyed() method. Same effect.

I moved the delay again, and reproduced the same problem in a standalone
servlet that overrides HttpServlet.destroy(). I've posted the code at the link
below:

http://pastebin.com/yYgrQ2sE

This is the output recorded in the stdout log file for an OS shutdown, and then
a shutdown of the service by hand. We, of course, favor the second. :-)

2013-03-14 10:05:40 Commons Daemon procrun stdout initialized
StatusServlet.init()
Entering StatusServlet.destroy()
Simulating long shutdown sequence.

2013-03-14 10:12:29 Commons Daemon procrun stdout initialized
StatusServlet.init()
Entering StatusServlet.destroy()
Simulating long shutdown sequence.
Simulation complete--sequence finished.
Exiting StatusServlet.destroy()

Can we guarantee that Windows won't just kill our Tomcat process and
potentially corrupt our database? That's the question.

I'd be grateful for some help on this. Thanks for your time and attention.

Steve T
This message is intended only for the named recipient. If you are not the
intended recipient, you are notified that disclosing, copying, distributing or
taking any action based on the contents of this information is strictly
prohibited.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Procrun and Tomcat service/OS shutdown on Windows

2013-03-14 Thread Thomas, Steve

Unfortunately, that appears to be the case with HSQLDB.  We maintain a set of 
nightly backups to address cases like those you've cited; however, if we can 
avoid issues arising from just shutting down the OS, that would help.

Regards,

Steve

-Original Message-
From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] 
Sent: Thursday, March 14, 2013 1:00 PM
To: Tomcat Users List
Subject: RE: Procrun and Tomcat service/OS shutdown on Windows

 From: Thomas, Steve [mailto:stho...@vocollect.com]
 Subject: Procrun and Tomcat service/OS shutdown on Windows

 Can we guarantee that Windows won't just kill our Tomcat process and 
 potentially corrupt our database?

If the integrity of your database depends on an orderly shutdown sequence, you 
need a better database.  What happens if there's a power outage?  What about 
some other abrupt hardware or software failure?

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

This message is intended only for the named recipient. If you are not the 
intended recipient, you are notified that disclosing, copying, distributing or 
taking any action based on the contents of this information is strictly 
prohibited.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Procrun and Tomcat service/OS shutdown on Windows

2013-03-14 Thread Thomas, Steve

Thanks, Jeffrey.  That may be a possibility for the long-term.  --Steve

-Original Message-
From: Harris, Jeffrey E. [mailto:jeffrey.har...@mantech.com] 
Sent: Thursday, March 14, 2013 12:52 PM
To: Tomcat Users List
Subject: RE: Procrun and Tomcat service/OS shutdown on Windows

Edit the registry so Tomcat depends on the HSQLDB shutdown.  This only works if 
HSQLDB is also started as a service.

Jeffrey Harris

 -Original Message-
 From: Thomas, Steve [mailto:stho...@vocollect.com]
 Sent: Thursday, March 14, 2013 12:00 PM
 To: users@tomcat.apache.org
 Subject: Procrun and Tomcat service/OS shutdown on Windows

 Hi -

 Running Tomcat 7.0.23 or 7.0.37 (32 or 64-bit) installed as a service 
 (either via service.bat or the exe installer) on a Windows 7 64-bit 
 OS, we are seeing an issue where the Windows shutdown kills Tomcat 
 before our webapp shutdown sequence has time to execute fully.  
 (Specifically, we just want to make sure our instance of HSQLDB shuts 
 down correctly, otherwise corruption can ensue.)

 Details:

 Initially we were running with 32-bit Tomcat 7.0.23 and saw that our 
 shutdown sequence was not being logged at all when one of our 
 customers shut down his laptop.  It looked like the process was just 
 being killed.  I found a commons-daemon/procrun bug and corresponding 
 fix that seemed like it should address the issue, namely

 http://stackoverflow.com/questions/13578196/how-to-gracefully-shutdown
 -
 procrun/14150785#14150785

 https://issues.apache.org/jira/browse/DAEMON-274

 I subsequently upgraded Tomcat to 7.0.36 (32-bit, zip) to get the 
 updated commons-daemon (http://tomcat.apache.org/tomcat-7.0-
 doc/changelog.html), but to no avail.  I thought perhaps the 32-bit 
 Tomcat/64-bit OS might be a disconnect, so I installed the 64-bit 
 version, but got the same result.  In short, it looks like we're 
 either doing something wrong with our code, or there's a new wrinkle 
 in the OS-service handshaking, or the bug wasn't fixed 
 correctly...maybe in that order.

 Details below on how our code manifested the problem as well as other 
 steps to reproduce.

 Our database shutdown code is located in the destroy() function of a 
 class implementing org.springframework.beans.factory.DisposableBean.  
 I added a Thread.sleep(5 min) call to reproduce it on my machine.  As 
 long as I shut down the service through the Services panel on Windows, 
 the shutdown sequence fully executes (and takes 5 min, as expected).
 But if I just shut down Windows, the sequence is interrupted.

 (As an aside, I don't expect the shutdown to take anywhere near that 
 long in practice, but wanted to make sure the problem manifested 
 itself so that I could address the bug.  We are seeing this with a 
 decent customer test machine, but I can't reproduce it on my machine 
 w/o
 changes.)

 Thinking it might be Spring, I moved the shutdown delay to a 
 ServletContextListener. contextDestroyed() method.  Same effect.

 I moved the delay again, and reproduced the same problem in a 
 standalone servlet that overrides HttpServlet.destroy().  I've posted 
 the code at the link below:

 http://pastebin.com/yYgrQ2sE

 This is the output recorded in the stdout log file for an OS shutdown, 
 and then a shutdown of the service by hand.  We, of course, favor the 
 second. :-)

 2013-03-14 10:05:40 Commons Daemon procrun stdout initialized
 StatusServlet.init()
 Entering StatusServlet.destroy()
 Simulating long shutdown sequence.

 2013-03-14 10:12:29 Commons Daemon procrun stdout initialized
 StatusServlet.init()
 Entering StatusServlet.destroy()
 Simulating long shutdown sequence.
 Simulation complete--sequence finished.
 Exiting StatusServlet.destroy()

 Can we guarantee that Windows won't just kill our Tomcat process and 
 potentially corrupt our database?  That's the question.

 I'd be grateful for some help on this.  Thanks for your time and 
 attention.

 Steve T
 This message is intended only for the named recipient. If you are not 
 the intended recipient, you are notified that disclosing, copying, 
 distributing or taking any action based on the contents of this 
 information is strictly prohibited.

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Edit the service entry in the registry (under 
HKEY_Local_Machine\system\currentcontrolset\services\Tomcat Service Name) so 
Tomcat depends on HSQLDB.  This only works if HSQLDB is also started as a 
service.  If HSQLDB is started some other way (i.e., by the Tomcat web app), 
you can try and install it as a service using the srvany utility (or possibly 
the sc utility).

If you can configure Tomcat to be dependent on HSQLDB, this will also force 
HSQLDB to start before Tomcat.

There is a method discussed at 
http://blogs.technet.com/b/askperf/archive/2008/02/04/ws2008-service-shutdown-and-crash

RE: Tomcat upgrade -SSL handshake failure?

2013-02-19 Thread Thomas, Steve

-Original Message-
From: Thomas, Steve [mailto:stho...@vocollect.com] 
Sent: Thursday, February 14, 2013 4:38 PM
To: Tomcat Users List
Subject: RE: Tomcat upgrade -SSL handshake failure?

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Thursday, February 14, 2013 11:41 AM
To: Tomcat Users List
Subject: Re: Tomcat upgrade -SSL handshake failure?

[[snip]]

Please report back what you've found. Others may be going crazy with similar 
situations.

- -chris

-

Yep, will do.  So far we've tried changing the ciphers by adding the following 
to our HTTPS connector

ciphers=SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, 
TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, 
TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, 
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA

but so far that has not worked.  My next step is to crank up the logging on 
Python's urllib2 with 

http://stackoverflow.com/a/4404838/1387355

to see if that can shed any light. Our automation team is also looking into 
moving to Python 3.3 to see if that can resolve the issue.

Thanks again for your interest and help.  More later.

Steve T


-

UPDATE: 
Just to rehash, our Python test framework started getting intermittent

urlopen error [Errno 1] _ssl.c:503: error:14094410:SSL 
routines:SSL3_READ_BYTES:sslv3 alert handshake failure

errors after we upgraded to Tomcat 10.0.35.  Chris caught the fact that we had 
also upgraded Java to version 7, and that actually turned out to be the problem 
in conjunction with the version of Python we are using.  Tomcat has more to do 
with the solution than the problem.

Last time I posted, I had a good lead on a resolution which involved specifying 
a subset of SSL ciphers.  That change didn't work, but it turns out that I 
misread part of the StackOverflow post on Python 2.7's lack of support for 
certain (sometimes preferred) ciphers provided in Java 7.  I started over, 
hunted around, and found the list of default-enabled ciphers and eliminated all 
the Diffie-Hellman ciphers until the test framework can be upgraded to Python 
3.3.   Here are the details:

Default Enabled Cipher Suites in Java 7
See 
http://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
TLS_ECDHE_RSA_WITH_RC4_128_SHA
SSL_RSA_WITH_RC4_128_SHA
TLS_ECDH_ECDSA_WITH_RC4_128_SHA
TLS_ECDH_RSA_WITH_RC4_128_SHA
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
SSL_RSA_WITH_RC4_128_MD5
TLS_EMPTY_RENEGOTIATION_INFO_SCSV2

Cipher List w/o DHE-related Ciphers
See http://stackoverflow.com/a/14224821/1387355
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
SSL_RSA_WITH_RC4_128_SHA
TLS_ECDH_ECDSA_WITH_RC4_128_SHA
TLS_ECDH_RSA_WITH_RC4_128_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
SSL_RSA_WITH_RC4_128_MD5
TLS_EMPTY_RENEGOTIATION_INFO_SCSV2

These are added to the SSL Connector node as attribute 

 ciphers=TLS_RSA_WITH_AES_256_CBC_SHA256, 
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384, 
TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, 
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256

RE: Tomcat upgrade -SSL handshake failure?

2013-02-14 Thread Thomas, Steve

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Thursday, February 14, 2013 11:41 AM
To: Tomcat Users List
Subject: Re: Tomcat upgrade -SSL handshake failure?

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Steve,

On 2/13/13 4:04 PM, Thomas, Steve wrote:
 A coworker just found this: 
 http://stackoverflow.com/questions/14167508/intermittent-sslv3-alert-h
 andshake-failure-under-python

Interesting.

I wonder if this has to do with renegotiation: that might account for the 
apparent randomness.

Are you making lots of individual connections from a single python process, or 
are these one-time requests from separate processes?

 which looks promising and explains the intermittent behavior.  We are 
 going to try to limit the ciphers to see if that fixes things.

Please report back what you've found. Others may be going crazy with similar 
situations.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEAREIAAYFAlEdE6UACgkQ9CaO5/Lv0PDoEACeLqKOeq3qxqsCHXLRsgYuDyj/
qwEAnAmvOndCnWtrYgU0hxV/LcKirjbz
=rAhy
-END PGP SIGNATURE-

-

Yep, will do.  So far we've tried changing the ciphers by adding the following 
to our HTTPS connector

ciphers=SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, 
TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, 
TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, 
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA

but so far that has not worked.  My next step is to crank up the logging on 
Python's urllib2 with 

http://stackoverflow.com/a/4404838/1387355

to see if that can shed any light. Our automation team is also looking into 
moving to Python 3.3 to see if that can resolve the issue.

Thanks again for your interest and help.  More later.

Steve T

This message is intended only for the named recipient. If you are not the 
intended recipient, you are notified that disclosing, copying, distributing or 
taking any action based on the contents of this information is strictly 
prohibited.

RE: Tomcat upgrade -SSL handshake failure?

2013-02-13 Thread Thomas, Steve

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Wednesday, February 13, 2013 10:52 AM
To: Tomcat Users List
Subject: Re: Tomcat upgrade -SSL handshake failure?

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Steve,

On 2/12/13 9:52 AM, Thomas, Steve wrote:
 Hi. We have been running Tomcat 7.0.23 in our test environment until 
 recently, then upgraded to 7.0.35. After the upgrade, our tests 
 started failing intermittently with

 urlopen error [Errno 1] _ssl.c:503: error:14094410:SSL
 routines:SSL3_READ_BYTES:sslv3 alert handshake failure

That looks like a load of fun.

[[snip]]

It's more likely that the JVM is more strict. Did you upgrade the JVM as well?

 If it isn't Tomcat--if something else must have changed--what would be 
 the most likely explanation?

*shrug*

I think you need more data on the situations where this actually
occurs: what URL, which port, etc. When you hit your service, you are hitting 
these servers directly, right -- that is, there isn't a load-balancer or 
anything like that in between your client and your server (as configured above)?

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEAREIAAYFAlEbtrUACgkQ9CaO5/Lv0PD0uwCeKg6VFK3IQZIiEt1GqireVHuC
2HAAoIvnJGon20Kl7Ief6tWFY/gf4jCi
=D9lF
-END PGP SIGNATURE-

-

Chris:  You're right that we did upgrade our JVM as well; I should have 
mentioned that.  I will follow up on the remainder of your email later, but in 
the meantime wanted to say thanks and good catch on the JVM!

Regards,

Steve

This message is intended only for the named recipient. If you are not the 
intended recipient, you are notified that disclosing, copying, distributing or 
taking any action based on the contents of this information is strictly 
prohibited.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Tomcat upgrade -SSL handshake failure?

2013-02-13 Thread Thomas, Steve

-Original Message-
From: Thomas, Steve [mailto:stho...@vocollect.com] 
Sent: Wednesday, February 13, 2013 11:10 AM
To: Tomcat Users List
Subject: RE: Tomcat upgrade -SSL handshake failure?

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Wednesday, February 13, 2013 10:52 AM
To: Tomcat Users List
Subject: Re: Tomcat upgrade -SSL handshake failure?

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Steve,

On 2/12/13 9:52 AM, Thomas, Steve wrote:
 Hi. We have been running Tomcat 7.0.23 in our test environment until 
 recently, then upgraded to 7.0.35. After the upgrade, our tests 
 started failing intermittently with

 urlopen error [Errno 1] _ssl.c:503: error:14094410:SSL
 routines:SSL3_READ_BYTES:sslv3 alert handshake failure

That looks like a load of fun.

[[snip]]

It's more likely that the JVM is more strict. Did you upgrade the JVM as well?

 If it isn't Tomcat--if something else must have changed--what would be 
 the most likely explanation?

*shrug*

I think you need more data on the situations where this actually
occurs: what URL, which port, etc. When you hit your service, you are hitting 
these servers directly, right -- that is, there isn't a load-balancer or 
anything like that in between your client and your server (as configured above)?

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEAREIAAYFAlEbtrUACgkQ9CaO5/Lv0PD0uwCeKg6VFK3IQZIiEt1GqireVHuC
2HAAoIvnJGon20Kl7Ief6tWFY/gf4jCi
=D9lF
-END PGP SIGNATURE-

-

Chris:  You're right that we did upgrade our JVM as well; I should have 
mentioned that.  I will follow up on the remainder of your email later, but in 
the meantime wanted to say thanks and good catch on the JVM!

Regards,

Steve

This message is intended only for the named recipient. If you are not the 
intended recipient, you are notified that disclosing, copying, distributing or 
taking any action based on the contents of this information is strictly 
prohibited.

-

Update: 

A coworker just found this: 
http://stackoverflow.com/questions/14167508/intermittent-sslv3-alert-handshake-failure-under-python

which looks promising and explains the intermittent behavior.  We are going to 
try to limit the ciphers to see if that fixes things.

Regards,

Steve

This message is intended only for the named recipient. If you are not the 
intended recipient, you are notified that disclosing, copying, distributing or 
taking any action based on the contents of this information is strictly 
prohibited.

Tomcat upgrade -SSL handshake failure?

2013-02-12 Thread Thomas, Steve

 to 7.0.35.  This has happened 
across multiple OS's - from Windows 2008 64-bit to RHEL5.

Could this version of Tomcat be stricter with its implementation of HTTPS, and 
that is triggering the issue?

If it isn't Tomcat--if something else must have changed--what would be the most 
likely explanation?

We would greatly appreciate any help in this matter.

Thanks and regards,

Steve T
This message is intended only for the named recipient. If you are not the 
intended recipient, you are notified that disclosing, copying, distributing or 
taking any action based on the contents of this information is strictly 
prohibited.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

BufferOverflowException in AjpNioProcessor

2013-01-17 Thread Steve Mactaggart

Hi All,

I have been hunting a BufferOverflowException on our production system for
the last while, and initially thought this was resolved by issue 53119, we
have subsequently upgraded to 7.0.32 and have still seen the issues.

Reading through the mailing list archive it seems I am not the only one
having issues with the NIO AJP Processor.

http://www.mailinglistarchive.com/html/users@tomcat.apache.org/2012-10/msg00477.html

Below is what we are seeing pretty regularly in our production environment.
 This is probably load based, as we don't seem to see this in any of our
development environments.

Caused by: java.nio.BufferOverflowException
at java.nio.HeapByteBuffer.put(HeapByteBuffer.java:183)
at
org.apache.coyote.ajp.AjpNioProcessor.output(AjpNioProcessor.java:281)
at
org.apache.coyote.ajp.AbstractAjpProcessor$SocketOutputBuffer.doWrite(AbstractAjpProcessor.java:1122)
at org.apache.coyote.Response.doWrite(Response.java:504)
at
org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:383)
at org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:342)
at
org.apache.tomcat.util.buf.IntermediateOutputStream.write(C2BConverter.java:278)
at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
at sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:282)
at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:125)
at java.io.OutputStreamWriter.write(OutputStreamWriter.java:207)
at
org.apache.tomcat.util.buf.WriteConvertor.write(C2BConverter.java:242)
at java.io.BufferedWriter.write(BufferedWriter.java:188)
at
org.apache.tomcat.util.buf.C2BConverter.convert(C2BConverter.java:125)
at
org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:476)
at
org.apache.catalina.connector.CoyoteWriter.write(CoyoteWriter.java:152)
at
org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:119)
at
org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:336)
at
org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:353)
at ... 72 more

As mentioned in the mailing list, could this be an issue that just needs to
be re-applied to the nio version of the Processor from the original issue I
thought this was?

I don't really know why this is happening, so can't provide a test case but
do know this is happening pretty regularly.

Steve

RE: Any way to deal with too many request per second?

2012-07-02 Thread Steve Millidge

Hi Brian,

You can tune the threads in the Tomcat HTTP connector. Set maximum threads to 
the maximum concurrency you are prepared to support. That way requests will 
wait until a thread becomes available.

Steve Millidge
C2B2
The Leading Independent Middleware Experts. 
T: 08450 539457 |M: 07920 100626 |W: www.c2b2.co.uk | E: smilli...@c2b2.co.uk
---
C2B2 Consulting Limited, Unit 33, Malvern Hills Science Park, Geraldine Road, 
Malvern, Worcestershire, WR14 3SZ
Registered in England and Wales: 4563419, Registered Office: Ardendale, Old 
Hollow, Malvern, Worcestershire

-Original Message-
From: Brian Braun [mailto:brianbr...@gmail.com] 
Sent: 30 June 2012 17:19
To: Tomcat Users List
Subject: Re: Any way to deal with too many request per second?

Hi Joseph,

Could you elaborate that further please? It sounds like a solution, but I 
didn't understand it.
Thanks in advance!

On Fri, Jun 29, 2012 at 8:28 PM, Joseph wutong...@gmail.com wrote:

 Try jdk build in block queue in concurrent pkg

 在 2012-6-30，7:57，Brian Braun brianbr...@gmail.com 写道：

  Hi,
 
  First of all, I'm using Ubuntu 11.1 + Tomcat 7.0.22.
 
  I created a RESTfull service. My clients are sending me HTTP 
  requests,
 and
  I return them responses. Usually, a client makes at the most 1-2 
  requests per second which is totally fine, but some clients 
  sometimes make about
 30
  requests per second and that makes my server suffer, even though I'm
 using
  a load balancer with two servers behind it. I would like to find a 
  way to deal with this. The best thing would be to delay them when 
  they do that, not to totally stop or ban them, but to slow them 
  somehow. Maybe
 creating a
  queue for them, or maybe putting them in a lower priority, until 
  they
 slow
  their requests.
  I could program this myself, but I guess there is already a solution 
  somewhere. Maybe a Tomcat valve could do it? Does anybody know one? 
  Or maybe some kind of filter? Any suggestions?
 
  Thanks in advance.

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: getting frustrated with web sockets

2012-06-06 Thread Steve Millidge

Mark,

 

I think it would be useful to get access to the session at least when you
are bootstrapping the web socket and creating the MessageInBound subclass
instance. It is very likely that a user will have accessed a web application
and logged in etc. prior to bootstrapping the websocket connection.
Therefore there's likely to be a whole bunch of useful context information I
want in my MessageInbound class when I create it.

 

Looking at the code it would be a simple change to pass Session into the
createWebSocketInbound(String subProtocol)  call.

 

Any chance we can get it added as a parameter, otherwise I'll have to hack
about with thread locals in the subclass of WebSocketServlet.

 

Cheers

 

 

Steve Millidge
Director
C2B2
The Leading Independent Middleware Experts. 
W:  http://www.c2b2.co.uk/ www.c2b2.co.uk |

SSI SecurityException

2011-10-21 Thread Steve Major

Hello folks,

I have a new Tomcat install, version 7.0.21 running on OS X 10.6.8 server (not 
using Apple's install of Tomcat, BTW), and Java 1.6.0.  I've successfully setup 
a SSI Filter before with Tomcat 6.0 a few years ago with the help of this list, 
but I'm just stuck right now.

I've uncommented the SSI Filters as described in: 
http://tomcat.apache.org/tomcat-7.0-doc/ssi-howto.html and enabled all files to 
be parsed with *

I've made my app privileged with Context antiResourceLocking=false 
privileged=true  based on the Manager app since it's already privileged.  
The META-INF directory in my app is where the context.xml is stored with this.

I'm using the Filters because I'd like it to find ssi directives within .jsp 
files.  When I launch Tomcat I see this in my logs:

SEVERE: Exception starting filter ssi
java.lang.SecurityException: Restricted class org.apache.catalina.ssi.SSIFilter
at 
org.apache.catalina.core.DefaultInstanceManager.checkAccess(DefaultInstanceManager.java:432)
at 
org.apache.catalina.core.DefaultInstanceManager.checkAccess(DefaultInstanceManager.java:421)
at 
org.apache.catalina.core.DefaultInstanceManager.loadClassMaybePrivileged(DefaultInstanceManager.java:399)
at 
org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:118)
at 
org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:252)
at 
org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:372)
at 
org.apache.catalina.core.ApplicationFilterConfig.init(ApplicationFilterConfig.java:98)
at 
org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:4584)
at 
org.apache.catalina.core.StandardContext$2.call(StandardContext.java:5262)
at 
org.apache.catalina.core.StandardContext$2.call(StandardContext.java:5257)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)

As as test, I tried using the Servlet instead of the Filter and that worked - 
at least the ssi include was shown, although Tomcat then didn't process the 
.jsp which I would expect.

I'm sure this is the way I configured it on version 6, but I may have missed 
something when I made my notes on that install.

Any direction would be appreciated.
-Steve


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: SSI SecurityException

2011-10-21 Thread Steve Major

Hello, thank you for replying!

Yes, that is the location I uncommented it since that is what their 
instructions say. I'm only deploying a single webapp, so I do not mind it being 
global.  I do see how it would be tidier in the future, if I deploy more, to do 
it on a per-app basis.  If this is contributing to my current problem, I have 
no issues doing as you suggest.

Should I copy it from the conf directory in its entirety or just a subsection 
of the file?

Thank you again.
-Steve

On Oct 21, 2011, at 2:27 PM, Konstantin Kolinko wrote:

 2011/10/21 Steve Major st...@themajorshome.com:
 Hello folks,
 
 I have a new Tomcat install, version 7.0.21 running on OS X 10.6.8 server 
 (not using Apple's install of Tomcat, BTW), and Java 1.6.0.  I've 
 successfully setup a SSI Filter before with Tomcat 6.0 a few years ago with 
 the help of this list, but I'm just stuck right now.
 
 I've uncommented the SSI Filters as described in: 
 http://tomcat.apache.org/tomcat-7.0-doc/ssi-howto.html and enabled all files 
 to be parsed with *
 
 Where did you uncomment it?
 
 You should not have modified conf/web.xml, because it applies to all
 webapps. You should copy it into your webapp only.
 
 
 Best regards,
 Konstantin Kolinko
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: SSI SecurityException

2011-10-21 Thread Steve Major

Thanks, I figured that out shortly before getting your reply.

Moving the filter and mapping into the app's web.xml has eliminated the error 
from the logs, however, the ssi still won't display a result.

By this I mean if I insert: Today is !--#echo var=DATE_LOCAL -- into my 
.jsp, when I view the page I only see Today is.

My previous experience with Apache's SSI suggests if it wasn't enabled 
correctly, I'd see Today is !--#echo var=DATE_LOCAL -- on my page because 
it just would assume that directive is text.

Assuming Tomcat follows the same, it would tell me that it is parsing it and 
for whatever reason not outputting a result.  I could be wrong.

Thank you again for your time.
-Steve


On Oct 21, 2011, at 3:01 PM, Konstantin Kolinko wrote:

 Should I copy it from the conf directory in its entirety or just a 
 subsection of the file?
 
 Only definition of the filter and its mapping.
 
 Best regards,
 Konstantin Kolinko
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Bad documentation error on Tomcat 6.0 howto site

2011-09-15 Thread Steve Cohen


There is a bad error on the Tomcat 6.0 documentation website:
http://tomcat.apache.org/tomcat-6.0-doc/manager-howto.html#Configuring_Manager_Application_Access

They give the 7.0 syntax for manager role names.  6.0 requires 
manager, not manager-gui or manager-script and it led astray for 
several hours.


Thanks.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Bad documentation error on Tomcat 6.0 howto site

2011-09-15 Thread Steve Cohen


On 09/15/2011 07:39 AM, Konstantin Kolinko wrote:

2011/9/15 Steve Cohensco...@javactivity.org:

There is a bad error on the Tomcat 6.0 documentation website:
http://tomcat.apache.org/tomcat-6.0-doc/manager-howto.html#Configuring_Manager_Application_Access

They give the 7.0 syntax for manager role names.  6.0 requires manager,
not manager-gui or manager-script and it led astray for several hours.


The documentation is correct.
You are probably using an old version of Tomcat 6 (and you are not
telling us which one).

Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



6.0.20.  Someone told me that the manager-gui, manager-script stuff was 
7.0, I switched it to manager and it worked.  So evidently, this was 
changed in a later 6.0.x version.  To me, that seems like sort of a 
major change to make in a minor upgrade version and it should at least 
be documented.  Or is the tomcat 6.0 documentation ONLY supposed to 
cover the latest release?


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Bad documentation error on Tomcat 6.0 howto site

2011-09-15 Thread Steve Cohen


On 09/15/2011 08:09 AM, Konstantin Kolinko wrote:

2011/9/15 Steve Cohensco...@javactivity.org:

6.0.20.


Yes, it is old...


  Someone told me that the manager-gui, manager-script stuff was 7.0,
I switched it to manager and it worked.  So evidently, this was changed in a
later 6.0.x version.  To me, that seems like sort of a major change to make
in a minor upgrade version and it should at least be documented.


See changelog, as well as release announcements.


  Or is the
tomcat 6.0 documentation ONLY supposed to cover the latest release?


It covers only the latest release.
The documentation for the version that you are using is included in
the download itself (see webapps/docs).

Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org




ok, thanks.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Custom Realm - Tomcat 5.5 to Tomcat 7 Migration

2011-08-19 Thread Steve Ratay

I have a custom realm that is quite complex and uses a variety of third party 
libraries, including Spring.  In Tomcat 5.5, I placed the Realm and all of the 
JARs it depended upon in the server/lib directory.  This kept these classes in 
the Catalina class loader, which was not visible to any web applications.  This 
was the perfect solution since I do not want to automatically include all of 
these JARs in the classloading hierarchy of my web applications.



Now I am trying to migrate to Tomcat 7, and having a hard time figuring out a 
way to create the same configuration.  I see that there is no longer a Catalina 
classloader or any classloader that won't be visible to the web applications.  
Is that accurate or is there some way to isolate certain JAR files and prevent 
them from being visible to my web applications?  Also, I'm thinking that 
another option could be to have a separate web application for authentication.  
Would I be able to do this and still integrate with the Realm concept in Tomcat?

As a side note, I'm working in a portal environment so I use the SSO valve and 
basically want a single point of authentication for all web applications (i.e. 
portlets) deployed in the servlet container.

Thanks, Steve

Fw: Issue with accepting IP address connections

2011-07-26 Thread Steve Allan

 Hello,
I have set up Tomcat 6.0 on a Windows 2007 server. IIS was
(and still is) installed. I have changed the port to 8081
for testing and can see the Tomcat start page at
localhost:8081.
However, I now need to set up the IP address for the server
which I thought was done through the Connector element is
the server.xml file but trying the IP address after setting
it up and restarting Tomcat gets a 'page can not be
displayed' error.

The Connector element is:
Connector port=8081 protocol=HTTP/1.1   
connectionTimeout=2          
addres=192.xxx.xx.x         
redirectPort=8443 /
 
What do I need to do to get Tomcat monitor a certain IP
address?
 
Thanks in advance,
Steve

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Authentication and roles (RFE)

2010-12-16 Thread Steve Mitchell

I would like my Tomcat instance to authenticate different roles differently.  
E.g., admins must use SSL client auth, while regular users use HTTP basic 
authentication over SSL.  This seems like a routine requirement, but it's 
unsupported in Tomcat 6 (or 7).

I have a workaround -- use an Apache reverse proxy for authentication.  The 
disadvantages are that Tomcat roles are unavailable, and admin users and 
regular users connect to the same resource with different URLs.  

The ideal solution would be to use SSL with selectable client authentication.  
In this mode, HTTP basic authentication would be skipped if the client had 
already presented a valid SSL client certificate.  Can Tomcat be made to do 
this?

  --Steve



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat5.5 MySQL14.12 java.net.SocketException: Broken pipe

2010-10-18 Thread Steve Ryder

It has been 10 days so I am declaring that Jason's suggestion did indeed 
solve the problem.

Thanks Jason.
- Original Message - 
From: Steve Ryder sry...@jsrsys.com

To: Tomcat Users List users@tomcat.apache.org
Sent: Thursday, October 07, 2010 10:03 AM
Subject: Re: Tomcat5.5 MySQL14.12 java.net.SocketException: Broken pipe

Thanks Jason.  I have added the two parameters.  Hopefully I will have 
seen the last of this error.

- Original Message - 
From: Jason Britton jbritto...@gmail.com

To: Tomcat Users List users@tomcat.apache.org
Sent: Wednesday, October 06, 2010 11:57 PM
Subject: Re: Tomcat5.5 MySQL14.12 java.net.SocketException: Broken pipe

To your mysql Resource definition below I would add
validationQuery=SELECT 1

That should prevent your application from getting handed stale db
connections from your pool.  Take a look at the testOnBorrow and
validationQuery definitions here
http://commons.apache.org/dbcp/configuration.html

Jason

On Wed, Oct 6, 2010 at 8:18 PM, Steve Ryder sry...@jsrsys.com wrote:

I am getting this during mysql connection (about once a week).
I have read the thread on MySQL forum, which has a solution, but the 
link

to the solution is broken and points back to the same page.
Suggestions have been use autoconnect=true
Another was that the server timeout was shorter than the connection
time-out.
I have the following:
In server.xml:
Connector port=80 maxHttpHeaderSize=8192
 maxThreads=192 minSpareThreads=32 maxSpareThreads=128
 enableLookups=false redirectPort=8443 acceptCount=128
 connectionTimeout=2 disableUploadTimeout=true /
In context.xml
Resource name=jdbc/MySql auth=Container type=javax.sql.DataSource
 url=jdbc:mysql://localhost.localdomain/rsa?autoReconnect=true
   factory=org.apache.commons.dbcp.BasicDataSourceFactory
 driverClassName=com.mysql.jdbc.Driver
 password=jsrsys username=jsrsys
   maxWait=1   maxActive=200  maxIdle=5
 removeAbandoned=true removeAbandonedTimeout=300 logAbandoned=true
/
Note that maxWait is 1/2 of connectionTimeout and I have
autoReconnect=true.
Any ideas.   This is low priority as users are able to reconnect by just
pressing Refresh, but I would like this to go away.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat5.5 MySQL14.12 java.net.SocketException: Broken pipe

2010-10-07 Thread Steve Ryder

Thanks Jason.  I have added the two parameters.  Hopefully I will have seen 
the last of this error.

- Original Message - 
From: Jason Britton jbritto...@gmail.com

To: Tomcat Users List users@tomcat.apache.org
Sent: Wednesday, October 06, 2010 11:57 PM
Subject: Re: Tomcat5.5 MySQL14.12 java.net.SocketException: Broken pipe

To your mysql Resource definition below I would add
validationQuery=SELECT 1

That should prevent your application from getting handed stale db
connections from your pool.  Take a look at the testOnBorrow and
validationQuery definitions here
http://commons.apache.org/dbcp/configuration.html

Jason

On Wed, Oct 6, 2010 at 8:18 PM, Steve Ryder sry...@jsrsys.com wrote:

I am getting this during mysql connection (about once a week).
I have read the thread on MySQL forum, which has a solution, but the 
link

to the solution is broken and points back to the same page.
Suggestions have been use autoconnect=true
Another was that the server timeout was shorter than the connection
time-out.
I have the following:
In server.xml:
Connector port=80 maxHttpHeaderSize=8192
 maxThreads=192 minSpareThreads=32 maxSpareThreads=128
 enableLookups=false redirectPort=8443 acceptCount=128
 connectionTimeout=2 disableUploadTimeout=true /
In context.xml
Resource name=jdbc/MySql auth=Container type=javax.sql.DataSource
 url=jdbc:mysql://localhost.localdomain/rsa?autoReconnect=true
   factory=org.apache.commons.dbcp.BasicDataSourceFactory
 driverClassName=com.mysql.jdbc.Driver
 password=jsrsys username=jsrsys
   maxWait=1   maxActive=200  maxIdle=5
 removeAbandoned=true removeAbandonedTimeout=300 logAbandoned=true
/
Note that maxWait is 1/2 of connectionTimeout and I have
autoReconnect=true.
Any ideas.   This is low priority as users are able to reconnect by just
pressing Refresh, but I would like this to go away.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Tomcat5.5 MySQL14.12 java.net.SocketException: Broken pipe

2010-10-06 Thread Steve Ryder


I am getting this during mysql connection (about once a week).
I have read the thread on MySQL forum, which has a solution, but the link 
to the solution is broken and points back to the same page.

Suggestions have been use autoconnect=true
Another was that the server timeout was shorter than the connection 
time-out.

I have the following:
In server.xml:
Connector port=80 maxHttpHeaderSize=8192
  maxThreads=192 minSpareThreads=32 maxSpareThreads=128
  enableLookups=false redirectPort=8443 acceptCount=128
  connectionTimeout=2 disableUploadTimeout=true /
In context.xml
Resource name=jdbc/MySql auth=Container type=javax.sql.DataSource
 url=jdbc:mysql://localhost.localdomain/rsa?autoReconnect=true
factory=org.apache.commons.dbcp.BasicDataSourceFactory
 driverClassName=com.mysql.jdbc.Driver
 password=jsrsys username=jsrsys
maxWait=1   maxActive=200  maxIdle=5
  removeAbandoned=true removeAbandonedTimeout=300 logAbandoned=true
/
Note that maxWait is 1/2 of connectionTimeout and I have autoReconnect=true.
Any ideas.   This is low priority as users are able to reconnect by just 
pressing Refresh, but I would like this to go away. 



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Tomcat5.5: Apache Tomcat Native library ... not found

How do it fix this? 
INFO: The Apache Tomcat Native library which allows optimal performance in 
production environments was not found on the java.library.path: 

i.e., what library is missing and/ how do I put it in the java.library.path. 
I presume an update to JAVA_OPTS in etc/init.d/tomcat5.5

Tomcat5.5: java.io.FilePermission access denied


Tomcat5.5: java.io.FilePermission access denied:
When I added the code on 02-08 it fixed the SocketPermission and
PropertyPermission exceptions for my servlets.  What am  I doing wrong that
I now get FilePermission exceptions.
I have changed Linux permissions for Data to 377.  Still get error.
But I have in policy.d/04webapps.policy file:
// == WEB APPLICATION PERMISSIONS
=
// These permissions are granted by default to all web applications
// In addition, a web application will be given a read FilePermission
// and JndiPermission for all files and directories in its document root.
grant {
   // Added by JSR 2010-09-13
permission java.io.FilePermission *, read,write;
  // Added by JSR 2010-02-08:
permission java.util.PropertyPermission *, read,write;
   permission java.net.SocketPermission*, connect,resolve;

Exception report:
Sep 30, 2010 12:05:46 PM org.apache.catalina.core.StandardWrapperValve
invoke
SEVERE: Servlet.service() for servlet jsp threw exception
java.security.AccessControlException: access denied (java.io.FilePermission
/home/sryder/app.rsoa.org/ROOT/Data/2010-09-30-at-1205.csv write)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)
at
java.security.AccessController.checkPermission(AccessController.java:427)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at java.lang.SecurityManager.checkWrite(SecurityManager.java:962)
at java.io.FileOutputStream.init(FileOutputStream.java:169)
at java.io.FileOutputStream.init(FileOutputStream.java:70)
at com.jsrsys.web.JsrLineOut.open(JsrLineOut.java:73)
at com.jsrsys.web.JsrLineOut.setName(JsrLineOut.java:118)
at org.apache.jsp.AbstractCsv_jsp._jspService(AbstractCsv_jsp.java:359)




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat5.5: java.io.FilePermission access denied

Sorry, I meant 777.   Typo on my part.Is the Java Permissions error tied 
to the file system permissions.  I really do want ALL my apps to be able to 
read and write from the file system.  I use this mainly for creating CSV 
downloads, and occasionally for reading uploaded files.


Thanks in advance for any suggestions you might have.  Since I personally 
control ALL the jsp files in all apps on this server, is there some global 
command that will allow ALL permissions for JSPs so I don't have to discover 
them one by one.  (Which is the way Tomcat 5.0 works).
- Original Message - 
From: Caldarale, Charles R chuck.caldar...@unisys.com

To: Tomcat Users List users@tomcat.apache.org
Sent: Friday, October 01, 2010 11:59 AM
Subject: RE: Tomcat5.5: java.io.FilePermission access denied



From: Steve Ryder [mailto:sry...@jsrsys.com]
Subject: Tomcat5.5: java.io.FilePermission access denied



I have changed Linux permissions for Data to 377.


If I'm reading that correctly, that means the owner can write but not read, 
and everyone else can read and write.  Sounds a bit odd...


- Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat5.5: java.io.FilePermission access denied


Thanks.  I changed the following:
# Use the Java security manager? (yes/no)  2010-10-01--change to no.
TOMCAT5_SECURITY=no

which will cause the following to NOT happen:
if [ $TOMCAT5_SECURITY = yes ]; then
JAVA_OPTS=$JAVA_OPTS -Djava.security.manager 
-Djava.security.policy=$CATALINA_BASE/conf/catalina.policy
fi

Thanks.
- Original Message - 
From: Caldarale, Charles R chuck.caldar...@unisys.com

To: Tomcat Users List users@tomcat.apache.org
Sent: Friday, October 01, 2010 1:02 PM
Subject: RE: Tomcat5.5: java.io.FilePermission access denied



From: Steve Ryder [mailto:sry...@jsrsys.com]
Subject: Re: Tomcat5.5: java.io.FilePermission access denied



Since I personally control ALL the jsp files in all
apps on this server, is there some global command
that will allow ALL permissions for JSPs so I don't
have to discover them one by one.


Then just disable the security manager.  Look at the Tomcat startup script 
you're using, and take out the java.security.manager and 
java.security.policy settings.


- Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat5.5: java.io.FilePermission access denied

AS EXPECTED this solved the problem.  All I had to do was set the file 
permissions for the file I overwrite.  The application is now working just 
fine.
- Original Message - 
From: Steve Ryder sry...@jsrsys.com

To: Tomcat Users List users@tomcat.apache.org
Sent: Friday, October 01, 2010 5:48 PM
Subject: Re: Tomcat5.5: java.io.FilePermission access denied

Thanks.  I changed the following:
# Use the Java security manager? (yes/no)  2010-10-01--change to no.
TOMCAT5_SECURITY=no

which will cause the following to NOT happen:
if [ $TOMCAT5_SECURITY = yes ]; then
JAVA_OPTS=$JAVA_OPTS -Djava.security.manager 
-Djava.security.policy=$CATALINA_BASE/conf/catalina.policy
fi

Thanks.
- Original Message - 
From: Caldarale, Charles R chuck.caldar...@unisys.com

To: Tomcat Users List users@tomcat.apache.org
Sent: Friday, October 01, 2010 1:02 PM
Subject: RE: Tomcat5.5: java.io.FilePermission access denied

From: Steve Ryder [mailto:sry...@jsrsys.com]
Subject: Re: Tomcat5.5: java.io.FilePermission access denied

Since I personally control ALL the jsp files in all
apps on this server, is there some global command
that will allow ALL permissions for JSPs so I don't
have to discover them one by one.

Then just disable the security manager.  Look at the Tomcat startup script 
you're using, and take out the java.security.manager and 
java.security.policy settings.

- Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you 
received this in error, please contact the sender and delete the e-mail 
and its attachments from all computers.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 5.5: java.io.FilePermission read access denied to logging.properties

2010-09-26 Thread Steve Ryder

Thanks.  It turns out the root cause of the error was not permissions at 
all, but another error caused by a left over web.xml reference to a class 
that did not exist.  When I discovered, and removed, that statement in the 
web.xml, the logging properties error went away as well.



- Original Message - 
From: Rainer Jung rainer.j...@kippdata.de

To: users@tomcat.apache.org
Sent: Sunday, September 26, 2010 6:50 AM
Subject: Re: Tomcat 5.5: java.io.FilePermission read access denied to 
logging.properties




On 15.09.2010 11:02, Pid wrote:

On 14/09/2010 23:35, André Warnier wrote:

Pid wrote:

On 14/09/2010 16:17, Steve Ryder wrote:

java.security.AccessControlException: access denied
(java.io.FilePermission
/home/sryder/JsrSystems.info/ROOT/WEB-INF/classes/logging.properties
read)

When I first noticed this I added the java.io.FilePermission to
catalina.policy under WEB APP PERMISSIONS
grant { // Added by JSR 2010-09-13:
  permission java.io.FilePermission *, read,write;
 // Added by JSR 2010-02-08:
  permission java.util.PropertyPermission *, read,write;
 permission java.net.SocketPermission*, connect,resolve;

I still get the error at startup!

I have no logging.properties file under either the classes or under
common/classes.
Do I need to add one?  Can it be just a blank line?


Silly question: does the file have the appropriate user permissions for
Tomcat to access it?


Considering that the OP writes, just above there, that he does not have
a file there, that does indeed sound like a silly question.


Yeah.  I completely misread that.  Maybe I need specs.


The method in the stack indicates it might be a missing permission on the 
directories. The code wants to check whether the logging.properties in the 
webapp exists, and it seems it can't read the necessary directory 
information. So


- check directory permissions for 
/home/sryder/JsrSystems.info/ROOT/WEB-INF/classes/ and above


and if that doesn't suffice

- try adding read permissions for the directories to the policy file

Regards,

Rainer

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Help with jasypt (Java Security). NoClassDefFoundError.

2010-09-24 Thread Steve Ryder


I am new to jasypt.  I have installed the commons libraries that came with
the jasypt download in Apache.../common/lib.
The class not being found is in one of the libraries.
Tomcat 5.0, Java 1.4 running on Windows.
Do I need to do something in addition to copying the jar files into
common/lib?
commons-codec-1.1.jar, commons-lang-2.1.jar, jasypt-1.6.jar from jasypt
dist.
icu4j-charsets-4_4_1_1.jar, icu4j-4_4_1_1.jar  from icu website.

Also, once I get past this error, will I need BOTH icu libraries.This
exception is on Windows
development machine.

java.lang.NoClassDefFoundError:
org/apache/commons/lang/exception/NestableRuntimeException
java.lang.ClassLoader.defineClass0(Native Method)
java.lang.ClassLoader.defineClass(ClassLoader.java:539)
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
java.net.URLClassLoader.defineClass(URLClassLoader.java:251)
java.net.URLClassLoader.access$100(URLClassLoader.java:55)
java.net.URLClassLoader$1.run(URLClassLoader.java:194)
java.security.AccessController.doPrivileged(Native Method)
java.net.URLClassLoader.findClass(URLClassLoader.java:187)
java.lang.ClassLoader.loadClass(ClassLoader.java:289)
java.lang.ClassLoader.loadClass(ClassLoader.java:235)
java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
org.jasypt.util.text.BasicTextEncryptor.init(BasicTextEncryptor.java:67)
org.apache.jsp.jasyptExample_jsp._jspService(jasyptExample_jsp.java:83)
---this is mine...
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:94)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:324)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)

Below is my  simple test servlet
page import=org.jasypt.util.text.*
String password = 2010-09-23 11:21;
String origText = 123456789abcdef,f6c;
BasicTextEncryptor textEncryptor = new
BasicTextEncryptor();textEncryptor.setPassword(password);
String quePaso = textEncryptor.encrypt(origText);
String plainText = textEncryptor.decrypt(quePaso);
out.println(password+/+origText+/+quePaso+/+plainText); 



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Help with jasypt (Java Security). NoClassDefFoundError. (works on Linux)

2010-09-24 Thread Steve Ryder

I wish that were true.  I did that (after similar advice from jasypt user 
list), did not help.  Same error.
However, I uploaded to Linux Tomcat 5.5 Java 1.5 system, restarted Tomcat, 
and it works!
Go figure.  I still have one application running on an old server at Tomcat 
5.5 Java 1.4 level.  As soon as I migrate it I will update my Windows 
environment to match.
I stayed with Tomcat 5.5 as it is the last stable release and am also at 
similar level for 1.5.


I have learned the hard way that putting up the latest release is rarely a 
good idea unless there is some compelling reason to do so.


Thanks for the advice.
- Original Message - 
From: Christopher Schultz ch...@christopherschultz.net

To: Tomcat Users List users@tomcat.apache.org
Sent: Friday, September 24, 2010 12:01 PM
Subject: Re: Help with jasypt (Java Security). NoClassDefFoundError.



-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Steve,

On 9/24/2010 12:17 PM, Steve Ryder wrote:

java.lang.NoClassDefFoundError:
org/apache/commons/lang/exception/NestableRuntimeException


This is likely to be due to your placement of libraries.

Aside from Chuck's comments (with which I completely agree: it's upgrade
time for you), I would suggest that you place /all/ libraries your web
application needs into the webapp's WEB-INF/lib directory, and not use
common/lib for any of that stuff.

Moving your libraries from the common to the webapp's lib directory is
likely to solve this problem for you.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyc2XwACgkQ9CaO5/Lv0PC34QCdHmCZ8/01n9wQD3gvKvaH2hD1
MmkAoJt6H9CxBYbRvCyeHUo7HR3OR7lr
=F5qN
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 5.5: java.io.FilePermission read access denied to logging.properties

2010-09-14 Thread Steve Ryder

java.security.AccessControlException: access denied (java.io.FilePermission 
/home/sryder/JsrSystems.info/ROOT/WEB-INF/classes/logging.properties read)

When I first noticed this I added the java.io.FilePermission 
to catalina.policy under WEB APP PERMISSIONS
grant { 
// Added by JSR 2010-09-13:
 permission java.io.FilePermission *, read,write;
// Added by JSR 2010-02-08:
 permission java.util.PropertyPermission *, read,write;
permission java.net.SocketPermission*, connect,resolve;
 
I still get the error at startup!

I have no logging.properties file under either the classes or under 
common/classes.
Do I need to add one?  Can it be just a blank line?  

Full trace follows;
Sep 13, 2010 11:17:44 PM org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/5.5
Sep 13, 2010 11:17:44 PM org.apache.catalina.core.StandardHost start
INFO: XML validation disabled
Sep 13, 2010 11:17:45 PM org.apache.catalina.core.StandardHost start
INFO: XML validation disabled
Sep 13, 2010 11:17:46 PM org.apache.commons.modeler.Registry registerComponent
SEVERE: Error registering 
Catalina:type=Valve,name=StandardContextValve,path=/,host=la.jsrsystems.info
javax.management.MBeanException: Cannot instantiate ModelMBean of class 
org.apache.commons.modeler.BaseModelMBean
 at org.apache.commons.modeler.ManagedBean.createMBean(ManagedBean.java:385)
 at org.apache.commons.modeler.Registry.registerComponent(Registry.java:835)
 at 
org.apache.catalina.core.StandardPipeline.registerValve(StandardPipeline.java:302)
 at org.apache.catalina.core.StandardPipeline.start(StandardPipeline.java:234)
 at org.apache.catalina.core.StandardContext.start(StandardContext.java:4140)
 at 
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:760)
 at org.apache.catalina.core.ContainerBase.access$0(ContainerBase.java:744)
 at 
org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:144)
 at java.security.AccessController.doPrivileged(Native Method)
 at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:738)
 at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:544)
 at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:920)
 at 
org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:883)
 at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:492)
 at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1138)
 at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311)
 at 
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:120)
 at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1022)
 at org.apache.catalina.core.StandardHost.start(StandardHost.java:736)
 at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1014)
 at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
 at org.apache.catalina.core.StandardService.start(StandardService.java:448)
 at org.apache.catalina.core.StandardServer.start(StandardServer.java:700)
 at org.apache.catalina.startup.Catalina.start(Catalina.java:552)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:295)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.apache.commons.daemon.support.DaemonLoader.start(DaemonLoader.java:177)
Caused by: java.security.AccessControlException: access denied 
(java.io.FilePermission 
/home/sryder/JsrSystems.info/ROOT/WEB-INF/classes/logging.properties read)
 at 
java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)
 at java.security.AccessController.checkPermission(AccessController.java:427)
 at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
 at java.lang.SecurityManager.checkRead(SecurityManager.java:871)
 at java.io.File.exists(File.java:700)
 at org.apache.naming.resources.FileDirContext.file(FileDirContext.java:828)
 at org.apache.naming.resources.FileDirContext.lookup(FileDirContext.java:211)
 at org.apache.naming.resources.ProxyDirContext.lookup(ProxyDirContext.java:294)
 at 
org.apache.catalina.loader.WebappClassLoader.findResourceInternal(WebappClassLoader.java:1924)
 at 
org.apache.catalina.loader.WebappClassLoader.findResource(WebappClassLoader.java:936)
 at 
org.apache.juli.ClassLoaderLogManager.readConfiguration(ClassLoaderLogManager.java:299)
 at

Re: Tomcat 5.5: java.io.FilePermission read access denied to logging.properties

2010-09-14 Thread Steve Ryder

Thanks for your response, I really do need some help.  After lots of testing 
(when mail was working), I migrated my production workload to a new server. 
Yesterday, Java Mail stopped working, I suspect because I added the wrong 
permission in the wrong place.  (see #2).

I have tried removing that, but the error still happens.HELP.

1)  There is no logging.properties file under any ROOT/WEB-INF/ classes, it
is the security check that is failing.
2)   permission java.io.FilePermission *, read,write;   was in
catalina.policy.I have been experimenting all day with alternate
permission statements.  I did notice that I should not be updating
catalina.policy so have since move the permission stuff down into policy.d
folder as recommended.  What I need to know is to WHAT DO I GIVE PERMISSION?

From the stack

com.jsrsys.web.JsrSendMail.sendMail(JsrSendMail.java:507)--- my code
gets to:
javax.activation.MailcapCommandMap.init(MailcapCommandMap.java:153)
 failing here because:
java.security.AccessControlException: access denied (java.io.FilePermission
/home/sryder/JsrSystems.info/ROOT/WEB-INF/classes/logging.properties read)
java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)3)application code in JsrSendMail has 
been working for years under Tomcat5.0and was working under Tomcat 5.5  until I apparently startedaddingpermissions 
because of a bunch of mBean failures at startup.  AfterthatMail started to fail.  Removing those permissions does not 
help.The codesnippet that fails is: msg.setSentDate(new Date());if(!connectionIsOpen) result = setTransport(); 
   if(!result.equals(OK)) return result;sysout.display(JsrSendMail--line 509: 
keepOpen=+keepOpen+ connectionIsOpen=+connectionIsOpen  +result=+result  
);msg.saveChanges();  // don'tforget this this is the linethat fails.
tr.sendMessage(msg,msg.getAllRecipients());here is the whole stack from my call to the 
securityfailurejava.security.AccessControlException: access 
denied(java.io.FilePermission/home/sryder/JsrSystems.info/ROOT/WEB-IN
F/classes/logging.properties 
read)java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)java.security.AccessController.checkPermission(AccessController.java:427)java.lang.SecurityManager.checkPermission(SecurityManager.java:532)java.lang.SecurityManager.checkRead(SecurityManager.java:871)java.io.File.exists(File.java:700)org.apache.naming.resources.FileDirContext.file(FileDirContext.java:828)org.apache.naming.resources.FileDirContext.lookup(FileDirContext.java:211)org.apache.naming.resources.ProxyDirContext.lookup(ProxyDirContext.java:294)org.apache.catalina.loader.WebappClassLoader.findResourceInternal(WebappClassLoader.java:1924)org.apache.catalina.loader.WebappClassLoader.findResource(WebappClassLoader.java:936)org.apache.juli.ClassLoaderLogManager.readConfiguration(ClassLoaderLogManager.java:299)org.apache.juli.ClassLoaderLogManager$2.run(ClassLoaderLogManager.java:273)java.security.AccessController.doPrivileged(Native
 Method)org.apache.juli.Cl
assLoaderLogManager.getClassLoaderInfo(ClassLoaderLogManager.java:270)org.apache.juli.ClassLoaderLogManager.getLogger(ClassLoaderLogManager.java:175)
 
java.util.logging.Logger.getLogger(Logger.java:255)com.sun.activation.registries.LogSupport.clinit(LogSupport.java:60)javax.activation.MailcapCommandMap.init(MailcapCommandMap.java:153)failing
 
herejavax.activation.CommandMap.getDefaultCommandMap(CommandMap.java:74)javax.activation.DataHandler.getCommandMap(DataHandler.java:167)javax.activation.DataHandler.getDataContentHandler(DataHandler.java:625)javax.activation.DataHandler.writeTo(DataHandler.java:329)javax.mail.internet.MimeUtility.getEncoding(MimeUtility.java:264)javax.mail.internet.MimeBodyPart.updateHeaders(MimeBodyPart.java:1301)javax.mail.internet.MimeBodyPart.updateHeaders(MimeBodyPart.java:1008)javax.mail.internet.MimeMultipart.updateHeaders(MimeMultipart.java:415)javax.mail.internet.MimeBodyPart.updateHeaders(MimeBodyPart.java:1287)javax.mail.internet.MimeM
essage.updateHeaders(MimeMessage.java:2072)javax.mail.internet.MimeMessage.saveChanges(MimeMessage.java:2040)com.jsrsys.web.JsrSendMail.sendMail(JsrSendMail.java:507)--- mycode- Original Message 
-From: Pid p...@pidster.comTo: TomcatUsers List users@tomcat.apache.orgSent: Tuesday, September 14, 2010 3:33PMSubject: Re: Tomcat 5.5: java.io.FilePermission read 
access deniedtologging.propertiesOn 14/09/2010 16:17, Steve Ryder wrote:java.security.AccessControlException: 
accessdenied(java.io.FilePermission/home/sryder/JsrSystems.info/ROOT/WEB-INF/classes/logging.properties read) When I first noticed this I added thejava.io.FilePermission to catalina.policy under WEB 
APP PERMISSIONS grant{ // Added by JSR 2010-09-13:  permission java.io.FilePermission *,read,write; // Added by JSR 2010-02-08:  
permissionjava.util.PropertyPermission *, read,write

Help troubleshooting SSL certificate problem

2010-08-07 Thread Steve Johnson


 Greetings,

We're developing an application on top of Tomcat.  Our incoming 
connections are always HTTPS.  We've been using the self signed cert 
that came with tcServer for testing, but now I'm trying to get our setup 
working with an officially signed certificate we just got from GoDaddy.


I've followed the GoDaddy instructions for adding a total of 4 certs 
(root + 2 intermediates + ours) to a fresh keystore file.  I used the 
same keystorePass and keyAlias values as already specified for the 
default keystore file.  I then replaced the working keystore file (with 
self signed cert) with this new keystore file and restarted Tomcat.


Once I do this, my HTTPS port stops working.  Firefox says this:

   The connection to alpha.filethis.com was interrupted while the page 
was loading.


I'm stuck at this point.  I can find no supporting information for this 
failure in Tomcat's logs.  The logs are unchanged after attempting to 
access our app via HTTPS.  I tried upping the log levels in 
logging.properties, but even after getting huge log files to be spit 
out, nothing is added to the logs in response to these erring HTTPS 
requests.


My guess is that this problem has to do with my setup not matching the 
domain name in the certificate, even though I'm coming in via that 
domain on the URL.  All the docs I've seen so far online, however, don't 
mention having to do anything special in this regard.


I'm running tcServer, which it appears is Tomcat 6.0.26.  My server.xml 
file is included at the bottom of this post.


Can anyone tell me what might be going wrong, or how to enable some sort 
of diagnostics that might tell me something about why this isn't working?


Any help would be greatly appreciated.

Take care

Steve

server.xml
==

?xml version='1.0' encoding='utf-8'?
Server port=${shutdown.port} shutdown=SHUTDOWN

Listener className=org.apache.catalina.core.JasperListener /
Listener 
className=org.apache.catalina.core.JreMemoryLeakPreventionListener /

Listener className=org.apache.catalina.mbeans.ServerLifecycleListener /
Listener 
className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener /


Listener 
className=com.springsource.tcserver.serviceability.rmi.JmxSocketListener

port=${jmx.port}
bind=127.0.0.1
useSSL=false
passwordFile=${catalina.base}/conf/jmxremote.password
accessFile=${catalina.base}/conf/jmxremote.access
authenticate=true/

Listener 
className=com.springsource.tcserver.serviceability.deploy.TcContainerDeployer 
/


GlobalNamingResources
Resource name=UserDatabase auth=Container
  type=org.apache.catalina.UserDatabase
  description=User database that can be updated and saved
  factory=org.apache.catalina.users.MemoryUserDatabaseFactory
  pathname=conf/tomcat-users.xml /
/GlobalNamingResources

Service name=Catalina

Executor name=tomcatThreadPool namePrefix=tomcat-http-- 
maxThreads=300 minSpareThreads=50/


Connector executor=tomcatThreadPool
   port=${http.port}
   protocol=org.apache.coyote.http11.Http11NioProtocol
   connectionTimeout=2
   redirectPort=${https.port}
   acceptCount=100
   maxKeepAliveRequests=15/

Connector executor=tomcatThreadPool
   port=${https.port}
   protocol=org.apache.coyote.http11.Http11NioProtocol
   connectionTimeout=2
   redirectPort=${https.port}
   acceptCount=100
   maxKeepAliveRequests=15
   keystoreFile=${catalina.base}/conf/tcserver.keystore
   keystorePass=changeme
   keyAlias=tcserver
   SSLEnabled=true
   scheme=https
   sslProtocol=TLS
   clientAuth=false
   secure=true/

Engine name=Catalina defaultHost=localhost

Realm className=org.apache.catalina.realm.UserDatabaseRealm
 resourceName=UserDatabase/

Host name=localhost  appBase=webapps
unpackWARs=true autoDeploy=true deployOnStartup=true 
deployXML=true

xmlValidation=false xmlNamespaceAware=false
/Host
/Engine
/Service
/Server










-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Two-way SSL setup as Tomcat as a client

2010-08-07 Thread Steve Johnson

 I can confirm that the Apache HTTPClient module is a good way to go.  
In fact, it works with zero configuration.  You simply give it a normal 
'https' URL, and it does the right thing automagically.


It may be that you have to do some configuration of your JDK and 
environment to have SSL capabilities available to HTTPClient, but I 
don't think so.  I don't remember ever doing that on my dev box, and I 
know for a fact that my use of HTTPClient allows HTTPS URLs with no 
additional fuss.


HTTPClient is an excellent library in general, as is most of the apache 
stuff.


Have fun!

S

On 8/7/2010 3:13 PM, yifeng wu wrote:

I see. I guess I will look into using apache httpclient or some other library 
(any recommendation?).
Webshpere actually takes care of outbound SSL connection by configuration (no 
extra coding) that's why I got confused.
Thanks for input, Chuck.

YF


From: chuck.caldar...@unisys.com
To: users@tomcat.apache.org
Date: Sat, 7 Aug 2010 11:22:41 -0500
Subject: RE: Two-way SSL setup as Tomcat as a client


From: yifeng wu [mailto:yifen...@hotmail.com]
Subject: RE: Two-way SSL setup as Tomcat as a client

I am refering two way SSL not just one way.

Irrelevant; Pid's statement still stands: it's your webapp, not Tomcat, that is 
trying to communicate with an external server. Tomcat plays no role is such a 
connection, it's entirely up to your webapp. There is nothing in Tomcat to 
configure for this, since Tomcat is not involved. You'll need to use the secure 
connection capabilities of the JRE or a 3rd-party library of your choice to do 
the negotiation.

- Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org






-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Help troubleshooting SSL certificate problem

2010-08-07 Thread Steve Johnson

 The GoDaddy instructions mostly talk about building the keystore file, 
and are very similar to that section of the document you mention.  I 
assume what you're getting at is that the instructions you mention might 
be helpful to me.  I have, unfortunately, been over those instructions 
backwards and forwards.  They don't lend any clues.


I went through those instructions when I first got SSL working.  I had 
SSL working fine.  All I did this time around was replace one keystore 
file (tcserver.keystore) with another.  I used the same password and 
alias this time around so that I could just drop in the new keystore 
without any modifications.  When I do so, my system stops working.  If I 
revert back to the original keystore containing the self-signed 
certificate, the system works fine again.


S

On 8/7/2010 3:14 PM, Hassan Schroeder wrote:

On Sat, Aug 7, 2010 at 2:20 PM, Steve Johnsonst...@parisgroup.net  wrote:


I've followed the GoDaddy instructions for adding a total of 4 certs (root +
2 intermediates + ours) to a fresh keystore file.

Do the GoDaddy instructions look anything like the Tomcat ones? :-)
http://tomcat.apache.org/tomcat-6.0-doc/ssl-howto.html




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

JNDI not available from ServletContextListener

2010-07-29 Thread Steve Mitchell

Can anybody reproduce the bug I'm getting in Tomcat 6.0.29, or is it just me?

I'm trying to access a DataSource via JNDI from a ServletContextListener.  I 
find that my InitialContext has no bindings at all in the 
ServletContextListener.contextInitialized() method.  It makes no difference 
whether I declare the DataSource in META-INF/context.xml or in conf/server.xml 
(with a ResourceLink in META-INF/context.xml).

A Bugzilla bug was filed for this behavior under Tomcat 7, and the bug was 
patched.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49132

That bug report includes a bare-bones Eclipse project that exhibited the error 
under Tomcat 7.  When I deploy that project on Tomcat 6.0.29, I get the same 
behavior that was reported under Tomcat 7, consistent with my original 
DataSource problem.

I reported my experience in Bugzilla but it was rejected.

https://issues.apache.org/bugzilla/show_bug.cgi?id=49673

Perhaps I've configured something wrong - does anybody else get the same 
behavior with the Eclipse project tomcat7-web-test under Tomcat 6.0.29?  Or 
is there something wrong with the posted project?

  --Steve

RE: JNDI not available from ServletContextListener

2010-07-29 Thread Steve Mitchell

I guess the maintainers know what they're doing, because my original DataSource 
problem turns out to be a configuration problem.  I still don't know why the 
Eclipse project fails for me, but I'm assuming it's some kind of deployment 
problem.

Thanks, case closed,
  --Steve

From: Steve Mitchell
Sent: Thursday, July 29, 2010 5:49 PM
To: 'users@tomcat.apache.org'
Subject: JNDI not available from ServletContextListener

Can anybody reproduce the bug I'm getting in Tomcat 6.0.29, or is it just me?

I'm trying to access a DataSource via JNDI from a ServletContextListener.  I 
find that my InitialContext has no bindings at all in the 
ServletContextListener.contextInitialized() method.  It makes no difference 
whether I declare the DataSource in META-INF/context.xml or in conf/server.xml 
(with a ResourceLink in META-INF/context.xml).

A Bugzilla bug was filed for this behavior under Tomcat 7, and the bug was 
patched.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49132

That bug report includes a bare-bones Eclipse project that exhibited the error 
under Tomcat 7.  When I deploy that project on Tomcat 6.0.29, I get the same 
behavior that was reported under Tomcat 7, consistent with my original 
DataSource problem.

I reported my experience in Bugzilla but it was rejected.

https://issues.apache.org/bugzilla/show_bug.cgi?id=49673

Perhaps I've configured something wrong - does anybody else get the same 
behavior with the Eclipse project tomcat7-web-test under Tomcat 6.0.29?  Or 
is there something wrong with the posted project?

  --Steve

Re: mod_jk session stickiness on failover

2010-05-18 Thread Steve Yates





G'day John, the strategy I would employ in your particular case would be
to utilise the JvmRouteBinderValve. Now the JvmRouteBinderValve was
designed to be used within a clustered environment I cannot see why it
cannot be configured stand-alone to simply detect for an incorrect route
and modify the client-side cookie appropriately.

RGS
SY

On 5/18/2010 8:35 PM, JohnRiley wrote:
 Hi,

 We are load balancing 3 non-clustered tomcat 6.0 servers with the mod_jk
 connector in apache 2.0. We have sticky sessions enabled and it works fine
 until one of the servers goes down. What happens then is that it start
 round-robin between the other two since none of them wants to accept the
 JSESSIONID with the route of the crashed tomcat server. 

 How can I make one of the other servers to create a new session with its own
 jvmRoute for that tomcat? Because right now we have a huge problem when
 taking down a server for maintenance. The user will change server on each
 request until the server that is down for maintenance is back up again.

 Do we really have to setup the tomcats in a cluster to accomplish this?

 Best Regards

 John Riley

Re: multiple form submits

2010-05-13 Thread Steve Yates

Hello Karthik,

It is a little difficult for application server such as Tomcat to
implement such validation as every request received through your
configured connector is essentially a genuine request from Tomcats point
of view. Unless you created a complex Valve of some sort which measured
the time difference between two requests from the same host to the same
URI and requested that Tomcat consider one to be a duplicate of the
other and therefore drop it, this is sort of the wrong way to approach it.

One little trick I have employed in the past is to temporarily disable
the button/link by using a little bit of Javascript not too dissimilar
to what you have done already. Without giving too much away have you
considered dynamically changing the href value of the anchor to either
nothing or an internal anchor '#' with the onClick method.

RGS
SY

On 5/13/2010 5:45 PM, Karthik Nanjangude wrote:
 Hi

 Spec :
 JDK1.5
 TOMCAT 6.0.20
 O/s windows /Linux


 Question  : My web application uses href  css based image's   for  
 transferring the request from 1 page to another
The problem is UserVisitor is  clicking the image based 
 href  MULTIPLE TIMES ( multiple clicks )

 a href=image.jsp?mult=1 id='submitButton1'  
 onClick=this.onclick=function(){return false} target=_self
class=buttonRedSmallspanSubmit Form/span/a/td

 And causes the multiple form submits.  How to prevent the same ?

 I googled / yahooed for Cross browser based  tricks to disable the multiple 
 request...Not luck so far ...

 Can some body help me if Tomcat has any special features to prevent this 
 attack ... :(




 with regards

 N.S.Karthik

Re: multiple form submits

2010-05-13 Thread Steve Yates

Karthik,

I have just re-iterated what Pid has already explained. I am not fast
enough.

+1 Pid

RGS

On 5/13/2010 6:10 PM, Pid wrote:
 On 13/05/2010 08:45, Karthik Nanjangude wrote:
   
 Hi

 Spec :
 JDK1.5
 TOMCAT 6.0.20
 O/s windows /Linux


 Question  : My web application uses href  css based image's   for  
 transferring the request from 1 page to another
The problem is UserVisitor is  clicking the image based 
 href  MULTIPLE TIMES ( multiple clicks )
 
 Why is this a problem?

   
 a href=image.jsp?mult=1 id='submitButton1'  
 onClick=this.onclick=function(){return false} target=_self
class=buttonRedSmallspanSubmit Form/span/a/td
 
 1. Unset the href value, or set it to '#image.jsp?mult=1.  You can
 always set a timer, to remove the '#' after a couple of seconds, if the
 page hasn't changed.

 2. Use a button/button instead and disable it during the first mouse
 down.

   
 And causes the multiple form submits.  How to prevent the same ?

 I googled / yahooed for Cross browser based  tricks to disable the multiple 
 request...Not luck so far ...

 Can some body help me if Tomcat has any special features to prevent this 
 attack ... :(
 
 It doesn't.


 p

Performance issues when adding Tomcat JK redirector to IIS's Default Web Site?

2010-02-15 Thread Steve Ryan

Dear All

 

I've tried googling this but can't find much, so I was hoping one of you
guys might be able to help me.

 

My web application lives under IIS's Default Web Site. It needs to use the
Tomcat JK redirector, so I have added the redirector as an ISAPI Filter on
the Default Web Site. This means any websites which live under the
Default Web Site will use the redirector. 

 

This is fine, however, there are other third-party websites which live under
IIS's Default Web Site, which means the change I made above (adding the
redirector as an ISAPI Filter on the Default Web Site) also affects these
third party websites.

 

So my question is this:

 

Are there any known performance issues with the Tomcat JK redirector, in
particular, any performance issues which could affect the third-party
websites as explained in my example above?

 

Any advice appreciated.

 

Cheers

 

Steve

RE: Performance issues when adding Tomcat JK redirector to IIS's Default Web Site?

2010-02-15 Thread Steve Ryan

Hi Peter

Thanks for your reply.

To answer your questions:

I am using IIS 6 and IIS 7.
I am using the latest version of the redirector, i.e. JK-1.2.28.

Our technical architect decided how we should use the redirector. This is
the basic design:

IIS 
- Default Web Site (ISAPI Filter = isapi_redirect.dll)
--- Virtual directory for our web application
--- Virtual directory for the redirector
--- Virtual directory for other third-party website

IIS Application Pools
- DefaultAppPool (may be used by Other third-party website)
- AppPool for our web application
- AppPool for the redirector

So as you can see, all the virtual directories live under the Default Web
Site. 

The isapi_redirect.dll is added as an ISAPI Filter for the entire Default
Web Site, which means all the virtual directories under Default Web Site
will be affected by this. My worry is it might impact Other third-party
website.

Thanks for your help.

Cheers

Steve

-Original Message-
From: peter.crowth...@googlemail.com [mailto:peter.crowth...@googlemail.com]
On Behalf Of Peter Crowther
Sent: 15 February 2010 11:47
To: Tomcat Users List
Subject: Re: Performance issues when adding Tomcat JK redirector to IIS's
Default Web Site?

Steve, you're likely to get more specific answers if you can tell us
versions: what version of the redirector, and what versions of IIS?
Also, can you tell us whose instructions you followed to get it
working, as there are some out there that are... how shall I say it...
less than ideal :-).

Cheers,

- Peter

On 15 February 2010 11:30, Steve Ryan st...@acme.ie wrote:
 Dear All



 I've tried googling this but can't find much, so I was hoping one of you
 guys might be able to help me.



 My web application lives under IIS's Default Web Site. It needs to use
the
 Tomcat JK redirector, so I have added the redirector as an ISAPI Filter on
 the Default Web Site. This means any websites which live under the
 Default Web Site will use the redirector.



 This is fine, however, there are other third-party websites which live
under
 IIS's Default Web Site, which means the change I made above (adding the
 redirector as an ISAPI Filter on the Default Web Site) also affects
these
 third party websites.



 So my question is this:



 Are there any known performance issues with the Tomcat JK redirector, in
 particular, any performance issues which could affect the third-party
 websites as explained in my example above?



 Any advice appreciated.



 Cheers



 Steve



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Performance issues when adding Tomcat JK redirector to IIS's Default Web Site?

2010-02-15 Thread Steve Ryan

Apologies, for some reason the formatting of my e-mail get messed up. I have
reformatted below:

Hi Peter

Thanks for your reply.

To answer your questions:

I am using IIS 6 and IIS 7.
I am using the latest version of the redirector, i.e. JK-1.2.28.

Our technical architect decided how we should use the redirector. This is
the basic design:

IIS 
- Default Web Site (ISAPI Filter = isapi_redirect.dll)
--- Virtual directory for our web application
--- Virtual directory for the redirector
--- Virtual directory for other third-party website

IIS Application Pools
- DefaultAppPool (may be used by Other third-party website)
- AppPool for our web application
- AppPool for the redirector

So as you can see, all the virtual directories live under the Default Web
Site. 

The isapi_redirect.dll is added as an ISAPI Filter for the entire Default
Web Site, which means all the virtual directories under Default Web Site
will be affected by this. My worry is it might impact Other third-party
website.

Thanks for your help.

Cheers

Steve

-Original Message-
From: peter.crowth...@googlemail.com [mailto:peter.crowth...@googlemail.com]
On Behalf Of Peter Crowther
Sent: 15 February 2010 11:47
To: Tomcat Users List
Subject: Re: Performance issues when adding Tomcat JK redirector to IIS's
Default Web Site?

Steve, you're likely to get more specific answers if you can tell us
versions: what version of the redirector, and what versions of IIS?
Also, can you tell us whose instructions you followed to get it
working, as there are some out there that are... how shall I say it...
less than ideal :-).

Cheers,

- Peter

On 15 February 2010 11:30, Steve Ryan st...@acme.ie wrote:
 Dear All



 I've tried googling this but can't find much, so I was hoping one of you
 guys might be able to help me.



 My web application lives under IIS's Default Web Site. It needs to use
the
 Tomcat JK redirector, so I have added the redirector as an ISAPI Filter on
 the Default Web Site. This means any websites which live under the
 Default Web Site will use the redirector.



 This is fine, however, there are other third-party websites which live
under
 IIS's Default Web Site, which means the change I made above (adding the
 redirector as an ISAPI Filter on the Default Web Site) also affects
these
 third party websites.



 So my question is this:



 Are there any known performance issues with the Tomcat JK redirector, in
 particular, any performance issues which could affect the third-party
 websites as explained in my example above?



 Any advice appreciated.



 Cheers



 Steve



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

File does not exist error - public_html/addArticle.do

I have a new website that I'm using to bring my skills up to date and 
I'm running into a file does not exist issue.


This is a very simple JSP/STRUTS application that I have working on my 
home system using NetBeans 6.8 and TomCat 5.5.28.  It is made up of a 
couple of JSP pages and a STRUTS actionform and action.  Very simple.  A 
form is displayed for the user to enter data into, a submit button is 
pressed, and a new page is then rendered that displays the input entered 
on the form.


My execution starts via a JSP named, newArticle.jsp.

This renders a form (without issue) which has a few text fields that the 
user enters data into and hits the submit button which calls html:form 
action=/addArticle.


I am now expecting a success JSP to be rendered that displays the 
information that was entered on the form.


What I'm getting is the following:

[Sat Feb 13 08:19:10 2010] [error] [client xxx.xxx.xx.xxx] File does not exist: 
/home/w1smchdj/public_html/addArticle.do


The site I'm deploying to uses TomCat 5.5.25 and when I deploy to my 
site I use CPANEL File Manager to copy the files individually rather 
than dropping a WAR file in as they do not recommend dropping in a WAR file.


I have copied the *.JSP files directly under the public_html folder of 
the site and the remainder of the components are in the WEB-INF folder 
directly under the public_html folder.


Again, this all works fine in my NetBeans / TomCat test at home.

I must not be deploying my components to the correct directory 
structure?  Or maybe I need to change my WEB.XML (which does not seem 
right as this is testing fine in NetBean / TomCat at home).


Any and all help would be greatly appreciated.







-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: File does not exist error - public_html/addArticle.do


Thanks for replying .

Yes, it is ugly I agree with that . but I'm just starting out  ... 
small steps


Anyway, I figured I'd start off with something small and easy.

I did pass a few emails back and forth with the support staff but they 
pushed it back on me ...


They told me to talk with the developer .. I laughed as I am the 
developer (Been writing code for 30+ years professionally ... mainframes).


It was kind of sad and funny in a way . these guys were in India 
somewhere and the broken English was a hilarious.  But they didn't help 
at all.


So I just figured it was very a simple thing ... I create a WEB-INF, 
populate it with all of the components that were in the directory on my 
home testing machine, and I'd be off and running.


But I can't get past the submit button  It thinks for some reason it 
needs addArticle.do.  This leads me to think the WEB-INF needs to be not 
only under the public_html directory but down further in another 
directory named for the app.  So then if I execute 
www.?.com\myApp\newArticle.jsp (where myApp is the name of the directory 
where the WEB-INF and all my other components are . that would work?


I'm just trying to trudge through this . but I wish those Rat 
b...@stards in the support staff were more help .. but what can you do


I do appreciate the help though  any ideas and suggestions at this 
point woud be great 


Thanks,

Steve



On 2/14/2010 9:55 AM, Pid wrote:

On 14/02/2010 11:58, Steve Campisano wrote:

I have a new website that I'm using to bring my skills up to date and
I'm running into a file does not exist issue.

This is a very simple JSP/STRUTS application that I have working on my
home system using NetBeans 6.8 and TomCat 5.5.28. It is made up of a
couple of JSP pages and a STRUTS actionform and action. Very simple. A
form is displayed for the user to enter data into, a submit button is
pressed, and a new page is then rendered that displays the input entered
on the form.


Tomcat != TomCat.  (Why does anyone think it's called TomCat?)


My execution starts via a JSP named, newArticle.jsp.

This renders a form (without issue) which has a few text fields that the
user enters data into and hits the submit button which calls html:form
action=/addArticle.

I am now expecting a success JSP to be rendered that displays the
information that was entered on the form.

What I'm getting is the following:

[Sat Feb 13 08:19:10 2010] [error] [client xxx.xxx.xx.xxx] File does not
exist: /home/w1smchdj/public_html/addArticle.do

The site I'm deploying to uses TomCat 5.5.25 and when I deploy to my
site I use CPANEL File Manager to copy the files individually rather
than dropping a WAR file in as they do not recommend dropping in a WAR
file.


Sounds ugly.


I have copied the *.JSP files directly under the public_html folder of
the site and the remainder of the components are in the WEB-INF folder
directly under the public_html folder.

Again, this all works fine in my NetBeans / TomCat test at home.

I must not be deploying my components to the correct directory
structure? Or maybe I need to change my WEB.XML (which does not seem
right as this is testing fine in NetBean / TomCat at home).

Any and all help would be greatly appreciated.


Without seeing the server.xml, any application context.xml or 
additional config, we're going to struggle to help you.


You may well be better off asking the site's admins for support, if 
you can't provide the above.



p

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: File does not exist error - public_html/addArticle.do


Well, I seemed to have corrected my issue 

I created a new directory under public_html and copied all of my 
componets to this directory  including WEB-INF, etc .


Did a start and stop and it worked 

Now I'm going to try and create a small MySQL database and see if I can 
CRUD this.


Thanks .. I may be back .. but on another forum 

Steve

On 2/14/2010 10:21 AM, Steve Campisano wrote:

Thanks for replying .

Yes, it is ugly I agree with that . but I'm just starting out  ... 
small steps


Anyway, I figured I'd start off with something small and easy.

I did pass a few emails back and forth with the support staff but they 
pushed it back on me ...


They told me to talk with the developer .. I laughed as I am the 
developer (Been writing code for 30+ years professionally ... 
mainframes).


It was kind of sad and funny in a way . these guys were in India 
somewhere and the broken English was a hilarious.  But they didn't 
help at all.


So I just figured it was very a simple thing ... I create a WEB-INF, 
populate it with all of the components that were in the directory on 
my home testing machine, and I'd be off and running.


But I can't get past the submit button  It thinks for some reason 
it needs addArticle.do.  This leads me to think the WEB-INF needs to 
be not only under the public_html directory but down further in 
another directory named for the app.  So then if I execute 
www.?.com\myApp\newArticle.jsp (where myApp is the name of the 
directory where the WEB-INF and all my other components are . that 
would work?


I'm just trying to trudge through this . but I wish those Rat 
b...@stards in the support staff were more help .. but what can you do


I do appreciate the help though  any ideas and suggestions at this 
point woud be great 


Thanks,

Steve



On 2/14/2010 9:55 AM, Pid wrote:

On 14/02/2010 11:58, Steve Campisano wrote:

I have a new website that I'm using to bring my skills up to date and
I'm running into a file does not exist issue.

This is a very simple JSP/STRUTS application that I have working on my
home system using NetBeans 6.8 and TomCat 5.5.28. It is made up of a
couple of JSP pages and a STRUTS actionform and action. Very simple. A
form is displayed for the user to enter data into, a submit button is
pressed, and a new page is then rendered that displays the input 
entered

on the form.


Tomcat != TomCat.  (Why does anyone think it's called TomCat?)


My execution starts via a JSP named, newArticle.jsp.

This renders a form (without issue) which has a few text fields that 
the

user enters data into and hits the submit button which calls html:form
action=/addArticle.

I am now expecting a success JSP to be rendered that displays the
information that was entered on the form.

What I'm getting is the following:

[Sat Feb 13 08:19:10 2010] [error] [client xxx.xxx.xx.xxx] File does 
not

exist: /home/w1smchdj/public_html/addArticle.do

The site I'm deploying to uses TomCat 5.5.25 and when I deploy to my
site I use CPANEL File Manager to copy the files individually rather
than dropping a WAR file in as they do not recommend dropping in a WAR
file.


Sounds ugly.


I have copied the *.JSP files directly under the public_html folder of
the site and the remainder of the components are in the WEB-INF folder
directly under the public_html folder.

Again, this all works fine in my NetBeans / TomCat test at home.

I must not be deploying my components to the correct directory
structure? Or maybe I need to change my WEB.XML (which does not seem
right as this is testing fine in NetBean / TomCat at home).

Any and all help would be greatly appreciated.


Without seeing the server.xml, any application context.xml or 
additional config, we're going to struggle to help you.


You may well be better off asking the site's admins for support, if 
you can't provide the above.



p

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: File does not exist error - public_html/addArticle.do


I spoke to soon . I'm still getting the same error .

On 2/14/2010 10:21 AM, Steve Campisano wrote:

Thanks for replying .

Yes, it is ugly I agree with that . but I'm just starting out  ... 
small steps


Anyway, I figured I'd start off with something small and easy.

I did pass a few emails back and forth with the support staff but they 
pushed it back on me ...


They told me to talk with the developer .. I laughed as I am the 
developer (Been writing code for 30+ years professionally ... 
mainframes).


It was kind of sad and funny in a way . these guys were in India 
somewhere and the broken English was a hilarious.  But they didn't 
help at all.


So I just figured it was very a simple thing ... I create a WEB-INF, 
populate it with all of the components that were in the directory on 
my home testing machine, and I'd be off and running.


But I can't get past the submit button  It thinks for some reason 
it needs addArticle.do.  This leads me to think the WEB-INF needs to 
be not only under the public_html directory but down further in 
another directory named for the app.  So then if I execute 
www.?.com\myApp\newArticle.jsp (where myApp is the name of the 
directory where the WEB-INF and all my other components are . that 
would work?


I'm just trying to trudge through this . but I wish those Rat 
b...@stards in the support staff were more help .. but what can you do


I do appreciate the help though  any ideas and suggestions at this 
point woud be great 


Thanks,

Steve



On 2/14/2010 9:55 AM, Pid wrote:

On 14/02/2010 11:58, Steve Campisano wrote:

I have a new website that I'm using to bring my skills up to date and
I'm running into a file does not exist issue.

This is a very simple JSP/STRUTS application that I have working on my
home system using NetBeans 6.8 and TomCat 5.5.28. It is made up of a
couple of JSP pages and a STRUTS actionform and action. Very simple. A
form is displayed for the user to enter data into, a submit button is
pressed, and a new page is then rendered that displays the input 
entered

on the form.


Tomcat != TomCat.  (Why does anyone think it's called TomCat?)


My execution starts via a JSP named, newArticle.jsp.

This renders a form (without issue) which has a few text fields that 
the

user enters data into and hits the submit button which calls html:form
action=/addArticle.

I am now expecting a success JSP to be rendered that displays the
information that was entered on the form.

What I'm getting is the following:

[Sat Feb 13 08:19:10 2010] [error] [client xxx.xxx.xx.xxx] File does 
not

exist: /home/w1smchdj/public_html/addArticle.do

The site I'm deploying to uses TomCat 5.5.25 and when I deploy to my
site I use CPANEL File Manager to copy the files individually rather
than dropping a WAR file in as they do not recommend dropping in a WAR
file.


Sounds ugly.


I have copied the *.JSP files directly under the public_html folder of
the site and the remainder of the components are in the WEB-INF folder
directly under the public_html folder.

Again, this all works fine in my NetBeans / TomCat test at home.

I must not be deploying my components to the correct directory
structure? Or maybe I need to change my WEB.XML (which does not seem
right as this is testing fine in NetBean / TomCat at home).

Any and all help would be greatly appreciated.


Without seeing the server.xml, any application context.xml or 
additional config, we're going to struggle to help you.


You may well be better off asking the site's admins for support, if 
you can't provide the above.



p

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: File does not exist error - public_html/addArticle.do