lost session in Tomcat 7.040 and IE8
I have Tomcat 7.0.26 running on Window7 Pro. I also have Tomcat 7.0.40 running on a Windows 7 Home Premium. Both have the same website. (Obviously, I'm doing some testing.) In the website, a user logs on and the user ID is kept in the session. In one of the JSP pages I have some JavaScript attached to an html button onclick="window.location='/MySite/MyAction.do'"> (I'm using Struts.) Now, here is were it gets strange... During testing, I found that IE8 and IE9 both run fine against Tomcat 7.0.26. By that I mean, after the user logs on, the user ID is kept in the session. After navigating around the site, if the user then clicks on the above button, the Struts Action class "MyAction.do" is able to find the user ID in the session. The same is true of IE9 against Tomcat 7.0.40. But if I do the above with IE8 against the site on Tomcat 7.0.40, the user ID in the session is empty. To summarize, | IE8 | IE9 --- Tomcat 7.0.26 | ok | ok --- Tomcat 7.0.40 |fail | ok --- Any ideas where to start looking? - Carl Dreher - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Class cast exception when starting tomcat 7.0.1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Jane,
On 6/13/13 6:44 PM, Jane Muse wrote:
> I'm using the standard implementation of Realm. Here's the code
>
> //Validate passwords try { if (oldTomcatPassword != null &&
> !"".equals(oldTomcatPassword.trim())) { TomcatConfig tconf =
> TomcatConfig.getInstance(); String digestAlg =
> tconf.getTomcatPwdEncryptionType(); String encryptedOldPwd =
> oldTomcatPassword; if (digestAlg != null) encryptedOldPwd =
> RealmBase.Digest(oldTomcatPassword, digestAlg); if
> (!encryptedOldPwd.equals(tconf.getEncryptedTomcatPwd(tomcatUserName)))
> { errors.add("incorrectPwd", new
> ActionError("error.password.incorrect")); } }
I'm not sure this is any different than the built-in Tomcat
digest-based realms. Why not just use the available ones and discard
your own realm?
> As I said, it no longer compiles with catalina.jar from Tomcat
> 7.0.41. This is not a surprise, that the signature would change,
> and I changed the code accordingly. Now it is:
>
> encryptedOldPwd = RealmBase.Digest(oldTomcatPassword, digestAlg,
> encodedType);
>
> Compiles fine now.
>
> . However, when I build with ant, it says actual and formal
> argument lists differ in length. I don't know why there's an actual
> and a formal argument list. I swapped out catalina.jar.
So, it complies "fine" except not when you build with ant? In what
situation does it compile "fine", then?
- -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/
iQIcBAEBCAAGBQJRuoGcAAoJEBzwKT+lPKRYeiYP+gI32KTIuZ5KO2B6GSthwTHl
+C30U4F16Wy1TGRuE5x876hlD/DKQP0DCzfk8D2rUsdQ/GqujQpt28hgtKHdBzij
ffHjs90S4lawDjiAxZyU6ZeiHT6g/r66gtCoQXMbN/s8Geur433XqLDWHDHIzloi
HpZDbLbbeDr+X06UYir037Xt34fMRAyahDCrCW25nJIOaPE/7ckAeiOsDjbBYWx1
G1/KJ5iE3WfysiERnmh7sFH0wt1g5b2B6BmmbNUGKP8lZNdpbmT8GeCcKfS3SR7e
J+onHNVcxEihwdZ1+5121npQlL9F4rxenO3u6StcLqYowL+++ysYt+wb2J9pI69E
Mw2Cpt83Ig1FtDnXSDd4g5jvj98yaZlqxAkT0JEDY6sHW70CpATJrFLoUwIHzAtE
VmRjVBDI5oVCOaGbz6pY53ZnM3eSrG/CiU4OVyzSAH9geKc093poRoE0pOiwGFIx
v1iG4Nj+LAsOPQjHyBPqtmd10htSxoScvy6tcVleava1uonSazsWKJbz4HDRv4ht
H+f+CC6KAfraMVWkCegB9PPxiWcfUnzeo49EfKWcNPspsIUCWYaXR90yvxYlssjb
jqlPp1sc1K7js6aTxeddTtmFPXXhpkFfs0UNmKJ0jZkd0IMQCVQt7dal26/JhbTY
I/sOTgQ+9mYooxZk9YkO
=S8rU
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: forward request by changing the port in request url
Hello, I do not think destination NAT is good solution because it works on TCP layer and knows nothing about domain names and URLs (both are application level (http) knowledge). So you would need to use separate IP/port for that and in case you have it you can bind tomcat there directly) So application-layer forwarding proxy (nginx, squid, apache) is way to go. Hardware cisco solutions could handle it too but I they are too big for such a simple task (unless you have really many users) Ilya >-Original Message- >From: Martin Gainty [mailto:mgai...@hotmail.com] >Sent: Friday, June 14, 2013 2:28 AM >To: Tomcat Users List >Subject: RE: forward request by changing the port in request url > >for IP Redirecting and or automatic Network Address Translations (e.g. Port >80 redirects to Port 81) > >you will need a proxy server > >please contact supp...@cisco.com > > >for product and service options > > > >Viel Gluck >Martin > > >> i have two service running under tomcat. One service is default i.e. >> catalina on port 8080 and 8443 second service is catalina_new on port 8081 >and 8444. >> >> i have application abc.war deployed in webapps_new service which is >running on port 8081. This application is not there in webapps. >> i want if any request coming on port 8080 for application abc, it is >> forwarded to port 8081.(same for ssl port 8443->8444) Is there any way to do >the same. >> >> Thanks >> Anil > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Class cast exception when starting tomcat 7.0.1
I'm using the standard implementation of Realm. Here's the code
//Validate passwords
try {
if (oldTomcatPassword != null &&
!"".equals(oldTomcatPassword.trim()))
{
TomcatConfig tconf = TomcatConfig.getInstance();
String digestAlg =
tconf.getTomcatPwdEncryptionType();
String encryptedOldPwd = oldTomcatPassword;
if (digestAlg != null)
encryptedOldPwd =
RealmBase.Digest(oldTomcatPassword, digestAlg);
if
(!encryptedOldPwd.equals(tconf.getEncryptedTomcatPwd(tomcatUserName))) {
errors.add("incorrectPwd", new
ActionError("error.password.incorrect"));
}
}
As I said, it no longer compiles with catalina.jar from Tomcat 7.0.41. This is
not a surprise, that the signature would change, and I changed the code
accordingly. Now it is:
encryptedOldPwd = RealmBase.Digest(oldTomcatPassword, digestAlg, encodedType);
Compiles fine now.
. However, when I build with ant, it says actual and formal argument lists
differ in length. I don't know why there's an actual and a formal argument
list. I swapped out catalina.jar.
188: error: method Digest in class RealmBase cannot be applied to given types;
[javac] encryptedOldPwd =
RealmBase.Digest(oldTomcatPassword, digestAlg, encodedType );
[javac]^
[javac] required: String,String
[javac] found: String,String,String
[javac] reason: actual and formal argument lists differ in length
[javac] 2 errors
[javac] 1 warning
-Original Message-
From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com]
Sent: Thursday, June 13, 2013 1:41 PM
To: Tomcat Users List
Subject: RE: Class cast exception when starting tomcat 7.0.1
> From: Jane Muse [mailto:jm...@rocketsoftware.com]
> Subject: RE: Class cast exception when starting tomcat 7.0.1
> I had catalina.jar in WEB-INF/lib.
Very, very bad move.
> It's needed because we have an implementation of Realm to store an
> encrypted tomcat password users enter in the webapp.
Your custom implementation of Realm should be in Tomcat's lib directory, not
the webapp's. See:
http://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html#What_is_a_Realm?
Such a Realm should not be tied into the operation of any webapp, other than
configuring the webapp to use it.
> If I remove it and add the catalina.jar from tomcat_home/lib to the
> classpath
Not sure what you mean by adding it to the classpath; please explain.
> I have to change the signature from
> org.apache.catalina.realm.RealmBase.Digest(String, String) to
> org.apache.catalina.realm.RealmBase.Digest(String, String, String).
That's because internal Tomcat APIs often change between levels. You certainly
cannot count on using an older version of Realm with a newer Tomcat (or vice
versa).
> Should I not be writing code that needs classes from catalina.jar?
It would certainly be desirable not to be dependent on internal Tomcat classes.
Why do you think a Realm should be storing a password (encrypted or not)
anywhere? A Realm would normally be reading a password from some controlled
storage, not writing to it.
- 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: forward request by changing the port in request url
Hello, What is "request for application"? How would any software know this request is for abc app? You should use different URLs (servlet contexts) or different domain names. Then you may install nginx or apache or squid or something else that would forward your requests to the following tomcats. But you need to configure tomcat valve to store remote_addr. I will give you an example for nginx and domain names. Say, your DNS zone is "example.com." You create 2 subdomains "abc.example.com" and "def.example.com" both with same IP (A record). You install nginx on it listening port 80. You configure it to pass requests for abc.example.com to localhost:8080 and requests for def.example.com to 8081. You open browser and navigate to abc.example.com. Nginx accepts your request and makes request to localhost:8080 where tomcat with app abc sits. Tomcat answers to nginx and it forwards it to you. That is pretty common solution. Ilya Kazakevich, Developer JetBrains Inc http://www.jetbrains.com "Develop with pleasure!" >-Original Message- >From: Anil Goyal -X (anigoyal - Aricent Technologies at Cisco) >[mailto:anigo...@cisco.com] >Sent: Thursday, June 13, 2013 10:00 PM >To: Tomcat Users List >Subject: forward request by changing the port in request url > >i have two service running under tomcat. One service is default i.e. catalina >on port 8080 and 8443 second service is catalina_new on port 8081 and 8444. > >i have application abc.war deployed in webapps_new service which is >running on port 8081. This application is not there in webapps. >i want if any request coming on port 8080 for application abc, it is forwarded >to port 8081.(same for ssl port 8443->8444) Is there any way to do the same. > >Thanks >Anil - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Class cast exception when starting tomcat 7.0.1
you can swap out one jar for another Ant has no idea which container it is communicating with unless you tell it catalina.jar is tied to the Servlet Spec so you cannot change catalina unless you change the accompanying Servlet Spec so you've already done that why not write a Quick and Dirty ant taskdef I'll pick this up on us...@ant.apache.org Viel Gluck Martin Gainty __ Jogi és Bizalmassági kinyilatkoztatás/Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Ez az üzenet bizalmas. Ha nem ön az akinek szánva volt, akkor kérjük, hogy jelentse azt nekünk vissza. Semmiféle továbbítása vagy másolatának készítése nem megengedett. Ez az üzenet csak ismeret cserét szolgál és semmiféle jogi alkalmazhatósága sincs. Mivel az electronikus üzenetek könnyen megváltoztathatóak, ezért minket semmi felelöség nem terhelhet ezen üzenet tartalma miatt. Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. > From: jm...@rocketsoftware.com > To: users@tomcat.apache.org > Subject: RE: Class cast exception when starting tomcat 7.0.1 > Date: Thu, 13 Jun 2013 20:19:07 + > > I had catalina.jar in WEB-INF/lib. It's needed because we have an > implementation of Realm to store an encrypted tomcat password users enter in > the webapp. If I remove it and add the catalina.jar from tomcat_home/lib to > the classpath, I have to change the signature from > org.apache.catalina.realm.RealmBase.Digest(String, String) to > org.apache.catalina.realm.RealmBase.Digest(String, String, String). Then the > code compiles ok, but I get this error when building with ant to make a war > file: > > error: method Digest in class RealmBase cannot be applied to given types; > [javac] encryptedOldPwd = RealmBase.Digest(oldTomcatPassword, digestAlg,null); > > Should I not be writing code that needs classes from catalina.jar? > > Thanks, > > Jane > > -Original Message- > From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Sent: Thursday, June 13, 2013 11:09 AM > To: Tomcat Users List > Subject: Re: Class cast exception when starting tomcat 7.0.1 > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Jane, > > On 6/13/13 12:38 PM, Jane Muse wrote: > > In the archives I thought the only unreleased versions would be > > specified "beta". Please let me know if this is not the case. > > I'll admit it's not clear from the version number which versions are beta, > released, etc. You have to look at the ChangeLog: > > http://tomcat.apache.org/tomcat-7.0-doc/changelog.html > > Each release contains a release date and (optionally) a comment on the > quality of the build. The first non-beta version of Tomcat 7.0.x was 7.0.6. > Tomcat 7.0.1 (distinct from 7.0.10) was actually "not released" > probably because it was broken for some reason. > > When the Tomcat team rolls a release, there is a vote. If there aren't enough > "yes" votes (or any "no" votes), the release is abandoned but the number > isn't re-used. > > Anyhow, there's no reason to attempt to migrate from Tomcat 6.0.x to Tomcat > 7.0.x by shooting for an "early" version of Tomcat 7.0.x: you should go for > the latest. > > Also, if you mistype and say "Tomcat 7.0.1" instead of "Tomcat 7.0.10" > or "Tomcat 7.0.4" instead of "Tomcat 7.0.40" (or "Tomcat 7.0.41"), don't get > an offended when people tell you you are doing it wrong. > Just say "whoops, I meant 7.0.40" and move on. > > Back to your original problem... have you modified the Tomcat 7 installation > in any way -- other than dropping your WAR file/exploded WAR into the > webapps/ directory)? > > Also, do you have any Tomcat-related JAR files in your webapp's WEB-INF/lib > directory? > > - -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/ > > iQIcBAEBCAAGBQJRugqsAAoJEBzwKT+lPKRYkwcQALdDoGGk6ZNHg82Ow8vTjjrY > dO/70UaIg69t4TsgIJApzd+ReSMbzrThby4Ok+EkYOEXLC1tZgbbQpTQdx0sjqXc > k7fJl9oRQ/O9UP4lj+PR1iWL0zTX/Ze+eTQ
RE: forward request by changing the port in request url
for IP Redirecting and or automatic Network Address Translations (e.g. Port 80 redirects to Port 81) you will need a proxy server please contact supp...@cisco.com for product and service options Viel Gluck Martin __ Verzicht und Vertraulichkeitanmerkung Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. > From: anigo...@cisco.com > To: users@tomcat.apache.org > Subject: forward request by changing the port in request url > Date: Thu, 13 Jun 2013 18:00:12 + > > i have two service running under tomcat. One service is default i.e. catalina > on port 8080 and 8443 > second service is catalina_new on port 8081 and 8444. > > i have application abc.war deployed in webapps_new service which is running > on port 8081. This application is not there in webapps. > i want if any request coming on port 8080 for application abc, it is > forwarded to port 8081.(same for ssl port 8443->8444) > Is there any way to do the same. > > Thanks > Anil
Re: TCNative with FIPS OpenSSL throws fingerprint error in FIPS mode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Steve, On 6/13/13 5:27 PM, Steve Nickels wrote: >>> 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. It is, but the function we are using says it gets the "first" error from the error queue. I suppose we could drain the entire error queue looking for all messages and concatenate them together or something. We aren't inspecting the entire error queue. >> 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. > 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 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'm curious: what base address did you use when you changed it? > 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. > 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"? - -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/ iQIcBAEBCAAGBQJRuj2oAAoJEBzwKT+lPKRY2rYQAKbgmjzUDFF3FeoJRZ72yhFf ibtmO/7E5KFk9OOIVoDrFrIslCmfquHTeQZQHD2UrJ00OOL9tgSqbd5
RE: TCNative with FIPS OpenSSL throws fingerprint error in FIPS mode
> > 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: Class cast exception when starting tomcat 7.0.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Chuck, On 6/13/13 4:40 PM, Caldarale, Charles R wrote: >> From: Jane Muse [mailto:jm...@rocketsoftware.com] Subject: RE: >> Class cast exception when starting tomcat 7.0.1 > >> I had catalina.jar in WEB-INF/lib. > > Very, very bad move. > >> It's needed because we have an implementation of Realm to store >> an encrypted tomcat password users enter in the webapp. > > Your custom implementation of Realm should be in Tomcat's lib > directory, not the webapp's. See: > http://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html#What_is_a_Realm? > > Such a Realm should not be tied into the operation of any webapp, > other than configuring the webapp to use it. > >> If I remove it and add the catalina.jar from tomcat_home/lib to >> the classpath > > Not sure what you mean by adding it to the classpath; please > explain. > >> I have to change the signature from >> org.apache.catalina.realm.RealmBase.Digest(String, String) to >> org.apache.catalina.realm.RealmBase.Digest(String, String, >> String). > > That's because internal Tomcat APIs often change between levels. > You certainly cannot count on using an older version of Realm with > a newer Tomcat (or vice versa). > >> Should I not be writing code that needs classes from >> catalina.jar? > > It would certainly be desirable not to be dependent on internal > Tomcat classes. Why do you think a Realm should be storing a > password (encrypted or not) anywhere? A Realm would normally be > reading a password from some controlled storage, not writing to > it. +1 I'm interested in what the custom realm does. Tomcat's realms all support simple hashing via MessageDigest (i.e. no salting, iteration, password-hashing algorithms, etc.) which is often enough for most people (yet I'm not one of them). If you are symmetrically-encrypting your passwords, you are setting yourself up for security problems. If you want to implement something more elaborate (say, you want to implement bcrypt password-hashing instead of MD5), then you'll have to do it yourself. I've been threatening to write-up some patches to allow pluggable password-mangling algorithms into Tomcat Realms, but I have not bothered to do so, yet. If there was more interest in such things, I might be persuaded to be a little more diligent. - -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/ iQIcBAEBCAAGBQJRujQTAAoJEBzwKT+lPKRYwcMP/1u6A4gaWA+NpKs1UgpA8Gr/ qvYqcMt2sjRMPsHEd0uGcxa/SThGJHU351myfMNW4VLfvxV2/++nbnJUlILV3vNS 3h7N6LZrBjAc4CC4u5Xx3MMH4cIY1/jSK0Apnp0inN/zQXTOIT12IRQAT/TNRppS xxjxcIseZiiIkcsrDx4RS57EjXPNS0abEknCCWfpdldu3KTiZemXu0Loq4jZYXNv WGit1orL4MFNPEP1CYl5bxaEMfHd4QpSDLY7DG+OQn/AD+xsNuhNwuTc7QI40aLu 9xAN+ebZL1Qo/WmvVQYyMEdPvP8Xc8xSi9uuaaBSnI05I5+tCkSHaZUJZ/JxJrNk wpAxaIxVHC3YQS/PDsLowY2+MIMXCDnZWi/QOg1TiDypLn5bEGNnJWDUa9L8suYc hyMCGAh93eFIbkb/wB4hHNHp2Lzqbg31YVWvY53wEGUL1WRkvVzVTlQjQ8pR1cUz 8UyVOD1nG21KnwgelCgJKf4FWNtyxvah+52lTSP+HDieAt/+mLY4Z6PH5AUEte+2 QvaO6wfcfSfERA8vIy43XWRQXuciWmRtQypdmHeZQ4KI5ajRteyUKLIu2P1wahmT W+6VyVvDm+k7DW9p7l0XodX/ivw+XChmCm5EXZbDqrhkyelX22lv5jSxn4ROzkUg HePguW0/PF6NNBb5BFg0 =Jhko -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Class cast exception when starting tomcat 7.0.1
> From: Jane Muse [mailto:jm...@rocketsoftware.com] > Subject: RE: Class cast exception when starting tomcat 7.0.1 > I had catalina.jar in WEB-INF/lib. Very, very bad move. > It's needed because we have an implementation of Realm to store an > encrypted tomcat password users enter in the webapp. Your custom implementation of Realm should be in Tomcat's lib directory, not the webapp's. See: http://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html#What_is_a_Realm? Such a Realm should not be tied into the operation of any webapp, other than configuring the webapp to use it. > If I remove it and add the catalina.jar from tomcat_home/lib to the > classpath Not sure what you mean by adding it to the classpath; please explain. > I have to change the signature from > org.apache.catalina.realm.RealmBase.Digest(String, String) to > org.apache.catalina.realm.RealmBase.Digest(String, String, String). That's because internal Tomcat APIs often change between levels. You certainly cannot count on using an older version of Realm with a newer Tomcat (or vice versa). > Should I not be writing code that needs classes from catalina.jar? It would certainly be desirable not to be dependent on internal Tomcat classes. Why do you think a Realm should be storing a password (encrypted or not) anywhere? A Realm would normally be reading a password from some controlled storage, not writing to it. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Class cast exception when starting tomcat 7.0.1
I had catalina.jar in WEB-INF/lib. It's needed because we have an implementation of Realm to store an encrypted tomcat password users enter in the webapp. If I remove it and add the catalina.jar from tomcat_home/lib to the classpath, I have to change the signature from org.apache.catalina.realm.RealmBase.Digest(String, String) to org.apache.catalina.realm.RealmBase.Digest(String, String, String). Then the code compiles ok, but I get this error when building with ant to make a war file: error: method Digest in class RealmBase cannot be applied to given types; [javac] encryptedOldPwd = RealmBase.Digest(oldTomcatPassword, digestAlg,null); Should I not be writing code that needs classes from catalina.jar? Thanks, Jane -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Thursday, June 13, 2013 11:09 AM To: Tomcat Users List Subject: Re: Class cast exception when starting tomcat 7.0.1 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jane, On 6/13/13 12:38 PM, Jane Muse wrote: > In the archives I thought the only unreleased versions would be > specified "beta". Please let me know if this is not the case. I'll admit it's not clear from the version number which versions are beta, released, etc. You have to look at the ChangeLog: http://tomcat.apache.org/tomcat-7.0-doc/changelog.html Each release contains a release date and (optionally) a comment on the quality of the build. The first non-beta version of Tomcat 7.0.x was 7.0.6. Tomcat 7.0.1 (distinct from 7.0.10) was actually "not released" probably because it was broken for some reason. When the Tomcat team rolls a release, there is a vote. If there aren't enough "yes" votes (or any "no" votes), the release is abandoned but the number isn't re-used. Anyhow, there's no reason to attempt to migrate from Tomcat 6.0.x to Tomcat 7.0.x by shooting for an "early" version of Tomcat 7.0.x: you should go for the latest. Also, if you mistype and say "Tomcat 7.0.1" instead of "Tomcat 7.0.10" or "Tomcat 7.0.4" instead of "Tomcat 7.0.40" (or "Tomcat 7.0.41"), don't get an offended when people tell you you are doing it wrong. Just say "whoops, I meant 7.0.40" and move on. Back to your original problem... have you modified the Tomcat 7 installation in any way -- other than dropping your WAR file/exploded WAR into the webapps/ directory)? Also, do you have any Tomcat-related JAR files in your webapp's WEB-INF/lib directory? - -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/ iQIcBAEBCAAGBQJRugqsAAoJEBzwKT+lPKRYkwcQALdDoGGk6ZNHg82Ow8vTjjrY dO/70UaIg69t4TsgIJApzd+ReSMbzrThby4Ok+EkYOEXLC1tZgbbQpTQdx0sjqXc k7fJl9oRQ/O9UP4lj+PR1iWL0zTX/Ze+eTQLIHiJ6rpNnyqgSOnZujsev1lbbaUZ A2w8GwiWOPvA17MIQUio1Rr/OKd6s7/02EKJQwbxIRoBh4jdaTalgJXCBKb5+60p EnNMautisYXQXrdE2hUhMgFX5EIyqPP4PZYxe2EKRRHlGuXnzybYJnuyxDLtGLY7 nTpOfy5LA5xuFLHEruHm7ARUo6Hb8AH2Qvi5saXDsp+6ddh6Fy4Id4JaWODk16Zl KbPQXk1QjZayw8/nmFkr2gWJc8pGYQMzmeCqSxiJ8FqcrXo/bTq4GJwFazqK4cvE xfQDLyCNXaNdbskJ3rM336173+j7spUhrVlS8LyZ7B7bRPPOzxt5CmOZ2b3Y5Ti+ uBTc1YUXQ74/gjoZCRet4xtaGwRfKXARVSebP6+33AtneOsAlbXejmz545ccmUWl T/9c31jchDw+JlpX04KPu5hJzAb+/Jk3HdVG6LGDrB4oKyxcJcmzvREDXzVt+L5q aPHhnAm8pAHYn1nSAR8k15NL61zDr16CC4ffzWu26c9DfSt9xq3XTg0ESPFv0U4J kxt8hkkwFdx5ZbXxnFgb =nulS -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: forward request by changing the port in request url
> From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Subject: Re: forward request by changing the port in request url > > Once you have a ROOT webapp, you can deploy the standard URL > > rewrite filter therein to send the request anywhere you want: > > http://tuckey.org/urlrewrite/ > I don't think that can be used for proxying, can it? No, not proxying, but I didn't read anything into the OP's requirements that it had to be. > I read the OP as saying there were two separate services, so it's > not a simple forward or redirect. Redirect works as long as the filter changes the port number to the desired one. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: forward request by changing the port in request url
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Chuck, On 6/13/13 2:23 PM, Caldarale, Charles R wrote: >> From: Anil Goyal -X (anigoyal - Aricent Technologies at Cisco) >> [mailto:anigo...@cisco.com] Subject: forward request by changing >> the port in request url > >> i have application abc.war deployed in webapps_new service which >> is running on port 8081. This application is not there in >> webapps. > > You should install at least a ROOT application for that > service/host. > >> i want if any request coming on port 8080 for application abc, it >> is forwarded to port 8081.(same for ssl port 8443->8444) Is there >> any way to do the same. > > Once you have a ROOT webapp, you can deploy the standard URL > rewrite filter therein to send the request anywhere you want: > > http://tuckey.org/urlrewrite/ I don't think that can be used for proxying, can it? I read the OP as saying there were two separate services, so it's not a simple forward or redirect. - -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/ iQIcBAEBCAAGBQJRuhBrAAoJEBzwKT+lPKRYRPYP/ie8SwRTy08927ugk9kTb5hI jwFGwjUI4zPkIB03lu1sK1Q5s57hk6kjN/ggox0+GWe0g5uMfMFjia2dd0+ei+jk TJLQ5Lzm6bdoLJW7uHpuecGHYpgp52MEn6XzDQiszoiaQNtPfCWH/TNeCNA6WxvH nlGOSOD3SalLW4egxChvmgihVUPW6YDR8zqPrYSOgmViXCLAu8E8kVAH41lrHWdJ 1TV9cTi4ebxofYcY5yEixl5QRwO0dN04ibeSp2iAdZzLo5zESPlOWWQXaXq0XBrq OEjfTgfR09ZQ2KI6XZ/Ejr35bvL3XUqPzuY8lT8/c5NJMDINI8fY7b96ukCoPebS 7ilqO+H5FjLECdcYu/VshNWE0hZUGbQZR04NZcT63tAr0M8MOUuSZd9XsK6ldZ0V BRKnJjzZQ3/tT6ElwZGHo/dwdqb9pH2lwEe2s2VKIAn/zrhytUscIPqU0GL1zsGy xAWaIzMf42aZ3gvShD1sT60oev/udk6O6rpbyi5Mlt2LFrCT+1z5DU5ynHJ273DU AtJH+WO9bkZfhZqv+Sunus4fag5YtNAEOReYW5x/30t1Rm2qVsre6Aw8RmbBLgtk 9OQRgHRFKaci+X9vgNJYEcNx+FPqLKqwTxoXIksCMxwGnq61pZ0ei4uR9cFxV/Bh RyDiQiNf+LP7dYyzqHrE =bmsH -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: forward request by changing the port in request url
> From: Anil Goyal -X (anigoyal - Aricent Technologies at Cisco) > [mailto:anigo...@cisco.com] > Subject: forward request by changing the port in request url > i have application abc.war deployed in webapps_new service which is running > on port 8081. This application is not there in webapps. You should install at least a ROOT application for that service/host. > i want if any request coming on port 8080 for application abc, it is > forwarded > to port 8081.(same for ssl port 8443->8444) > Is there any way to do the same. Once you have a ROOT webapp, you can deploy the standard URL rewrite filter therein to send the request anywhere you want: http://tuckey.org/urlrewrite/ - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: forward request by changing the port in request url
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Anil, On 6/13/13 2:00 PM, Anil Goyal -X (anigoyal - Aricent Technologies at Cisco) wrote: > i have two service running under tomcat. One service is default > i.e. catalina on port 8080 and 8443 second service is catalina_new > on port 8081 and 8444. > > i have application abc.war deployed in webapps_new service which is > running on port 8081. This application is not there in webapps. i > want if any request coming on port 8080 for application abc, it is > forwarded to port 8081.(same for ssl port 8443->8444) Is there any > way to do the same. Tomcat does not come with any HTTP proxying capabilities out of the box. If you want to do that kind of thing, you'll have to use some kind of 3rd-party software. Apache httpd is god at this kind of thing: reverse-proxying is something it can do out-of-the-box. - -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/ iQIcBAEBCAAGBQJRugxiAAoJEBzwKT+lPKRYwxAP/2KeJeq+bVwsml02oIuAiURf mD3ZAycGC4OJIbt7/qO2rSwbrWiPMueN/Heafk6jqAkEDs6bLgbT3CYikm5nMyPA /YXR4UlKsnAOPxD2lMZ3swxhoUeciv75RvQg+jSsySLf/29HkUg2vLeTXGVmjSOu c9odZT8FhCav+zKpWVNd/bOZ26MvSxl0jPP0ANGfZ/o/gy6NNgj5QB7kp4WhNQUW Xg4lCLegIx3ITcrtbLS+p5Jc0jSWD3buzkEcGTdZAPEZmkQyjSwxlv+JF6aSrBl4 yFLvubBylT+aqIlWXAYlWjSI5oqu+VOl94sEywi1T/kCHn+cWaKzZkmdXmzqcYmX bf3qvis+WS1gXq2pN5GgrN+ex+XG1b3RUBnFAc7iN3ecHjTQiMVBwKKuKvBxsecf Naa/0gbSyWbmnj0VPMZm6ug7M+hlO+AeA4ccJB39u+Cyg2WnyC2NRpS1uCds6BIj 4RlQ3kw6yuO2+ToTcGTzfq3v1RKXLm8Z6Q8xV8aXHgqYOwFtDi37EFr5ehniIiL+ eXpXo1e3TwrjrCRfG7qwgPZnU8jzUcZq42nl/qhar4l9cdbnl+6O0kQz9RWTJ0GK 8ozaXgVfjd0qB+uoPr2zw4ZzrZjENbTSLewVK+pYPcoMHhHi+ZIdGpYqDqmR2S3O ii7nWwMkrtuFCXXVdyWe =6wCS -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Class cast exception when starting tomcat 7.0.1
> From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Subject: Re: Class cast exception when starting tomcat 7.0.1 > I'll admit it's not clear from the version number which versions are > beta, released, etc. You have to look at the ChangeLog: It's easier to look in the archives if all you want to know is the status of each released version: http://archive.apache.org/dist/tomcat/tomcat-7/ - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TCNative with FIPS OpenSSL throws fingerprint error in FIPS mode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Steve, On 6/13/13 1:57 PM, Steve Nickels wrote: > 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. Do you think there are ways it could be improved? Better error checking, etc.? I implemented it as simply as I possibly could. (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? > 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. Thanks, - -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/ iQIcBAEBCAAGBQJRugwMAAoJEBzwKT+lPKRYLY8QAMFcsCWHn0ZXJsi9pqndPYa+ EJ57iZwR4odAZ9uspZwo5+ttViVsYI5vFcS9jNRbB5y8fu3p/I20jCeO2cqsGEH1 2rvI9Q5ynxl9fD9BH8dAIEMhnyH1IOBhrw/pAfwhl2YH5u3GnIDfyvw8cKTzliok O+c9dT8wF1+yvDf0A45J+B3RjZCXZFvqyVmFOpOt73Bc+k3IgR82w3yNolRyAmIu TM2htIhdYibFCMO7FwsrjkczvNdS4YZXdyx5Yk1FB4HQisnOnwQtngQJNYnwR0RO qFsW3GJdsQZzgOwQLdmfF4BGTOjPSRQ+8B3ANpbu2Np63w3lLqSNYL6YzTkP1zMd n5g8/tiy+zYiSglQhcwBb3SGsAkxA0eA/zLr/kvnuf1NRucvx1hy0cnPJPjbLXyn fhE9McgPkhkhNm6Hfei1hKda2HKF22cuamx96aV0BVFtTzhfyVLqz2sXSrGGwQe1 FIsBjdLHYQ3h9f/cEf7NlahcKNJPDGnJfvXkCc+ypNlIthyj5OgrfB20whxomo+i UnEcxACUntEvB1gIQSZLidgu4DLwrrz2vMIdhT6Q08p+j8QBTWcqumlXQ4kwYJF/ 2DAvGUKA3GEMMelZargeOMjobJKQ7/TFDoolpYuMejJsB1WfjVJIgKsTmLiWCuIp u+SpbpznQVQeIAtr9Q7e =WVnL -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Class cast exception when starting tomcat 7.0.1
> From: Jane Muse [mailto:jm...@rocketsoftware.com] > Subject: RE: Class cast exception when starting tomcat 7.0.1 > In the archives I thought the only unreleased versions would be specified > "beta". Please let me know if this is not the case. No, the description of alpha, beta, and stable as the terms apply to Tomcat releases is given here: http://tomcat.apache.org/whichversion.html 7.0.1 never even made it to the alpha stage, and therefore didn't get into the archives. That's often true for early versions of a particular branch, and occasionally happens with later ones when an oops is discovered during testing. (You'll notice that there is no 7.0.36 in the archives.) - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Class cast exception when starting tomcat 7.0.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jane, On 6/13/13 12:38 PM, Jane Muse wrote: > In the archives I thought the only unreleased versions would be > specified "beta". Please let me know if this is not the case. I'll admit it's not clear from the version number which versions are beta, released, etc. You have to look at the ChangeLog: http://tomcat.apache.org/tomcat-7.0-doc/changelog.html Each release contains a release date and (optionally) a comment on the quality of the build. The first non-beta version of Tomcat 7.0.x was 7.0.6. Tomcat 7.0.1 (distinct from 7.0.10) was actually "not released" probably because it was broken for some reason. When the Tomcat team rolls a release, there is a vote. If there aren't enough "yes" votes (or any "no" votes), the release is abandoned but the number isn't re-used. Anyhow, there's no reason to attempt to migrate from Tomcat 6.0.x to Tomcat 7.0.x by shooting for an "early" version of Tomcat 7.0.x: you should go for the latest. Also, if you mistype and say "Tomcat 7.0.1" instead of "Tomcat 7.0.10" or "Tomcat 7.0.4" instead of "Tomcat 7.0.40" (or "Tomcat 7.0.41"), don't get an offended when people tell you you are doing it wrong. Just say "whoops, I meant 7.0.40" and move on. Back to your original problem... have you modified the Tomcat 7 installation in any way -- other than dropping your WAR file/exploded WAR into the webapps/ directory)? Also, do you have any Tomcat-related JAR files in your webapp's WEB-INF/lib directory? - -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/ iQIcBAEBCAAGBQJRugqsAAoJEBzwKT+lPKRYkwcQALdDoGGk6ZNHg82Ow8vTjjrY dO/70UaIg69t4TsgIJApzd+ReSMbzrThby4Ok+EkYOEXLC1tZgbbQpTQdx0sjqXc k7fJl9oRQ/O9UP4lj+PR1iWL0zTX/Ze+eTQLIHiJ6rpNnyqgSOnZujsev1lbbaUZ A2w8GwiWOPvA17MIQUio1Rr/OKd6s7/02EKJQwbxIRoBh4jdaTalgJXCBKb5+60p EnNMautisYXQXrdE2hUhMgFX5EIyqPP4PZYxe2EKRRHlGuXnzybYJnuyxDLtGLY7 nTpOfy5LA5xuFLHEruHm7ARUo6Hb8AH2Qvi5saXDsp+6ddh6Fy4Id4JaWODk16Zl KbPQXk1QjZayw8/nmFkr2gWJc8pGYQMzmeCqSxiJ8FqcrXo/bTq4GJwFazqK4cvE xfQDLyCNXaNdbskJ3rM336173+j7spUhrVlS8LyZ7B7bRPPOzxt5CmOZ2b3Y5Ti+ uBTc1YUXQ74/gjoZCRet4xtaGwRfKXARVSebP6+33AtneOsAlbXejmz545ccmUWl T/9c31jchDw+JlpX04KPu5hJzAb+/Jk3HdVG6LGDrB4oKyxcJcmzvREDXzVt+L5q aPHhnAm8pAHYn1nSAR8k15NL61zDr16CC4ffzWu26c9DfSt9xq3XTg0ESPFv0U4J kxt8hkkwFdx5ZbXxnFgb =nulS -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
forward request by changing the port in request url
i have two service running under tomcat. One service is default i.e. catalina on port 8080 and 8443 second service is catalina_new on port 8081 and 8444. i have application abc.war deployed in webapps_new service which is running on port 8081. This application is not there in webapps. i want if any request coming on port 8080 for application abc, it is forwarded to port 8081.(same for ssl port 8443->8444) Is there any way to do the same. Thanks Anil
RE: TCNative with FIPS OpenSSL throws fingerprint error in FIPS mode
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 > x9QiPMVZ
RE: Class cast exception when starting tomcat 7.0.1
In the archives I thought the only unreleased versions would be specified "beta". Please let me know if this is not the case. Thanks. -Original Message- From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] Sent: Thursday, June 13, 2013 9:25 AM To: Tomcat Users List Subject: RE: Class cast exception when starting tomcat 7.0.1 > From: Jane Muse [mailto:jm...@rocketsoftware.com] > Subject: RE: Class cast exception when starting tomcat 7.0.1 > Just saying, I wasn't using a 3 year unreleased version. Maybe a 3 > year version, yes. Here's my original email: > "I'm getting a class cast exception when starting up tomcat 7.0.1. > I've migrated from 6.0.18 to 7.0.1. I got the same error when > migrating directly to 7.0.4. The error is:" Exactly. You referenced only 7.0.1 (never released) and 7.0.4, which never made it out of beta. You never told us that you meant 7.0.10 and 7.0.41 until today. We can't read your mind, only what you actually write. - 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: Class cast exception when starting tomcat 7.0.1
> From: Jane Muse [mailto:jm...@rocketsoftware.com] > Subject: RE: Class cast exception when starting tomcat 7.0.1 > Just saying, I wasn't using a 3 year unreleased version. Maybe a 3 year > version, yes. Here's my original email: > "I'm getting a class cast exception when starting up tomcat 7.0.1. I've > migrated from 6.0.18 to 7.0.1. I got the same error when migrating directly > to 7.0.4. The error is:" Exactly. You referenced only 7.0.1 (never released) and 7.0.4, which never made it out of beta. You never told us that you meant 7.0.10 and 7.0.41 until today. We can't read your mind, only what you actually write. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Class cast exception when starting tomcat 7.0.1
Just saying, I wasn't using a 3 year unreleased version. Maybe a 3 year version, yes. Here's my original email: "I'm getting a class cast exception when starting up tomcat 7.0.1. I've migrated from 6.0.18 to 7.0.1. I got the same error when migrating directly to 7.0.4. The error is:" -Original Message- From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] Sent: Thursday, June 13, 2013 8:52 AM To: Tomcat Users List Subject: RE: Class cast exception when starting tomcat 7.0.1 > From: Jane Muse [mailto:jm...@rocketsoftware.com] > Subject: RE: Class cast exception when starting tomcat 7.0.1 > Who says I was using a 3 year old unreleased level? Your subject line. > I tried an easier migration - Tomcat 6.0.18 to 7.0.10. The "logic" of that completely escapes me. - 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: Class cast exception when starting tomcat 7.0.1
> From: Jane Muse [mailto:jm...@rocketsoftware.com] > Subject: RE: Class cast exception when starting tomcat 7.0.1 > Who says I was using a 3 year old unreleased level? Your subject line. > I tried an easier migration - Tomcat 6.0.18 to 7.0.10. The "logic" of that completely escapes me. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Class cast exception when starting tomcat 7.0.1
> Who says I was using a 3 year old unreleased level? You did when you set the subject line to "Class cast exception when starting tomcat 7.0.1" Charles was hinting that 7.0.1 wasn't released Chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Class cast exception when starting tomcat 7.0.1
Who says I was using a 3 year old unreleased level? I had started out with Tomcat 7.0.41 and when I got the class cast exception, I tried an easier migration - Tomcat 6.0.18 to 7.0.10. I downloaded 7.0.10 from the archives. As I said, the problem was due to using catalina.jar in my WEB-INF lib, and not due to using 7.0.10. JMuse -Original Message- From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] Sent: Wednesday, June 12, 2013 3:18 PM To: Tomcat Users List Subject: RE: Class cast exception when starting tomcat 7.0.1 > From: Jane Muse [mailto:jm...@rocketsoftware.com] > Subject: RE: Class cast exception when starting tomcat 7.0.1 > Problem was solved by removing an old catalina.jar for WEB-INF/lib. The fact that you had a Tomcat-supplied jar in WEB-INF/lib is even scarier than using a three-year-old unreleased level. Tomcat-supplied jars must *NEVER* be placed anywhere other than in Tomcat's lib directory. Sounds like you need to do a comprehensive audit of your webapp development and deployment process. - 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: TCNative with FIPS OpenSSL throws fingerprint error in FIPS mode
> >> 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: OOME issue in Tomcat 6.0.18(with SSL)
Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Chirag,
On 6/13/13 12:59 AM, Chirag Dewan wrote:
A little more digging in and I found out that only with SSL,tomcat
is creating a large number of sessions. I can see in the logs for
HTTP:
INFO: SessionListener:
sessionDestroyed('2E8DE01EE3F0D166FEFC8A45353CD9ED')
Now,in case of HTTPS I see a large number of such logs. So I
believe for HTTPS requests it is creating a session for every
request as compared to HTTP?
That seems odd, as web applications usually create sessions regardless
of the use of HTTP versus HTTPS. I suppose it's your web application,
so it could be doing anything at all.
This is my SSL setting in client:
public HttpTLSProtocolSocketFactory() { try { this.sslcontext =
SSLContext.getInstance("TLS"); TrustManager[] arrayOfTrustManager =
{ new DummyX509TrustManager() }; this.sslcontext.init(null,
arrayOfTrustManager, null); } catch (Exception localException) {
this.logger.log(Level.SEVERE, "Failed to created SSLContext: " +
localException.getMessage()); } }
public Socket createSocket(String paramString, int paramInt1,
InetAddress paramInetAddress, int paramInt2, HttpConnectionParams
paramHttpConnectionParams) throws IOException,
UnknownHostException, ConnectTimeoutException { if
(paramHttpConnectionParams == null) throw new
IllegalArgumentException("Parameters may not be null"); int i =
paramHttpConnectionParams.getConnectionTimeout(); SSLSocketFactory
localSSLSocketFactory = this.sslcontext.getSocketFactory(); if (i
== 0) return localSSLSocketFactory.createSocket(paramString,
paramInt1, paramInetAddress, paramInt2); Socket localSocket =
localSSLSocketFactory.createSocket(); InetSocketAddress
localInetSocketAddress1 = new InetSocketAddress(paramInetAddress,
paramInt2); InetSocketAddress localInetSocketAddress2 = new
InetSocketAddress(paramString, paramInt1);
localSocket.bind(localInetSocketAddress1);
localSocket.connect(localInetSocketAddress2, i); return
localSocket; }
Can different sockets create different sessions?
This isn't an SSL session issue, it's an HttpSession issue. The client
is irrelevant, except that you are not handling the Set-Cookie
response header Tomcat is likely sending to you. If you sent that
Cookie back to the server, you would likely eliminate all those extra
sessions and instead only create one (HTTP) session per client thread.
So for HTTP I am not creating any new sessions,same should be the
case for HTTPS. Right?
Only you know what your web application is doing.
The only thing which differs in my is the SSLSocketFactory
Implementation, which creates sockets.
Look at your webapp's code, not the client code.
You might want to write an HttpSessionListener that fires whenever an
HttpSession is created. Do something like this:
public void sessionCreated(HttpSessionEvent se)
{
new Throwable("Trace for session creation").printStackTrace();
}
It looks like you already have an HttpSessionListener (that's where
the INFO message above comes from), so maybe you could just modify
that one.
This will dump stack traces to stdout and tell you exactly where the
sessions are being created. then you can probably figure out why they
are being created in the first place.
Just a shot in the dark here : isn't there some set of conditions whereby Tomcat would set
a cookie sent back to the client, who would return it when the connection is HTTP, but not
when the connection is HTTPS ?
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: OOME issue in Tomcat 6.0.18(with SSL)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Chirag,
On 6/13/13 12:59 AM, Chirag Dewan wrote:
> A little more digging in and I found out that only with SSL,tomcat
> is creating a large number of sessions. I can see in the logs for
> HTTP:
>
> INFO: SessionListener:
> sessionDestroyed('2E8DE01EE3F0D166FEFC8A45353CD9ED')
>
> Now,in case of HTTPS I see a large number of such logs. So I
> believe for HTTPS requests it is creating a session for every
> request as compared to HTTP?
That seems odd, as web applications usually create sessions regardless
of the use of HTTP versus HTTPS. I suppose it's your web application,
so it could be doing anything at all.
> This is my SSL setting in client:
>
> public HttpTLSProtocolSocketFactory() { try { this.sslcontext =
> SSLContext.getInstance("TLS"); TrustManager[] arrayOfTrustManager =
> { new DummyX509TrustManager() }; this.sslcontext.init(null,
> arrayOfTrustManager, null); } catch (Exception localException) {
> this.logger.log(Level.SEVERE, "Failed to created SSLContext: " +
> localException.getMessage()); } }
>
> public Socket createSocket(String paramString, int paramInt1,
> InetAddress paramInetAddress, int paramInt2, HttpConnectionParams
> paramHttpConnectionParams) throws IOException,
> UnknownHostException, ConnectTimeoutException { if
> (paramHttpConnectionParams == null) throw new
> IllegalArgumentException("Parameters may not be null"); int i =
> paramHttpConnectionParams.getConnectionTimeout(); SSLSocketFactory
> localSSLSocketFactory = this.sslcontext.getSocketFactory(); if (i
> == 0) return localSSLSocketFactory.createSocket(paramString,
> paramInt1, paramInetAddress, paramInt2); Socket localSocket =
> localSSLSocketFactory.createSocket(); InetSocketAddress
> localInetSocketAddress1 = new InetSocketAddress(paramInetAddress,
> paramInt2); InetSocketAddress localInetSocketAddress2 = new
> InetSocketAddress(paramString, paramInt1);
> localSocket.bind(localInetSocketAddress1);
> localSocket.connect(localInetSocketAddress2, i); return
> localSocket; }
>
> Can different sockets create different sessions?
This isn't an SSL session issue, it's an HttpSession issue. The client
is irrelevant, except that you are not handling the Set-Cookie
response header Tomcat is likely sending to you. If you sent that
Cookie back to the server, you would likely eliminate all those extra
sessions and instead only create one (HTTP) session per client thread.
> So for HTTP I am not creating any new sessions,same should be the
> case for HTTPS. Right?
Only you know what your web application is doing.
> The only thing which differs in my is the SSLSocketFactory
> Implementation, which creates sockets.
Look at your webapp's code, not the client code.
You might want to write an HttpSessionListener that fires whenever an
HttpSession is created. Do something like this:
public void sessionCreated(HttpSessionEvent se)
{
new Throwable("Trace for session creation").printStackTrace();
}
It looks like you already have an HttpSessionListener (that's where
the INFO message above comes from), so maybe you could just modify
that one.
This will dump stack traces to stdout and tell you exactly where the
sessions are being created. then you can probably figure out why they
are being created in the first place.
- -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/
iQIcBAEBCAAGBQJRudXVAAoJEBzwKT+lPKRYdVEQAJB3Kl1Kp2X4tdvA6J336s+e
iJRQ8Wj0Ap7pB18FC/dFuriIydvp/sEV66SniLcrp7aHB2bwWDg2IrQJdkRODsvh
cARtVY7vDCZR6PffWSpAGOrwe9IbddnPnF1zN3gakPayYQKkA2MAkxgPX8NsVltj
iqHtU00QL5vdUg/PFrw/x26l5GvR8JU9+pgL1bMPi9UHXFTQ6rcQDRxlMdWes5g6
QLAGGuwcCWWYiv3bO1AJiaJB/37qfwQ+CL2FbPu28CeKWzi7MwmjNJuRG4fUaWfZ
Xj4wXAlXVhdcdRNYKNG+yVktwYooaNV0lDTJb4r78K3wukjLg1z9ndXE0t77wT6G
oYL5LWsnkPq34pUQupCJnl/N2anAjIb1pbCfZ+xLvotRv++s3uGpMtV8ozBeDkgy
WYL6hGyeRCewV9z4wA7nQHZ03JYP9vFE6qWzxjwgKT7KLCdbwDM5QOg5EXv+rxx6
VxQk9yZ55cMi+Pk+A3fahq+FanBu2nRqeOHKkmxmjKS1hJuOdSr9gE+VWDosF7zj
z8Dg8Uq8aqd//paR3T0zSoSHMpfWY+1/sojtgBThqQmdOVZli+AriVwnjCegzZQB
tS68ROi+wGtGuJHSuE0GQ3D7enSii6MxPGmuTsAGThLqQKdJlwyvRpUxNsdjiSLG
LvUGReWZ9EUTB5RuWIj3
=34Mn
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
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/3DLdVl6BBLAAqKMANzQE4rv uz44hZh6kpAyfE6ZKdmmm9WOw0X2g6Fq/rYDlYJlX0V/357AXQ33CttDXauU5eGs N0gjbe9E75mIm7HJlXoKnK3U4HjU2/Pc16q1jCdcu8YW3NYVyztglMbOd/hjYc+Z GRGk6Q+/qsI42As7GGMltLiO6FS+e4sgZ4fOlsppcn/w9g9GTCdENifKX1Dl851j 8mqfNEVSrMJy1kxbXmVyvE/Nmv2eLsVZGyOAkqIMEeZFuloLuRBAK9o+EGJiL8Ff /ewNsn1G2otNVi+8TyFFrOLZPV2MyveBzNw53umjYyVkmfxKIorm5LP2peeN0/53 Zg6HrF1fV4LtAsqU/GWsa3j7O87kP4f1ZyYvYb+0BEMBeZtq/XNVWhzvADj9IV9s x9QiPMVZTwZRaBO11p+mlRsam3tWWJpIGzxmUke9GHYOunKHKLed7S5ZGCZV5yje 4jozK+x5ueNHb3rh/HJIJlo4534wFTxB1L9Xuq1/WT39lYydJ4wcF+51+BYDwAMp M1AnA37PBS76nXzOOu4nQo6LW9pSIQ59B57WpH8m3HRZvgO7xZxZWMs3VdViC6A+ OkCXqFORijvyG9YSbKun9D7NPIUZchynvEFQbmOE5K0A56Q9+u6v/76UuVItjiJq biV1heB9VPjzArksryKq =5w4s -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: http request (no only session) replication in cluster
Christopher Thx for response, I will inform guys from business about what You have written, and let them consider it Regards Jakub On Wed, Jun 12, 2013 at 4:10 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Jakob, > > On 6/11/13 5:04 PM, Ja kub wrote: > > requirement is system should be possible to process 160 req/sec > > (200 is better to multiply) and system is kind of failover proxy > > itself > > > > there are 2 backing webservices, each can answer max 20s, it there > > is timeout on first, I must call the second, if there is timeout on > > second I send soap fault to client, so usually it shouldn't be more > > than 20s per req, guys say that normally it is 7-10 > > seconds/request, but in worst case it is 2*20s*160 requests/s ~= > > 6400 pending requests (and according to deal we must fulfill worst > > case) > > If you have 2 member nodes and one of them starts to slow down, then > you'll see pretty much all requests re-tried on the second node, which > will slow down that one. I think you'll end up seeing a storm of > requests bouncing back and forth. > > Worse, the initial request will continue processing on the 1st node, > ignorant of the fact that the lb has given up and tried the other > node. It's just going to fall apart from there. > > Honestly, this should be able to be handled at your lb -- can't you > set a time-out there? > > > even if there are so many requests they are pending on sockets, I > > try to do it with NIO, asynchronous servlets and async cxf - both > > async cxf webservice is exposed by me, and I also call backing ws > > with async cxf I think even one tomcat on one server should be able > > to serve such 6400 pending requests with 160req/s, apart from proxy > > there are also 4-6 inserts into database (cli req, resp; 1st ws > > call, resp; 2nd ws call, resp > > > > how do You assess such architecture/attitude ? do You expect > > problems with async exposed webservice based on async servlet and > > NIO, and async cxf ws client ? afaik cxf use thread locals, are > > they all right with tomcat async servlets ? (I don't define > > threadlocals by myself, only cxf possibly does) > > It's not a socket-resource issue, it's a raw work-load issue: you have > a large amount of load and it looks like you can't handle it very > well. I would recommend more nodes, first, and then seriously consider > whether re-trying on a second node is appropriate if the first node > takes too long. > > What you should probably do is actually profile your code to find out > what is taking so long. Using tricks like ThreadLocals can shed > microseconds off of a request, not whole seconds. > > You might want to consider whether you can do less work during a > request -- perhaps split a single transaction into more than one. Or, > just acknowledge that sometimes a transaction can take 10-20 seconds > (or 50?) and manage the clients' expectations. > > You also need to find out where your bottleneck is: RDBMSs, slow > disks, slow network links, etc. can all be much more significant than > things like software stack and exact implementation of your code. If > you are missing an index on a relational table, transactions that > should take a second or two can take tens of seconds. > > Start there: profile your application, find out what is slow, and fix > that. Don't try to work-around the problem with surprising > transactional re-tries, because they likely won't work the way you > hoped. Hey, once you fix your performance problem, perhaps you won't > need additional hardware. Also, your users will be very happy to see a > speed improvement. > > - -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/ > > iQIcBAEBCAAGBQJRuIFyAAoJEBzwKT+lPKRYr+4QAL7UCQvZ/CBIueIqhFDLkZ57 > v0uWcuukEtT8/8dNUBW2SGSE4OwDyH41Nsx7ZVo4W+lTnzduVbjXSvU4lXNDiY19 > 9MgpwuxZWlUxHAgOQ5NODIFwrHQK2GYMe8+Qo8OBVf6lOhVdB4PS/7XM7lrsnWBn > rpojl4rPm7+esciZPB1q15+PxCbgh4uGsI4KCXyZiW/gz/dLC2v8u6QiYfqoXgov > iutYtII+7f1E6I+Ag3LjmQwrzY7pRpHrotcJ4aCpyOs9EHTavKf3mapwY2HiOP+t > G9qwGuq5tUJhkBzF5Vdvqf+lCbdJHkQtLW3Z4vL4/XTK7SVSvjipFhsttZF4TII6 > 6QVQmjCJZRYdPDegzB+NVaCxPkdZLLdwHNFFfsZGabdTQDkAKOEXQiYjBqJ9n5nX > WRHvYLQtyGEj1e+0zqwCihRHie2TbfwdggtCoVaOF+8Zpguv3K9VRHwvFA/miA1i > JkYCfxKjyF/RoCyB4wZqCi5VsJjztQpq6uDQiUG0CACY1491sB35M+Vkqm3jqRbh > 0HXs1ckqZsw+2Y013kpCVs0eipOst5GD6XqXr6LTT/fQwEYWa3uVTk3/h2xDd9BT > DlTZrs1CNhqMBjNqUDUFkiiempf9kFkQhrao50CAilix95/VhdWkDjFcFSKKQ0/J > EkcONNIioMTN7cWzKNHf > =miI6 > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
