Re: Installing a program designed for Tomcat 5.5 on Tomcat 9
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 2/6/20 6:01 PM, Mark Thomas wrote: > On 06/02/2020 20:32, Shane Johnson wrote: >> I am currently trying to install a program designed to operate on >> Win XP 32 and earlier on to a Win 10 environment. The program >> extracts to the Shared and Webapps folders of Tomcat 5.5 and uses >> a SQL database. After converting the database and installing it >> on SQL 2017 I added the JDBC connector and downloaded and >> installed tomcat 9 only to find there is no shared folder to >> extract the shared files to. Any suggestions? > > There are several options but the simplest is put anything > extracted to shared in the lib directory. IMHO, the proper place to move libraries that were in an old "shared" folder on a previous installation is the application's own WEB-INF/lib/ directory, rather than Tomcat's top-level lib directory. If any of those libraries conflicts with anything provided by Tomcat, there may be problems with the server if you put them into lib/. Instead, if you put them into WEB-INF/lib/, then the server will isolate them to that one application and they will not pollute the rest of the server. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5BYxoACgkQHPApP6U8 pFhuIhAAwlpK4qoubt2gK9UuX7yV+oMEuRCUtBihMVAQOw+g8DTWk9CIJm5uawIp yL7lwK1kjwEcYWGyu93y0wWwB4vZKtVosutMVeeepr6dlhPonVcVgoL0ktyelin+ k3PFIh9ieVyU3SxC96ZIYVLYyJu8psZUFpvGthylLL+GWy0uat61cWrU5zMWOb0q CxEqdpE65VSwZwYCfVz1GiKOnGgJ24y8AHCT1sPrlvY3R/lYkNozIIkD8mp40MYX 9V/3bBAP1VgZG9shlC2pQ2EU2Lu9l6QLdRsL3XgVg2jQEhy3qz3VFmGt84ja/J9x DbEusx0TTsil1uvSdl5Jj19J7nl3UChZyxZDnMGx8kbMcKQnl8HipCw/lC3pssGt gqrlse9s6Zq+jHWCBd76PfLNf1owmIkAHVKLtJqiyw16+u4VCCPM5Ev06xdoRFH0 4V+khCe8Cxs+3k1ls5EFuiDpR/8PkRuT0kWQNRR/iXaKvegeWtJLCoij9PjxK0+U YXx6Axw6PsSJXgay/UVLnjvhbTFmDppCBPLtyXRF3DQiPeUa7X2psPQv5Kfgaxe9 w5bZaDZlollnZ8T6bGTTc/gguBDILSATKOmXIaa+hYDF1pX5sp85qK0iUgW4LBOz JIn3qVpvcItQ115AN0e7cLapyvuFggVreigEpl4VaCXaOExDryg= =EOi3 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Installing a program designed for Tomcat 5.5 on Tomcat 9
Am 09.02.20 um 22:28 schrieb Shane Johnson:
> Attached is a screen shot copy of the files it extracts to the Shared
> folder the classes folder it creates is empty. I do now recall there
> were some similar file names to ones already in the library
Attachments tend to get removed on this mailing list - as has happened
to your image. Could you post the content as text?
Felix
>
> On Sun, Feb 9, 2020 at 11:36 AM Felix Schumacher
> <mailto:felix.schumac...@internetallee.de>> wrote:
>
>
> Am 09.02.20 um 18:46 schrieb Shane Johnson:
> > I extracted the shared folder to my desktop to see what was in
> it. It
> > contains 2 folders Classes and lib, with 24 jar files in the lib
> folder. I
> > did try extracting it to the Libraries in the tomcat tree and
> running the
> > program with no success. I now am wiping the installation of
> tomcat and
> > extracted program and doing a full reload. This next time I am
> going to try
> > to move the Library files in the tomcat 9 directory into a
> folder named
> > shared by altering the directory tree first prior to extracting the
> > program. I think I read in the docs somewhere there is a command
> line that
> > can do this so tomcat knows where to look for the library and shared
> > library files. Any more suggestions would be welcome.
>
> Try to do what Mark suggested :) The shared class loader has been
> "replaced by/merged with" the common loader. The common loader
> holds all
> classes and libs, that are common (shared) across all webapps.
>
> Copy everything (watch out for jars with same/similar names) that you
> found in your extracted shared folder into the lib folder. (If there
> really is a folder called Classes, that contains the class structures,
> copy the files/folders from inside Classes into the top level lib/
> folder.)
>
> It might help, if you post the elements of your shared folder, so that
> others can have a better guess on where to copy those.
>
> If you want to get fancy, you can edit conf/catalina.properties
> and edit
> the property "comon.loader" to include your shared folder. Be sure to
> both entries for the classes and the jar files.
>
> You might want to have a look at RUNNING.txt. There is a
> description on
> how to setup tomcat for multiple installations. Those setups are -
> in my
> opinion - easier to play with, as you are not messing with the
> original
> installation but a minimal shallow copy.
>
> Felix
>
> >
> > On Sun, Feb 9, 2020 at 5:09 AM Konstantin Kolinko
> mailto:knst.koli...@gmail.com>>
> > wrote:
> >
> >> вс, 9 февр. 2020 г. в 02:12, Peter Rader <mailto:p.ra...@gmx.net>>:
> >>>
> >>>> I am currently trying to install a program designed to
> operate on Win
> >> XP 32
> >>>> and earlier on to a Win 10 environment. The program extracts
> to the
> >> Shared
> >>>> and Webapps folders of Tomcat 5.5 and uses a SQL database. After
> >> converting
> >>>> the database and installing it on SQL 2017 I added the JDBC
> connector
> >> and
> >>>> downloaded and installed tomcat 9 only to find there is no shared
> >> folder to
> >>>> extract the shared files to. Any suggestions?
> >>> Hm, shared ... do you mean the endorsed folder? From old apps
> I remember
> >> that some jdbc-jars have to be placed in tomcat's endorsed folder.
> >>> I am pretty sure that you could use the JVM/JDK's endorsed
> folder. They
> >> usually have their place in \lib\endorsed .
> >>
> >> Endorsed folder is a different beast. Please do not put
> anything there.
> >>
> >> Tomcat 5.5 documentation is still available online (if you know the
> >> address to type it in a browser's address bar) [1] The closest
> analogy
> >> to the "Shared" classloader in current Tomcat is the "Common"
> >> classloader that loads classes from ${catalina.base|/lib.
> >>
> >> [1]
> >>
> https://tomcat.apache.org/tomcat-5.5-doc/class-loader-howto.html#Overview
> >> [2]
> >>
> https://tomcat.apache.org/tomcat-9.0-doc/class-loader-howto.html#Overview
> >>
> >> It is possible to reconfigure Tomcat 9 to have a sepa
Re: Installing a program designed for Tomcat 5.5 on Tomcat 9
Attached is a screen shot copy of the files it extracts to the Shared
folder the classes folder it creates is empty. I do now recall there were
some similar file names to ones already in the library
On Sun, Feb 9, 2020 at 11:36 AM Felix Schumacher <
felix.schumac...@internetallee.de> wrote:
>
> Am 09.02.20 um 18:46 schrieb Shane Johnson:
> > I extracted the shared folder to my desktop to see what was in it. It
> > contains 2 folders Classes and lib, with 24 jar files in the lib folder.
> I
> > did try extracting it to the Libraries in the tomcat tree and running the
> > program with no success. I now am wiping the installation of tomcat and
> > extracted program and doing a full reload. This next time I am going to
> try
> > to move the Library files in the tomcat 9 directory into a folder named
> > shared by altering the directory tree first prior to extracting the
> > program. I think I read in the docs somewhere there is a command line
> that
> > can do this so tomcat knows where to look for the library and shared
> > library files. Any more suggestions would be welcome.
>
> Try to do what Mark suggested :) The shared class loader has been
> "replaced by/merged with" the common loader. The common loader holds all
> classes and libs, that are common (shared) across all webapps.
>
> Copy everything (watch out for jars with same/similar names) that you
> found in your extracted shared folder into the lib folder. (If there
> really is a folder called Classes, that contains the class structures,
> copy the files/folders from inside Classes into the top level lib/ folder.)
>
> It might help, if you post the elements of your shared folder, so that
> others can have a better guess on where to copy those.
>
> If you want to get fancy, you can edit conf/catalina.properties and edit
> the property "comon.loader" to include your shared folder. Be sure to
> both entries for the classes and the jar files.
>
> You might want to have a look at RUNNING.txt. There is a description on
> how to setup tomcat for multiple installations. Those setups are - in my
> opinion - easier to play with, as you are not messing with the original
> installation but a minimal shallow copy.
>
> Felix
>
> >
> > On Sun, Feb 9, 2020 at 5:09 AM Konstantin Kolinko <
> knst.koli...@gmail.com>
> > wrote:
> >
> >> вс, 9 февр. 2020 г. в 02:12, Peter Rader :
> >>>
> >>>> I am currently trying to install a program designed to operate on Win
> >> XP 32
> >>>> and earlier on to a Win 10 environment. The program extracts to the
> >> Shared
> >>>> and Webapps folders of Tomcat 5.5 and uses a SQL database. After
> >> converting
> >>>> the database and installing it on SQL 2017 I added the JDBC connector
> >> and
> >>>> downloaded and installed tomcat 9 only to find there is no shared
> >> folder to
> >>>> extract the shared files to. Any suggestions?
> >>> Hm, shared ... do you mean the endorsed folder? From old apps I
> remember
> >> that some jdbc-jars have to be placed in tomcat's endorsed folder.
> >>> I am pretty sure that you could use the JVM/JDK's endorsed folder. They
> >> usually have their place in \lib\endorsed .
> >>
> >> Endorsed folder is a different beast. Please do not put anything there.
> >>
> >> Tomcat 5.5 documentation is still available online (if you know the
> >> address to type it in a browser's address bar) [1] The closest analogy
> >> to the "Shared" classloader in current Tomcat is the "Common"
> >> classloader that loads classes from ${catalina.base|/lib.
> >>
> >> [1]
> >>
> https://tomcat.apache.org/tomcat-5.5-doc/class-loader-howto.html#Overview
> >> [2]
> >>
> https://tomcat.apache.org/tomcat-9.0-doc/class-loader-howto.html#Overview
> >>
> >> It is possible to reconfigure Tomcat 9 to have a separate Shared
> >> classloader as well, but that is an overkill.
> >>
> >> Also, do not forget about Migration Guides [3].
> >>
> >> [3] https://tomcat.apache.org/migration.html
> >> [4]
> >> https://tomcat.apache.org/migration-6.html#Modified_directory_structure
> >>
> >> 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
>
>
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Installing a program designed for Tomcat 5.5 on Tomcat 9
Am 09.02.20 um 18:46 schrieb Shane Johnson:
> I extracted the shared folder to my desktop to see what was in it. It
> contains 2 folders Classes and lib, with 24 jar files in the lib folder. I
> did try extracting it to the Libraries in the tomcat tree and running the
> program with no success. I now am wiping the installation of tomcat and
> extracted program and doing a full reload. This next time I am going to try
> to move the Library files in the tomcat 9 directory into a folder named
> shared by altering the directory tree first prior to extracting the
> program. I think I read in the docs somewhere there is a command line that
> can do this so tomcat knows where to look for the library and shared
> library files. Any more suggestions would be welcome.
Try to do what Mark suggested :) The shared class loader has been
"replaced by/merged with" the common loader. The common loader holds all
classes and libs, that are common (shared) across all webapps.
Copy everything (watch out for jars with same/similar names) that you
found in your extracted shared folder into the lib folder. (If there
really is a folder called Classes, that contains the class structures,
copy the files/folders from inside Classes into the top level lib/ folder.)
It might help, if you post the elements of your shared folder, so that
others can have a better guess on where to copy those.
If you want to get fancy, you can edit conf/catalina.properties and edit
the property "comon.loader" to include your shared folder. Be sure to
both entries for the classes and the jar files.
You might want to have a look at RUNNING.txt. There is a description on
how to setup tomcat for multiple installations. Those setups are - in my
opinion - easier to play with, as you are not messing with the original
installation but a minimal shallow copy.
Felix
>
> On Sun, Feb 9, 2020 at 5:09 AM Konstantin Kolinko
> wrote:
>
>> вс, 9 февр. 2020 г. в 02:12, Peter Rader :
>>>
>>>> I am currently trying to install a program designed to operate on Win
>> XP 32
>>>> and earlier on to a Win 10 environment. The program extracts to the
>> Shared
>>>> and Webapps folders of Tomcat 5.5 and uses a SQL database. After
>> converting
>>>> the database and installing it on SQL 2017 I added the JDBC connector
>> and
>>>> downloaded and installed tomcat 9 only to find there is no shared
>> folder to
>>>> extract the shared files to. Any suggestions?
>>> Hm, shared ... do you mean the endorsed folder? From old apps I remember
>> that some jdbc-jars have to be placed in tomcat's endorsed folder.
>>> I am pretty sure that you could use the JVM/JDK's endorsed folder. They
>> usually have their place in \lib\endorsed .
>>
>> Endorsed folder is a different beast. Please do not put anything there.
>>
>> Tomcat 5.5 documentation is still available online (if you know the
>> address to type it in a browser's address bar) [1] The closest analogy
>> to the "Shared" classloader in current Tomcat is the "Common"
>> classloader that loads classes from ${catalina.base|/lib.
>>
>> [1]
>> https://tomcat.apache.org/tomcat-5.5-doc/class-loader-howto.html#Overview
>> [2]
>> https://tomcat.apache.org/tomcat-9.0-doc/class-loader-howto.html#Overview
>>
>> It is possible to reconfigure Tomcat 9 to have a separate Shared
>> classloader as well, but that is an overkill.
>>
>> Also, do not forget about Migration Guides [3].
>>
>> [3] https://tomcat.apache.org/migration.html
>> [4]
>> https://tomcat.apache.org/migration-6.html#Modified_directory_structure
>>
>> 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: Installing a program designed for Tomcat 5.5 on Tomcat 9
I extracted the shared folder to my desktop to see what was in it. It
contains 2 folders Classes and lib, with 24 jar files in the lib folder. I
did try extracting it to the Libraries in the tomcat tree and running the
program with no success. I now am wiping the installation of tomcat and
extracted program and doing a full reload. This next time I am going to try
to move the Library files in the tomcat 9 directory into a folder named
shared by altering the directory tree first prior to extracting the
program. I think I read in the docs somewhere there is a command line that
can do this so tomcat knows where to look for the library and shared
library files. Any more suggestions would be welcome.
On Sun, Feb 9, 2020 at 5:09 AM Konstantin Kolinko
wrote:
> вс, 9 февр. 2020 г. в 02:12, Peter Rader :
> >
> >
> > > I am currently trying to install a program designed to operate on Win
> XP 32
> > > and earlier on to a Win 10 environment. The program extracts to the
> Shared
> > > and Webapps folders of Tomcat 5.5 and uses a SQL database. After
> converting
> > > the database and installing it on SQL 2017 I added the JDBC connector
> and
> > > downloaded and installed tomcat 9 only to find there is no shared
> folder to
> > > extract the shared files to. Any suggestions?
> >
> > Hm, shared ... do you mean the endorsed folder? From old apps I remember
> that some jdbc-jars have to be placed in tomcat's endorsed folder.
> >
> > I am pretty sure that you could use the JVM/JDK's endorsed folder. They
> usually have their place in \lib\endorsed .
>
> Endorsed folder is a different beast. Please do not put anything there.
>
> Tomcat 5.5 documentation is still available online (if you know the
> address to type it in a browser's address bar) [1] The closest analogy
> to the "Shared" classloader in current Tomcat is the "Common"
> classloader that loads classes from ${catalina.base|/lib.
>
> [1]
> https://tomcat.apache.org/tomcat-5.5-doc/class-loader-howto.html#Overview
> [2]
> https://tomcat.apache.org/tomcat-9.0-doc/class-loader-howto.html#Overview
>
> It is possible to reconfigure Tomcat 9 to have a separate Shared
> classloader as well, but that is an overkill.
>
> Also, do not forget about Migration Guides [3].
>
> [3] https://tomcat.apache.org/migration.html
> [4]
> https://tomcat.apache.org/migration-6.html#Modified_directory_structure
>
> Best regards,
> Konstantin Kolinko
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
Re: Installing a program designed for Tomcat 5.5 on Tomcat 9
вс, 9 февр. 2020 г. в 02:12, Peter Rader :
>
>
> > I am currently trying to install a program designed to operate on Win XP 32
> > and earlier on to a Win 10 environment. The program extracts to the Shared
> > and Webapps folders of Tomcat 5.5 and uses a SQL database. After converting
> > the database and installing it on SQL 2017 I added the JDBC connector and
> > downloaded and installed tomcat 9 only to find there is no shared folder to
> > extract the shared files to. Any suggestions?
>
> Hm, shared ... do you mean the endorsed folder? From old apps I remember that
> some jdbc-jars have to be placed in tomcat's endorsed folder.
>
> I am pretty sure that you could use the JVM/JDK's endorsed folder. They
> usually have their place in \lib\endorsed .
Endorsed folder is a different beast. Please do not put anything there.
Tomcat 5.5 documentation is still available online (if you know the
address to type it in a browser's address bar) [1] The closest analogy
to the "Shared" classloader in current Tomcat is the "Common"
classloader that loads classes from ${catalina.base|/lib.
[1] https://tomcat.apache.org/tomcat-5.5-doc/class-loader-howto.html#Overview
[2] https://tomcat.apache.org/tomcat-9.0-doc/class-loader-howto.html#Overview
It is possible to reconfigure Tomcat 9 to have a separate Shared
classloader as well, but that is an overkill.
Also, do not forget about Migration Guides [3].
[3] https://tomcat.apache.org/migration.html
[4] https://tomcat.apache.org/migration-6.html#Modified_directory_structure
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Aw: Installing a program designed for Tomcat 5.5 on Tomcat 9
> I am currently trying to install a program designed to operate on Win XP 32 > and earlier on to a Win 10 environment. The program extracts to the Shared > and Webapps folders of Tomcat 5.5 and uses a SQL database. After converting > the database and installing it on SQL 2017 I added the JDBC connector and > downloaded and installed tomcat 9 only to find there is no shared folder to > extract the shared files to. Any suggestions? Hm, shared ... do you mean the endorsed folder? From old apps I remember that some jdbc-jars have to be placed in tomcat's endorsed folder. I am pretty sure that you could use the JVM/JDK's endorsed folder. They usually have their place in \lib\endorsed . Kind regards Peter Rader - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Installing a program designed for Tomcat 5.5 on Tomcat 9
On 06/02/2020 20:32, Shane Johnson wrote: > I am currently trying to install a program designed to operate on Win XP 32 > and earlier on to a Win 10 environment. The program extracts to the Shared > and Webapps folders of Tomcat 5.5 and uses a SQL database. After converting > the database and installing it on SQL 2017 I added the JDBC connector and > downloaded and installed tomcat 9 only to find there is no shared folder to > extract the shared files to. Any suggestions? There are several options but the simplest is put anything extracted to shared in the lib directory. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Installing a program designed for Tomcat 5.5 on Tomcat 9
I am currently trying to install a program designed to operate on Win XP 32 and earlier on to a Win 10 environment. The program extracts to the Shared and Webapps folders of Tomcat 5.5 and uses a SQL database. After converting the database and installing it on SQL 2017 I added the JDBC connector and downloaded and installed tomcat 9 only to find there is no shared folder to extract the shared files to. Any suggestions?
Re: Jasper Exception when using Tomcat 9 but works with Tomcat 5.5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Sean, On 1/12/18 11:34 AM, Sean Brett wrote: > In case anyone else has such an issue, it appears that this was all > caused by the rt.jar in the webapps WEB-INF/lib directory. > > I removed that jar for one of the other webapps exhibiting the same > issue and it resolved the issue. I wonder what the problematic classes were, here. Tomcat is supposed to prohibit loading certain classes from within the web application. For example, it's not okay for a web application to provide its own implementation of java.lang.Object or java.lang.String. There are certain packages which are supposed to be "protected" (not in the Java sense of the word, but in the "security" sense of the word) from corruption by (broken) web applications. Perhaps something is included in the rt.jar file that "shouldn't be" but Tomcat is allowing it to load. Could you post the manifest of the rt.jar file? Like this: $ jar tf rt.jar It will be a huge list, but that's okay: go ahead and post it, anyway. - -chris > On 12/01/2018 14:38, "Sean Brett" <sean.br...@nottingham.ac.uk> > wrote: > >> Comments at the bottom. (Spoiler alert: Good news!) >> >> >> On 11/01/2018 22:38, "Christopher Schultz" >> <ch...@christopherschultz.net> wrote: >> >>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 >>> >>> Sean, >>> >>> On 1/11/18 11:58 AM, Sean Brett wrote: >>>> On 11/01/2018 15:48, "Christopher Schultz" >>>> <ch...@christopherschultz.net> wrote: >>>> >>>> >>>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 >>>>> >>>>> Sean, >>>>> >>>>> (Thanks for moving to the mailing list; it's a much better >>>>> forum for getting into a protracted discussion. See below >>>>> for more, inline.) >>>>> >>>>> On 1/10/18 9:08 AM, Sean Brett wrote: >>>>>> I've been tasked with migrating a site from one >>>>>> institution to another. As part of the process we are >>>>>> attempting to update the versions the site uses. >>>>>> >>>>>> Initially I was asked to use Java 8 with Tomcat 5.5 (on >>>>>> Linux), which led to issues - not to mention Tomcat 5 >>>>>> being 'out of support¹. I have since tried to deploy the >>>>>> webapps to Tomcat 9 with Java 8. Some of the webapps >>>>>> appear to run fine (and resolve the issues I was having >>>>>> with Tomcat5). However, the main app (and 2 >>>>>> similar/smaller web apps) throws a JasperException when I >>>>>> go to the index.jsp - the same web apps deployed to >>>>>> Tomcat 5.5 load without issue. >>>>> >>>>> Moving to a later Tomcat version is best. We'll help you >>>>> figure out these issues so you can use a current version >>>>> and be better-equipped to stay current into the future. >>>>> >>>>>> Most of the similar issues I have found have suggested >>>>>> this would be related to the jar files and possibly some >>>>>> sort of conflict. However, the lib structure for tomcat 9 >>>>>> is different to tomcat5 and I'm not sure which jars could >>>>>> be causing this. e.g. >>>>>> https://stackoverflow.com/questions/22552244/tomcat-7-fails-to-co mpi >>> >>>>>> le >>>>> >>>>>> >>> - - -jsp- >>>>>> >>>>>> >>>>> pages >>>>> >>>>> JAR files might conflict, but that depends upon what you >>>>> have done so far. Easy questions: >>>>> >>>>> 1. Have you added anything to Tomcat's lib/ directory (that >>>>> would be CATALINA_HOME/lib or CATALINA_BASE/lib -- or both) >>>>> after installing Tomcat 8/9? >>>> >>>> Yes, I’ve added some jars. Some I can’t remember why I’ve >>>> added them but doubt they’d be connected to the problem. >>>> Here’s a list of the CATALINA_HOME/lib directory: (the last 4 >>>> being the ones that have been added) >>>> >>>> [snip] >>>> >>>> -rw-r--r--. 1 tomcat tomcat 313898 Dec 20 13:57 >>>> dom4j-1.6.1.jar -rw-r--r--. 1 tomcat tomcat 802494 Dec 20 >>>> 13:57 freemarker-2.3.8.jar -rw-r--r--. 1 tomcat to
Re: Jasper Exception when using Tomcat 9 but works with Tomcat 5.5
In case anyone else has such an issue, it appears that this was all caused by the rt.jar in the webapps WEB-INF/lib directory. I removed that jar for one of the other webapps exhibiting the same issue and it resolved the issue. On 12/01/2018 14:38, "Sean Brett" <sean.br...@nottingham.ac.uk> wrote: >Comments at the bottom. (Spoiler alert: Good news!) > > >On 11/01/2018 22:38, "Christopher Schultz" <ch...@christopherschultz.net> >wrote: > >>-BEGIN PGP SIGNED MESSAGE- >>Hash: SHA256 >> >>Sean, >> >>On 1/11/18 11:58 AM, Sean Brett wrote: >>> On 11/01/2018 15:48, "Christopher Schultz" >>> <ch...@christopherschultz.net> wrote: >>> >>> >>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 >>>> >>>> Sean, >>>> >>>> (Thanks for moving to the mailing list; it's a much better forum >>>> for getting into a protracted discussion. See below for more, >>>> inline.) >>>> >>>> On 1/10/18 9:08 AM, Sean Brett wrote: >>>>> I've been tasked with migrating a site from one institution to >>>>> another. As part of the process we are attempting to update >>>>> the versions the site uses. >>>>> >>>>> Initially I was asked to use Java 8 with Tomcat 5.5 (on >>>>> Linux), which led to issues - not to mention Tomcat 5 being >>>>> 'out of support¹. I have since tried to deploy the webapps to >>>>> Tomcat 9 with Java 8. Some of the webapps appear to run fine >>>>> (and resolve the issues I was having with Tomcat5). However, >>>>> the main app (and 2 similar/smaller web apps) throws a >>>>> JasperException when I go to the index.jsp - the same web apps >>>>> deployed to Tomcat 5.5 load without issue. >>>> >>>> Moving to a later Tomcat version is best. We'll help you figure >>>> out these issues so you can use a current version and be >>>> better-equipped to stay current into the future. >>>> >>>>> Most of the similar issues I have found have suggested this >>>>> would be related to the jar files and possibly some sort of >>>>> conflict. However, the lib structure for tomcat 9 is different >>>>> to tomcat5 and I'm not sure which jars could be causing this. >>>>> e.g. >>>>> https://stackoverflow.com/questions/22552244/tomcat-7-fails-to-compi >>le >>>> >>>>> >>- - -jsp- >>>>> >>>>> >>>> pages >>>> >>>> JAR files might conflict, but that depends upon what you have >>>> done so far. Easy questions: >>>> >>>> 1. Have you added anything to Tomcat's lib/ directory (that would >>>> be CATALINA_HOME/lib or CATALINA_BASE/lib -- or both) after >>>> installing Tomcat 8/9? >>> >>> Yes, I’ve added some jars. Some I can’t remember why I’ve added >>> them but doubt they’d be connected to the problem. Here’s a list >>> of the CATALINA_HOME/lib directory: (the last 4 being the ones that >>> have been added) >>> >>> [snip] >>> >>> -rw-r--r--. 1 tomcat tomcat 313898 Dec 20 13:57 dom4j-1.6.1.jar >>> -rw-r--r--. 1 tomcat tomcat 802494 Dec 20 13:57 >>> freemarker-2.3.8.jar -rw-r--r--. 1 tomcat tomcat 355030 Dec 20 >>> 13:57 mail.jar -rw-r--r--. 1 tomcat tomcat 713037 Dec 20 14:15 >>> postgresql-42.1.4.jar >> >>Yup, those look "foreign". >> >>If possible, I'd move all of those except for the postgresql driver >>into your web application's WEB-INF/lib folder. We can move them back >>if absolutely necessary. >> >>Is "mail.jar" the JavaMail API/implementation? You'd only need that in >>Tomcat's lib/ directory if you were asking Tomcat to provide mail >>session via JNDI -- such would appear somewhere in either your web >>applications' META-INF/context.xml file or some file under >>CATALINA_BASE/conf/* >> >>Check your version of JavaMail. There are older versions which contain >>vulnerabilities that have been patched. The API is (AFAICT) 100% >>backward-compatible, so you should be able to upgrade to >>JavaMail.latest without any problems. YMMV. >> >>>> 2. What JAR files are bundled with your application in >>>> WEB-INF/lib ? >>> >>> -rw-r-. 1 root root 97703 Jan 11 15:05 servlet-api.jar >> >>Remove
Re: Jasper Exception when using Tomcat 9 but works with Tomcat 5.5
Comments at the bottom. (Spoiler alert: Good news!) On 11/01/2018 22:38, "Christopher Schultz" <ch...@christopherschultz.net> wrote: >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA256 > >Sean, > >On 1/11/18 11:58 AM, Sean Brett wrote: >> On 11/01/2018 15:48, "Christopher Schultz" >> <ch...@christopherschultz.net> wrote: >> >> >>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 >>> >>> Sean, >>> >>> (Thanks for moving to the mailing list; it's a much better forum >>> for getting into a protracted discussion. See below for more, >>> inline.) >>> >>> On 1/10/18 9:08 AM, Sean Brett wrote: >>>> I've been tasked with migrating a site from one institution to >>>> another. As part of the process we are attempting to update >>>> the versions the site uses. >>>> >>>> Initially I was asked to use Java 8 with Tomcat 5.5 (on >>>> Linux), which led to issues - not to mention Tomcat 5 being >>>> 'out of support¹. I have since tried to deploy the webapps to >>>> Tomcat 9 with Java 8. Some of the webapps appear to run fine >>>> (and resolve the issues I was having with Tomcat5). However, >>>> the main app (and 2 similar/smaller web apps) throws a >>>> JasperException when I go to the index.jsp - the same web apps >>>> deployed to Tomcat 5.5 load without issue. >>> >>> Moving to a later Tomcat version is best. We'll help you figure >>> out these issues so you can use a current version and be >>> better-equipped to stay current into the future. >>> >>>> Most of the similar issues I have found have suggested this >>>> would be related to the jar files and possibly some sort of >>>> conflict. However, the lib structure for tomcat 9 is different >>>> to tomcat5 and I'm not sure which jars could be causing this. >>>> e.g. >>>> https://stackoverflow.com/questions/22552244/tomcat-7-fails-to-compi >le >>> >>>> >- - -jsp- >>>> >>>> >>> pages >>> >>> JAR files might conflict, but that depends upon what you have >>> done so far. Easy questions: >>> >>> 1. Have you added anything to Tomcat's lib/ directory (that would >>> be CATALINA_HOME/lib or CATALINA_BASE/lib -- or both) after >>> installing Tomcat 8/9? >> >> Yes, I’ve added some jars. Some I can’t remember why I’ve added >> them but doubt they’d be connected to the problem. Here’s a list >> of the CATALINA_HOME/lib directory: (the last 4 being the ones that >> have been added) >> >> [snip] >> >> -rw-r--r--. 1 tomcat tomcat 313898 Dec 20 13:57 dom4j-1.6.1.jar >> -rw-r--r--. 1 tomcat tomcat 802494 Dec 20 13:57 >> freemarker-2.3.8.jar -rw-r--r--. 1 tomcat tomcat 355030 Dec 20 >> 13:57 mail.jar -rw-r--r--. 1 tomcat tomcat 713037 Dec 20 14:15 >> postgresql-42.1.4.jar > >Yup, those look "foreign". > >If possible, I'd move all of those except for the postgresql driver >into your web application's WEB-INF/lib folder. We can move them back >if absolutely necessary. > >Is "mail.jar" the JavaMail API/implementation? You'd only need that in >Tomcat's lib/ directory if you were asking Tomcat to provide mail >session via JNDI -- such would appear somewhere in either your web >applications' META-INF/context.xml file or some file under >CATALINA_BASE/conf/* > >Check your version of JavaMail. There are older versions which contain >vulnerabilities that have been patched. The API is (AFAICT) 100% >backward-compatible, so you should be able to upgrade to >JavaMail.latest without any problems. YMMV. > >>> 2. What JAR files are bundled with your application in >>> WEB-INF/lib ? >> >> -rw-r-. 1 root root 97703 Jan 11 15:05 servlet-api.jar > >Remove that one. Tomcat should refuse to load it, but you should >remove it anyway. > >> -rw-r-. 1 root root 8356134 Jan 11 15:05 rt.jar > >Is that the Java JDK's runtime library? If so, remove that as well. >Tomcat should refuse to load classes over-top of the standard java.*, >javax.*, and a few other top-level packages but it's always possible >something might sneak in there and confuse everything. > >> -rw-r-. 1 root root 474746 Jan 11 15:05 >> postgresql-8.3-603.jdbc4.jar> -rw-r-. 1 root root 355030 Jan >> 11 15:05 mail.jar > >If you have either (or both) of these in Tomcat's CATALINA_BASE/lib or >CATALINA_HOME/lib directories, you'll
Re: Jasper Exception when using Tomcat 9 but works with Tomcat 5.5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Sean, On 1/11/18 11:58 AM, Sean Brett wrote: > On 11/01/2018 15:48, "Christopher Schultz" > <ch...@christopherschultz.net> wrote: > > >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 >> >> Sean, >> >> (Thanks for moving to the mailing list; it's a much better forum >> for getting into a protracted discussion. See below for more, >> inline.) >> >> On 1/10/18 9:08 AM, Sean Brett wrote: >>> I've been tasked with migrating a site from one institution to >>> another. As part of the process we are attempting to update >>> the versions the site uses. >>> >>> Initially I was asked to use Java 8 with Tomcat 5.5 (on >>> Linux), which led to issues - not to mention Tomcat 5 being >>> 'out of support¹. I have since tried to deploy the webapps to >>> Tomcat 9 with Java 8. Some of the webapps appear to run fine >>> (and resolve the issues I was having with Tomcat5). However, >>> the main app (and 2 similar/smaller web apps) throws a >>> JasperException when I go to the index.jsp - the same web apps >>> deployed to Tomcat 5.5 load without issue. >> >> Moving to a later Tomcat version is best. We'll help you figure >> out these issues so you can use a current version and be >> better-equipped to stay current into the future. >> >>> Most of the similar issues I have found have suggested this >>> would be related to the jar files and possibly some sort of >>> conflict. However, the lib structure for tomcat 9 is different >>> to tomcat5 and I'm not sure which jars could be causing this. >>> e.g. >>> https://stackoverflow.com/questions/22552244/tomcat-7-fails-to-compi le >> >>> - - -jsp- >>> >>> >> pages >> >> JAR files might conflict, but that depends upon what you have >> done so far. Easy questions: >> >> 1. Have you added anything to Tomcat's lib/ directory (that would >> be CATALINA_HOME/lib or CATALINA_BASE/lib -- or both) after >> installing Tomcat 8/9? > > Yes, I’ve added some jars. Some I can’t remember why I’ve added > them but doubt they’d be connected to the problem. Here’s a list > of the CATALINA_HOME/lib directory: (the last 4 being the ones that > have been added) > > [snip] > > -rw-r--r--. 1 tomcat tomcat 313898 Dec 20 13:57 dom4j-1.6.1.jar > -rw-r--r--. 1 tomcat tomcat 802494 Dec 20 13:57 > freemarker-2.3.8.jar -rw-r--r--. 1 tomcat tomcat 355030 Dec 20 > 13:57 mail.jar -rw-r--r--. 1 tomcat tomcat 713037 Dec 20 14:15 > postgresql-42.1.4.jar Yup, those look "foreign". If possible, I'd move all of those except for the postgresql driver into your web application's WEB-INF/lib folder. We can move them back if absolutely necessary. Is "mail.jar" the JavaMail API/implementation? You'd only need that in Tomcat's lib/ directory if you were asking Tomcat to provide mail session via JNDI -- such would appear somewhere in either your web applications' META-INF/context.xml file or some file under CATALINA_BASE/conf/* Check your version of JavaMail. There are older versions which contain vulnerabilities that have been patched. The API is (AFAICT) 100% backward-compatible, so you should be able to upgrade to JavaMail.latest without any problems. YMMV. >> 2. What JAR files are bundled with your application in >> WEB-INF/lib ? > > -rw-r-. 1 root root 97703 Jan 11 15:05 servlet-api.jar Remove that one. Tomcat should refuse to load it, but you should remove it anyway. > -rw-r-. 1 root root 8356134 Jan 11 15:05 rt.jar Is that the Java JDK's runtime library? If so, remove that as well. Tomcat should refuse to load classes over-top of the standard java.*, javax.*, and a few other top-level packages but it's always possible something might sneak in there and confuse everything. > -rw-r-. 1 root root 474746 Jan 11 15:05 > postgresql-8.3-603.jdbc4.jar> -rw-r-. 1 root root 355030 Jan > 11 15:05 mail.jar If you have either (or both) of these in Tomcat's CATALINA_BASE/lib or CATALINA_HOME/lib directories, you'll want to remove them from here. > -rw-r-. 1 root root 352668 Jan 11 15:05 log4j-1.2.8.jar Ok. > -rw-r-. 1 root root 55008 Jan 11 15:05 local-ldap-0.0.1.jar > -rw-r-. 1 root root 38114 Jan 11 15:05 ldap-src-0.0.1.jar > -rw-r-. 1 root root 38668 Jan 11 15:05 ldap.jar -rw-r-. 1 > root root 55827 Jan 11 15:05 ldap-0.0.1.jar Hmm. Does your application use LDAP directly? > -rw-r-. 1 root root 146718 Jan 11 15:05 jdom.jar -rw-r-. 1 > root root 173211 Jan 11 15:05 IonoMap.jar -rw-r-. 1 root root > 457002 Jan 11 1
Re: Jasper Exception when using Tomcat 9 but works with Tomcat 5.5
Thanks for the input Chris, I’ve responded inline... On 11/01/2018 15:48, "Christopher Schultz" <ch...@christopherschultz.net> wrote: >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA256 > >Sean, > >(Thanks for moving to the mailing list; it's a much better forum for >getting into a protracted discussion. See below for more, inline.) > >On 1/10/18 9:08 AM, Sean Brett wrote: >> I've been tasked with migrating a site from one institution to >> another. As part of the process we are attempting to update the >> versions the site uses. >> >> Initially I was asked to use Java 8 with Tomcat 5.5 (on Linux), >> which led to issues - not to mention Tomcat 5 being 'out of >> support¹. I have since tried to deploy the webapps to Tomcat 9 >> with Java 8. Some of the webapps appear to run fine (and resolve >> the issues I was having with Tomcat5). However, the main app (and 2 >> similar/smaller web apps) throws a JasperException when I go to the >> index.jsp - the same web apps deployed to Tomcat 5.5 load without >> issue. > >Moving to a later Tomcat version is best. We'll help you figure out >these issues so you can use a current version and be better-equipped >to stay current into the future. > >> Most of the similar issues I have found have suggested this would >> be related to the jar files and possibly some sort of conflict. >> However, the lib structure for tomcat 9 is different to tomcat5 and >> I'm not sure which jars could be causing this. e.g. >> https://stackoverflow.com/questions/22552244/tomcat-7-fails-to-compile >- -jsp- >> >> >pages > >JAR files might conflict, but that depends upon what you have done so >far. Easy questions: > >1. Have you added anything to Tomcat's lib/ directory (that would be >CATALINA_HOME/lib or CATALINA_BASE/lib -- or both) after installing >Tomcat 8/9? Yes, I’ve added some jars. Some I can’t remember why I’ve added them but doubt they’d be connected to the problem. Here’s a list of the CATALINA_HOME/lib directory: (the last 4 being the ones that have been added) -rw-r-. 1 tomcat tomcat 36940 Sep 27 18:32 websocket-api.jar -rw-r-. 1 tomcat tomcat 216799 Sep 27 18:32 tomcat-websocket.jar -rw-r-. 1 tomcat tomcat 203098 Sep 27 18:32 tomcat-util-scan.jar -rw-r-. 1 tomcat tomcat 132773 Sep 27 18:32 tomcat-util.jar -rw-r-. 1 tomcat tomcat 34540 Sep 27 18:32 tomcat-jni.jar -rw-r-. 1 tomcat tomcat 144927 Sep 27 18:32 tomcat-jdbc.jar -rw-r-. 1 tomcat tomcat 42274 Sep 27 18:32 tomcat-i18n-ja.jar -rw-r-. 1 tomcat tomcat 39391 Sep 27 18:32 tomcat-i18n-fr.jar -rw-r-. 1 tomcat tomcat 65452 Sep 27 18:32 tomcat-i18n-es.jar -rw-r-. 1 tomcat tomcat 251863 Sep 27 18:32 tomcat-dbcp.jar -rw-r-. 1 tomcat tomcat 792447 Sep 27 18:32 tomcat-coyote.jar -rw-r-. 1 tomcat tomcat 10643 Sep 27 18:32 tomcat-api.jar -rw-r-. 1 tomcat tomcat 277812 Sep 27 18:32 servlet-api.jar -rw-r-. 1 tomcat tomcat 61763 Sep 27 18:32 jsp-api.jar -rw-r-. 1 tomcat tomcat 26859 Sep 27 18:32 jaspic-api.jar -rw-r-. 1 tomcat tomcat 547928 Sep 27 18:32 jasper.jar -rw-r-. 1 tomcat tomcat 163671 Sep 27 18:32 jasper-el.jar -rw-r-. 1 tomcat tomcat 81575 Sep 27 18:32 el-api.jar -rw-r-. 1 tomcat tomcat 2450404 Sep 27 18:32 ecj-4.6.3.jar -rw-r-. 1 tomcat tomcat 285214 Sep 27 18:32 catalina-tribes.jar -rw-r-. 1 tomcat tomcat 75123 Sep 27 18:32 catalina-storeconfig.jar -rw-r-. 1 tomcat tomcat 1607874 Sep 27 18:32 catalina.jar -rw-r-. 1 tomcat tomcat 119105 Sep 27 18:32 catalina-ha.jar -rw-r-. 1 tomcat tomcat 54233 Sep 27 18:32 catalina-ant.jar -rw-r-. 1 tomcat tomcat 18253 Sep 27 18:32 annotations-api.jar -rw-r--r--. 1 tomcat tomcat 313898 Dec 20 13:57 dom4j-1.6.1.jar -rw-r--r--. 1 tomcat tomcat 802494 Dec 20 13:57 freemarker-2.3.8.jar -rw-r--r--. 1 tomcat tomcat 355030 Dec 20 13:57 mail.jar -rw-r--r--. 1 tomcat tomcat 713037 Dec 20 14:15 postgresql-42.1.4.jar > >2. What JAR files are bundled with your application in WEB-INF/lib ? -rw-r-. 1 root root 97703 Jan 11 15:05 servlet-api.jar -rw-r-. 1 root root 8356134 Jan 11 15:05 rt.jar -rw-r-. 1 root root 474746 Jan 11 15:05 postgresql-8.3-603.jdbc4.jar -rw-r-. 1 root root 355030 Jan 11 15:05 mail.jar -rw-r-. 1 root root 352668 Jan 11 15:05 log4j-1.2.8.jar -rw-r-. 1 root root 55008 Jan 11 15:05 local-ldap-0.0.1.jar -rw-r-. 1 root root 38114 Jan 11 15:05 ldap-src-0.0.1.jar -rw-r-. 1 root root 38668 Jan 11 15:05 ldap.jar -rw-r-. 1 root root 55827 Jan 11 15:05 ldap-0.0.1.jar -rw-r-. 1 root root 146718 Jan 11 15:05 jdom.jar -rw-r-. 1 root root 173211 Jan 11 15:05 IonoMap.jar -rw-r-. 1 root root 457002 Jan 11 15:05 ibmjndi.jar -rw-r-. 1 root root 38015 Jan 11 15:05 commons-logging-1.
Re: Jasper Exception when using Tomcat 9 but works with Tomcat 5.5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Sean, (Thanks for moving to the mailing list; it's a much better forum for getting into a protracted discussion. See below for more, inline.) On 1/10/18 9:08 AM, Sean Brett wrote: > I've been tasked with migrating a site from one institution to > another. As part of the process we are attempting to update the > versions the site uses. > > Initially I was asked to use Java 8 with Tomcat 5.5 (on Linux), > which led to issues - not to mention Tomcat 5 being 'out of > support¹. I have since tried to deploy the webapps to Tomcat 9 > with Java 8. Some of the webapps appear to run fine (and resolve > the issues I was having with Tomcat5). However, the main app (and 2 > similar/smaller web apps) throws a JasperException when I go to the > index.jsp - the same web apps deployed to Tomcat 5.5 load without > issue. Moving to a later Tomcat version is best. We'll help you figure out these issues so you can use a current version and be better-equipped to stay current into the future. > Most of the similar issues I have found have suggested this would > be related to the jar files and possibly some sort of conflict. > However, the lib structure for tomcat 9 is different to tomcat5 and > I'm not sure which jars could be causing this. e.g. > https://stackoverflow.com/questions/22552244/tomcat-7-fails-to-compile - -jsp- > > pages JAR files might conflict, but that depends upon what you have done so far. Easy questions: 1. Have you added anything to Tomcat's lib/ directory (that would be CATALINA_HOME/lib or CATALINA_BASE/lib -- or both) after installing Tomcat 8/9? 2. What JAR files are bundled with your application in WEB-INF/lib ? > I've also tried changing the index.jsp into a simpler (HelloWorld) > form - removing any code. And tried deleting the 'work' directory > before restarting Tomcat > (http://grokbase.com/t/tomcat/users/072v2kf60h/java-permission-denied- error > > - -in-tomcat). In both cases the exception is still thrown. Can you post the full text of HelloWorld.jsp? I'm wondering if you have some odd syntax or are expecting to use a "custom base JSP servlet class" or something like that which is no longer compatible with Tomcat's current JSP servlet. If so, we'll try to figure out why the custom code was necessary and make arrangements to replace it. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlpXh1QdHGNocmlzQGNo cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFiFnA//ebj5XoXFXG0vEAIA DVSR2X8JwfeiW5Fiamt1h1jw1a/zl92Q9TBsqJ4ocxceipules1+us7Tpi0QyURt OozqydqC8+qm7N/m/LBPk8Mxo/dMgV7s5Yk2bITlQFbPzKrlkgfL2YKDcbsNlBWs RZxUdVD11GkdDp9DGUDdoYcMjYW+nDhHr9NLjlKvpyCUZ1lwJ68uSPahzJL6/ba+ FNiXsghDNGi7aZOh8P0Hy3A/5pYhdugcU8M1HYtMbdGrmqaKGB9afjGT7Odp5Eo+ 38bIc5wWJZN9Ak6IVzi3Avloa3STckDuzGlWkTS82q9cpG8uy461F2MHC0yjZha6 +rZz299/QZ2Ouzbc2ICUxJLWsQvSfWii9zdAS8y6+LevmyFzpgbTdTsQfOPicGtc +Ow9VWl2SJe+sPNFkgOdKP+XkKTOPUJjdP+hhjOzUPpEjJ71Hcf5x8bZ1EuceAt4 ORnM9LCFY4ecSIAhmMivdajxHHHf2IWvCnI4emaTjlULUiyq70go9bBAjiTd2k18 oMsr1gIXgWonp3Gl3RW7/o/fXilaPIOJeEeKPEKgPtvEFf56EkkAouPo/KXiDIMF CJMDPGSPx2n7ITZcFJnT0vIZFIJh9fZqUuxAnqG/f5A9cN7QGQf2sORKUgWMOZtp 5G743rnFC/IQE3t1irkHxn/yK0s= =W9Le -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Jasper Exception when using Tomcat 9 but works with Tomcat 5.5
I've been tasked with migrating a site from one institution to another. As part of the process we are attempting to update the versions the site uses. Initially I was asked to use Java 8 with Tomcat 5.5 (on Linux), which led to issues - not to mention Tomcat 5 being 'out of support¹. I have since tried to deploy the webapps to Tomcat 9 with Java 8. Some of the webapps appear to run fine (and resolve the issues I was having with Tomcat5). However, the main app (and 2 similar/smaller web apps) throws a JasperException when I go to the index.jsp - the same web apps deployed to Tomcat 5.5 load without issue. Most of the similar issues I have found have suggested this would be related to the jar files and possibly some sort of conflict. However, the lib structure for tomcat 9 is different to tomcat5 and I'm not sure which jars could be causing this. e.g. https://stackoverflow.com/questions/22552244/tomcat-7-fails-to-compile-jsp- pages I've also tried changing the index.jsp into a simpler (HelloWorld) form - removing any code. And tried deleting the 'work' directory before restarting Tomcat (http://grokbase.com/t/tomcat/users/072v2kf60h/java-permission-denied-error -in-tomcat). In both cases the exception is still thrown. The exception thrown is: --- --- - org.apache.jasper.JasperException: Unable to compile class for JSP <http://www.coderanch.com/forums/f-50/jsp>: An error occurred at line: [15] in the generated java file: [/opt/tomcat9/work/Catalina/localhost/home/org/apache/jsp/index_jsp.java] The type index_jsp must implement the inherited abstract method JspSourceImports.getPackageImports() An error occurred at line: [15] in the generated java file: [/opt/tomcat9/work/Catalina/localhost/home/org/apache/jsp/index_jsp.java] The type index_jsp must implement the inherited abstract method JspSourceImports.getClassImports() An error occurred at line: [15] in the generated java file: [/opt/tomcat9/work/Catalina/localhost/home/org/apache/jsp/index_jsp.java] The type index_jsp must implement the inherited abstract method JspSourceDependent.getDependants() An error occurred at line: [22] in the generated java file: [/opt/tomcat9/work/Catalina/localhost/home/org/apache/jsp/index_jsp.java] The type Map is not generic; it cannot be parameterized with arguments http://www.coderanch.com/t/410859/java/java/string-stringbuffer-stringbuil der-performance>, Long> An error occurred at line: [24] in the generated java file: [/opt/tomcat9/work/Catalina/localhost/home/org/apache/jsp/index_jsp.java] The type Set is not generic; it cannot be parameterized with arguments An error occurred at line: [26] in the generated java file: [/opt/tomcat9/work/Catalina/localhost/home/org/apache/jsp/index_jsp.java] The type Set is not generic; it cannot be parameterized with arguments An error occurred at line: [29] in the generated java file: [/opt/tomcat9/work/Catalina/localhost/home/org/apache/jsp/index_jsp.java] _jspx_imports_packages cannot be resolved to a variable ... ... ... Stacktrace: org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandl er.java:103) org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java: 213) org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:458) org.apache.jasper.compiler.Compiler.compile(Compiler.java:389) org.apache.jasper.compiler.Compiler.compile(Compiler.java:361) org.apache.jasper.compiler.Compiler.compile(Compiler.java:345) org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java: 603) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java: 369) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:385) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:329) javax.servlet.http.HttpServlet.service(HttpServlet.java:741) org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53) edu.purdue.cybercenter.ionomics.servlet.PiiMS.doGet(PiiMS.java:83) javax.servlet.http.HttpServlet.service(HttpServlet.java:634) javax.servlet.http.HttpServlet.service(HttpServlet.java:741) org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53) ‹‹‹ ‹‹ This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked
RE: Apache TomCat 5.5
Mary - First, sorry for the top-post. I noticed in your original post that you have upgraded to the latest Java 8, and nearly latest Windows version (at least new than the release available when Tomcat 5.5 was first available). I don't understand why you can't just go ahead and upgrade to the latest Tomcat 8 or 8.5 implementation. As others have said, it is quite likely that your application will run just fine. Without more details of your exact implementation environment, I can't give full advice, but here are some things to take into account: 1) If you are terminating SSL at the IIS7 client interface, then that is where you need to enable HSTS. It only needs to be on the IIS7-Tomcat conversation if that is also using SSL on its linkage (not normally needed for an internal network, but your requirements may specify otherwise). Strip it out of headers on the way to Tomcat and add it back on the way to client if necessary. 2) When going from such an old Version of Tomcat to a newer one, be aware that Tomcat configuration files and options HAVE changed. You cannot just copy server.xml, context.xml, etc. files from the old version to the new. You must migrate your settings to the new versions. This is not that difficult or time-consuming, but it is best to do this manually. 3) Beware of any changes to provided valves/filters that you rely on. Changes to those in new versions may require you to handle them differently. 4) Do this all in a test/dev environment, possibly several times, before even thinking about changing production. 5) If the addition of an additional/unknown HTTP header is causing problems with your backend processing, then you have more problems than you think you do. You application is in violation of the most basic tenets of the HTTP protocol stack, as those headers should just be ignored according to the protocol. Your application may stop working correctly in the next few months even without you doing anything to your current setup. Respectfully, Jeff > -Original Message- > From: Pham, Mary (NIH/OD/ORS) [E] [mailto:maryp...@mail.nih.gov] > Sent: Wednesday, September 21, 2016 9:52 AM > To: 'Tomcat Users List' <users@tomcat.apache.org> > Subject: RE: Apache TomCat 5.5 > > Thank you. Chris, Chuck, Andre, Mark who had answered and I've done > this far. > My report. > - I installed the "URL rewrite" module on IIS 7. To make short, it > worked. http to https redirected then enforced hsts on the IIS site. > - but broke all the scripts run on Tomcat due to Strick Transport > Security when HTTPS. > - so I have to disable in/outbound of URL rewrite. > Back to square one. We will not be able to upgrade Tomcat at this time. > > Please help. > > -Mary > > -Original Message- > From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Sent: Thursday, September 15, 2016 11:01 AM > To: Tomcat Users List <users@tomcat.apache.org> > Subject: Re: Apache TomCat 5.5 > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > André, > > On 9/14/16 7:04 PM, André Warnier (tomcat) wrote: > > Mary, have a look here : > > http://tomcat.apache.org/whichversion.html Tomcat 5.5 was first > > released about 10 years ago, and the last modification to it was in > > 2012. The current "stable" version is Tomcat 8.5.5. > > > > For Open Source and free software such as Apache Tomcat, that means > > that your chances of getting support and help for such an old version > > are really not good, because most of the people which would be able to > > help you probably do not run that version anywhere anymore. Even the > > documentation is not directly available on-line anymore. > > > > Regarding your particular issue, it is even possible that the > > requirement which you are mentioning is younger than Tomcat 5.5 and > > cannot be met by such an old software version. It is even likely that, > > considering the age of your Tomcat and the age of the Java JVM it is > > probably running under, there are a whole lot of other security issues > > with your server, which make it impossible to make it "secure as the > > government requires". > > > > What I am saying is that you are probably wasting your time, and > > ultimately your employer's time, with this approach. > > > > You seem to mention below that you are using Tomcat "with IIS". > > Maybe this IIS is a front-end to Tomcat, and users access Tomcat > > always through IIS. If so, then as long as the connection between IIS > > and Tomcat is secure (e.g. they run on the same host), then you should > > probably take care of the SSL/HTTPS (and header) aspect on the IIS > > front-end. That is, if you /real
Re: Apache TomCat 5.5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mary, On 9/21/16 10:51 AM, Pham, Mary (NIH/OD/ORS) [E] wrote: > Thank you. Chris, Chuck, Andre, Mark who had answered and I've > done this far. My report. > > - I installed the "URL rewrite" module on IIS 7. To make short, > it worked. http to https redirected then enforced hsts on the IIS > site. - but broke all the scripts run on Tomcat due to Strick > Transport Security when HTTPS. - so I have to disable in/outbound > of URL rewrite. > > Back to square one. We will not be able to upgrade Tomcat at this > time. So you have several requirements, here: 1. Stay on Tomcat 5.5 2. Implement HSTS 3. Have your scripts all work It sounds like #2 and #3 conflict, since evidently HSTS "broke all the scripts to run on Tomcat". Your only option is to fix your application so that it will work with HSTS enabled. Upgrading Tomcat doesn't really have any bearing on any of this, since you could upgrade Tomcat and still not enable HSTS. - -chris > -Original Message- From: Christopher Schultz > [mailto:ch...@christopherschultz.net] Sent: Thursday, September 15, > 2016 11:01 AM To: Tomcat Users List <users@tomcat.apache.org> > Subject: Re: Apache TomCat 5.5 > > André, > > On 9/14/16 7:04 PM, André Warnier (tomcat) wrote: >> Mary, have a look here : >> http://tomcat.apache.org/whichversion.html Tomcat 5.5 was first >> released about 10 years ago, and the last modification to it was >> in 2012. The current "stable" version is Tomcat 8.5.5. > >> For Open Source and free software such as Apache Tomcat, that >> means that your chances of getting support and help for such an >> old version are really not good, because most of the people which >> would be able to help you probably do not run that version >> anywhere anymore. Even the documentation is not directly >> available on-line anymore. > >> Regarding your particular issue, it is even possible that the >> requirement which you are mentioning is younger than Tomcat 5.5 >> and cannot be met by such an old software version. It is even >> likely that, considering the age of your Tomcat and the age of >> the Java JVM it is probably running under, there are a whole lot >> of other security issues with your server, which make it >> impossible to make it "secure as the government requires". > >> What I am saying is that you are probably wasting your time, and >> ultimately your employer's time, with this approach. > >> You seem to mention below that you are using Tomcat "with IIS". >> Maybe this IIS is a front-end to Tomcat, and users access Tomcat >> always through IIS. If so, then as long as the connection >> between IIS and Tomcat is secure (e.g. they run on the same >> host), then you should probably take care of the SSL/HTTPS (and >> header) aspect on the IIS front-end. That is, if you /really/ >> cannot upgrade Tomcat and if your applications /really/ do not >> run under a newer version of Tomcat and Java. > > HSTS is just an HTTP header thing. It can be deployed on any > version of anything basically back until the beginning of (HTTP) > time. > > It's slightly easier to do with more recent Tomcats because of the > inclusion of both the HTTP Header Security Filter[1] and the > rewrite valve[2] (oddly not mentioned in the "Valves" section of > the "Configuration" reference), but anyone can write a simple > Filter and add it to their web application to add these headers. In > fact, I wouldn't surprised if Tomcat's HTTP Header Security Filter > included with Tomcat 8+ would work just fine on Tomcat 5.5. You > just need to grab the code, compile it, and drop it into your own > application. > > Since you mentioned IIS, I think you're right that IIS is probably > a better place to configure these HSTS headers. > > Mary, ultimately, Tomcat 5.5 should definitely be upgraded to > Tomcat 8 or later. You should take your web application and deploy > it on Tomcat 8.0 or Tomcat 8.5 in a testing environment and just > see what happens. You might be surprised: it will probably with > right away without any modifications. > > Hope that helps, -chris > > [1] http://tomcat.apache.org/tomcat-7.0-doc/config/filter.html [2] > http://tomcat.apache.org/tomcat-8.0-doc/rewrite.html > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > - > > To unsubscribe, e-mail: users-unsubs
RE: Apache TomCat 5.5
Thank you. Chris, Chuck, Andre, Mark who had answered and I've done this far. My report. - I installed the "URL rewrite" module on IIS 7. To make short, it worked. http to https redirected then enforced hsts on the IIS site. - but broke all the scripts run on Tomcat due to Strick Transport Security when HTTPS. - so I have to disable in/outbound of URL rewrite. Back to square one. We will not be able to upgrade Tomcat at this time. Please help. -Mary -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Thursday, September 15, 2016 11:01 AM To: Tomcat Users List <users@tomcat.apache.org> Subject: Re: Apache TomCat 5.5 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 9/14/16 7:04 PM, André Warnier (tomcat) wrote: > Mary, have a look here : > http://tomcat.apache.org/whichversion.html Tomcat 5.5 was first > released about 10 years ago, and the last modification to it was in > 2012. The current "stable" version is Tomcat 8.5.5. > > For Open Source and free software such as Apache Tomcat, that means > that your chances of getting support and help for such an old version > are really not good, because most of the people which would be able to > help you probably do not run that version anywhere anymore. Even the > documentation is not directly available on-line anymore. > > Regarding your particular issue, it is even possible that the > requirement which you are mentioning is younger than Tomcat 5.5 and > cannot be met by such an old software version. It is even likely that, > considering the age of your Tomcat and the age of the Java JVM it is > probably running under, there are a whole lot of other security issues > with your server, which make it impossible to make it "secure as the > government requires". > > What I am saying is that you are probably wasting your time, and > ultimately your employer's time, with this approach. > > You seem to mention below that you are using Tomcat "with IIS". > Maybe this IIS is a front-end to Tomcat, and users access Tomcat > always through IIS. If so, then as long as the connection between IIS > and Tomcat is secure (e.g. they run on the same host), then you should > probably take care of the SSL/HTTPS (and header) aspect on the IIS > front-end. That is, if you /really/ cannot upgrade Tomcat and if your > applications /really/ do not run under a newer version of Tomcat and > Java. HSTS is just an HTTP header thing. It can be deployed on any version of anything basically back until the beginning of (HTTP) time. It's slightly easier to do with more recent Tomcats because of the inclusion of both the HTTP Header Security Filter[1] and the rewrite valve[2] (oddly not mentioned in the "Valves" section of the "Configuration" reference), but anyone can write a simple Filter and add it to their web application to add these headers. In fact, I wouldn't surprised if Tomcat's HTTP Header Security Filter included with Tomcat 8+ would work just fine on Tomcat 5.5. You just need to grab the code, compile it, and drop it into your own application. Since you mentioned IIS, I think you're right that IIS is probably a better place to configure these HSTS headers. Mary, ultimately, Tomcat 5.5 should definitely be upgraded to Tomcat 8 or later. You should take your web application and deploy it on Tomcat 8.0 or Tomcat 8.5 in a testing environment and just see what happens. You might be surprised: it will probably with right away without any modifications. Hope that helps, - -chris [1] http://tomcat.apache.org/tomcat-7.0-doc/config/filter.html [2] http://tomcat.apache.org/tomcat-8.0-doc/rewrite.html -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJX2reWAAoJEBzwKT+lPKRYp7MQAJ6nRq3m47o2BEX6nwTBNFFb lcOfn/2L0dTfhESp/7EHqAcJaTvCHT6JH+RKplQ4gito4cJ8F2tp0HBiLRNukxjB dxnZL7q5j6Z/41vrLMWX94WI4zz1PMqlhrEMI0/pEtRQFx07h0aE7WLp4CY6JMTl dCGcuqkEgzNmjL1se+3+Aj3uVd0QAYESfT24AbLK0MHyrkmtIhRfr8W03C/ouD8M 9xcZ9f9BemvneI2zwiUelXaTvE4sCkPf3ULp/xw0MNYGLgl6VS8yByt1KwQsFzal YPK+UL+k/JK6sxvGpsVLTvmY6StWYXOJZzp4C38YHxj7L5exDpDc/gCAClGm5kM/ uS1vVLL8jlkxby6k3mk5eU43M/HZkgAL+3FNjYCOcnvlsyJKsvQ9qai7Mal2N1Zt jolFNDZCxWxfXLBPM/BLnfaYTYS6FXWZmAT5QrbnqAoxG9iKWsiMloPym8xdO36+ vIxOeNevWZif7MbpRUw84oOtcCAm1aZcyjXjwxQwWNciczocZg8d3DSJY53wqcrL nAx5zVbxE5h3nBKSuuNl3s1WGXf7hySYxWyCg7Ya67EsGGeDT1rlLaotXI8PdKOL qB32fz6PRJZspxJDefQGSHWrjq3gBAqeNFzp/3vj9tmvdCDkdzT0xNJH9s/6YGVE 7whnGB6jlseII/fYe6s1 =hetE -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Apache TomCat 5.5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 9/14/16 7:04 PM, André Warnier (tomcat) wrote: > Mary, have a look here : > http://tomcat.apache.org/whichversion.html Tomcat 5.5 was first > released about 10 years ago, and the last modification to it was in > 2012. The current "stable" version is Tomcat 8.5.5. > > For Open Source and free software such as Apache Tomcat, that means > that your chances of getting support and help for such an old > version are really not good, because most of the people which would > be able to help you probably do not run that version anywhere > anymore. Even the documentation is not directly available on-line > anymore. > > Regarding your particular issue, it is even possible that the > requirement which you are mentioning is younger than Tomcat 5.5 > and cannot be met by such an old software version. It is even > likely that, considering the age of your Tomcat and the age of the > Java JVM it is probably running under, there are a whole lot of > other security issues with your server, which make it impossible to > make it "secure as the government requires". > > What I am saying is that you are probably wasting your time, and > ultimately your employer's time, with this approach. > > You seem to mention below that you are using Tomcat "with IIS". > Maybe this IIS is a front-end to Tomcat, and users access Tomcat > always through IIS. If so, then as long as the connection between > IIS and Tomcat is secure (e.g. they run on the same host), then you > should probably take care of the SSL/HTTPS (and header) aspect on > the IIS front-end. That is, if you /really/ cannot upgrade Tomcat > and if your applications /really/ do not run under a newer version > of Tomcat and Java. HSTS is just an HTTP header thing. It can be deployed on any version of anything basically back until the beginning of (HTTP) time. It's slightly easier to do with more recent Tomcats because of the inclusion of both the HTTP Header Security Filter[1] and the rewrite valve[2] (oddly not mentioned in the "Valves" section of the "Configuration" reference), but anyone can write a simple Filter and add it to their web application to add these headers. In fact, I wouldn't surprised if Tomcat's HTTP Header Security Filter included with Tomcat 8+ would work just fine on Tomcat 5.5. You just need to grab the code, compile it, and drop it into your own application. Since you mentioned IIS, I think you're right that IIS is probably a better place to configure these HSTS headers. Mary, ultimately, Tomcat 5.5 should definitely be upgraded to Tomcat 8 or later. You should take your web application and deploy it on Tomcat 8.0 or Tomcat 8.5 in a testing environment and just see what happens. You might be surprised: it will probably with right away without any modifications. Hope that helps, - -chris [1] http://tomcat.apache.org/tomcat-7.0-doc/config/filter.html [2] http://tomcat.apache.org/tomcat-8.0-doc/rewrite.html -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJX2reWAAoJEBzwKT+lPKRYp7MQAJ6nRq3m47o2BEX6nwTBNFFb lcOfn/2L0dTfhESp/7EHqAcJaTvCHT6JH+RKplQ4gito4cJ8F2tp0HBiLRNukxjB dxnZL7q5j6Z/41vrLMWX94WI4zz1PMqlhrEMI0/pEtRQFx07h0aE7WLp4CY6JMTl dCGcuqkEgzNmjL1se+3+Aj3uVd0QAYESfT24AbLK0MHyrkmtIhRfr8W03C/ouD8M 9xcZ9f9BemvneI2zwiUelXaTvE4sCkPf3ULp/xw0MNYGLgl6VS8yByt1KwQsFzal YPK+UL+k/JK6sxvGpsVLTvmY6StWYXOJZzp4C38YHxj7L5exDpDc/gCAClGm5kM/ uS1vVLL8jlkxby6k3mk5eU43M/HZkgAL+3FNjYCOcnvlsyJKsvQ9qai7Mal2N1Zt jolFNDZCxWxfXLBPM/BLnfaYTYS6FXWZmAT5QrbnqAoxG9iKWsiMloPym8xdO36+ vIxOeNevWZif7MbpRUw84oOtcCAm1aZcyjXjwxQwWNciczocZg8d3DSJY53wqcrL nAx5zVbxE5h3nBKSuuNl3s1WGXf7hySYxWyCg7Ya67EsGGeDT1rlLaotXI8PdKOL qB32fz6PRJZspxJDefQGSHWrjq3gBAqeNFzp/3vj9tmvdCDkdzT0xNJH9s/6YGVE 7whnGB6jlseII/fYe6s1 =hetE -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Apache TomCat 5.5
Mary, have a look here : http://tomcat.apache.org/whichversion.html Tomcat 5.5 was first released about 10 years ago, and the last modification to it was in 2012. The current "stable" version is Tomcat 8.5.5. For Open Source and free software such as Apache Tomcat, that means that your chances of getting support and help for such an old version are really not good, because most of the people which would be able to help you probably do not run that version anywhere anymore. Even the documentation is not directly available on-line anymore. Regarding your particular issue, it is even possible that the requirement which you are mentioning is younger than Tomcat 5.5 and cannot be met by such an old software version. It is even likely that, considering the age of your Tomcat and the age of the Java JVM it is probably running under, there are a whole lot of other security issues with your server, which make it impossible to make it "secure as the government requires". What I am saying is that you are probably wasting your time, and ultimately your employer's time, with this approach. You seem to mention below that you are using Tomcat "with IIS". Maybe this IIS is a front-end to Tomcat, and users access Tomcat always through IIS. If so, then as long as the connection between IIS and Tomcat is secure (e.g. they run on the same host), then you should probably take care of the SSL/HTTPS (and header) aspect on the IIS front-end. That is, if you /really/ cannot upgrade Tomcat and if your applications /really/ do not run under a newer version of Tomcat and Java. On 14.09.2016 20:49, Pham, Mary (NIH/OD/ORS) [E] wrote: Hi Daniel, A new bee has to learn on an outdated systems! We cann't up upgrade due to dependency of apps and forms, that's what I've learned. Thank you for the link. To be honest I do not know what to do yet. I've checked and seen several web.xml files, in different directoriesSome I think is original, some had modified. Regards, -Mary -Original Message- From: Daniel Küppers [mailto:dan...@tetralog.com] Sent: Wednesday, September 14, 2016 11:17 AM To: Tomcat Users List <users@tomcat.apache.org> Subject: Re: Apache TomCat 5.5 Hello EveryOne, As new bee of Apache. We have been using one of the old Apache TomCat on windows server 2008R2, IIS 7. After we purchased and installed the SSL certificate. We need to apply a header directive in Apache "Strict-Transport-Security" so that our web site would be secured as the Government required. My question is where can I insert this line? In which and where's the files in Apache TomCat 5.5, JDK 8 updated 102. Is it in the same server.xml file as we modified the connector for SSL. Look forward to hearing from your supports. Regards, Mary Pham Information Technology Specialist National Institutes of Health Library Division of Library Services Office of Research Services 10 Center Drive, Room 1L07, MSC 1150 Bethesda, MD 20892-1150 T. 301.496.1506 maryp...@mail.nih.gov<mailto:maryp...@mail.nih.gov> Hello Mary, you are using a quite outdated tomcat. A quick googling brought me to stackoverflow, which might solve the problem for your tomcat 5.5. the easiest way possible is to add a filter to your webapp and apply the HSTS header in the response. You can make use of the buildin HSTS support, if its possible to upgrade your tomcat to a recent version. Related SO-Question: http://stackoverflow.com/questions/27541755/add-hsts-feature-to-tomcat Best regards, Daniel - 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: Apache TomCat 5.5
> From: Pham, Mary (NIH/OD/ORS) [E] [mailto:maryp...@mail.nih.gov] > Subject: Apache TomCat 5.5 > We have been using one of the old Apache TomCat on windows server 2008R2, IIS > 7. Firstly, it's Tomcat, not TomCat. > We need to apply a header directive in Apache "Strict-Transport-Security" so > that our web site > would be secured as the Government required. Your web site is pretty much guaranteed to be _insecure_ as long as you're running that old - and unsupported - version of Tomcat. The last Tomcat 5.5 release was nearly four years ago, and many, many vulnerabilities have been addressed since then. SSL does not protect you against those. You really must upgrade to a supported level (preferably 8.5), after carefully reading the migration guides: http://tomcat.apache.org/migration.html Not doing so makes anything else you try pointless. > My question is where can I insert this line? As suggested by Daniel, a filter is your best bet - but upgrade Tomcat first. Not doing so leaves you subject to many more liabilities than lack of HSTS. - 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: Apache TomCat 5.5
Hi Daniel, A new bee has to learn on an outdated systems! We cann't up upgrade due to dependency of apps and forms, that's what I've learned. Thank you for the link. To be honest I do not know what to do yet. I've checked and seen several web.xml files, in different directoriesSome I think is original, some had modified. Regards, -Mary -Original Message- From: Daniel Küppers [mailto:dan...@tetralog.com] Sent: Wednesday, September 14, 2016 11:17 AM To: Tomcat Users List <users@tomcat.apache.org> Subject: Re: Apache TomCat 5.5 > Hello EveryOne, > > As new bee of Apache. We have been using one of the old Apache TomCat on > windows server 2008R2, IIS 7. After we purchased and installed the SSL > certificate. We need to apply a header directive in Apache > "Strict-Transport-Security" so that our web site would be secured as the > Government required. My question is where can I insert this line? In which > and where's the files in Apache TomCat 5.5, JDK 8 updated 102. Is it in the > same server.xml file as we modified the connector for SSL. > Look forward to hearing from your supports. > > Regards, > > > Mary Pham > Information Technology Specialist > National Institutes of Health Library > Division of Library Services > Office of Research Services > 10 Center Drive, Room 1L07, MSC 1150 > Bethesda, MD 20892-1150 > T. 301.496.1506 > maryp...@mail.nih.gov<mailto:maryp...@mail.nih.gov> Hello Mary, you are using a quite outdated tomcat. A quick googling brought me to stackoverflow, which might solve the problem for your tomcat 5.5. the easiest way possible is to add a filter to your webapp and apply the HSTS header in the response. You can make use of the buildin HSTS support, if its possible to upgrade your tomcat to a recent version. Related SO-Question: http://stackoverflow.com/questions/27541755/add-hsts-feature-to-tomcat Best regards, Daniel - 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: Apache TomCat 5.5
Hello EveryOne, As new bee of Apache. We have been using one of the old Apache TomCat on windows server 2008R2, IIS 7. After we purchased and installed the SSL certificate. We need to apply a header directive in Apache "Strict-Transport-Security" so that our web site would be secured as the Government required. My question is where can I insert this line? In which and where's the files in Apache TomCat 5.5, JDK 8 updated 102. Is it in the same server.xml file as we modified the connector for SSL. Look forward to hearing from your supports. Regards, Mary Pham Information Technology Specialist National Institutes of Health Library Division of Library Services Office of Research Services 10 Center Drive, Room 1L07, MSC 1150 Bethesda, MD 20892-1150 T. 301.496.1506 maryp...@mail.nih.gov<mailto:maryp...@mail.nih.gov> Hello Mary, you are using a quite outdated tomcat. A quick googling brought me to stackoverflow, which might solve the problem for your tomcat 5.5. the easiest way possible is to add a filter to your webapp and apply the HSTS header in the response. You can make use of the buildin HSTS support, if its possible to upgrade your tomcat to a recent version. Related SO-Question: http://stackoverflow.com/questions/27541755/add-hsts-feature-to-tomcat Best regards, Daniel - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Apache TomCat 5.5
Hello EveryOne, As new bee of Apache. We have been using one of the old Apache TomCat on windows server 2008R2, IIS 7. After we purchased and installed the SSL certificate. We need to apply a header directive in Apache "Strict-Transport-Security" so that our web site would be secured as the Government required. My question is where can I insert this line? In which and where's the files in Apache TomCat 5.5, JDK 8 updated 102. Is it in the same server.xml file as we modified the connector for SSL. Look forward to hearing from your supports. Regards, Mary Pham Information Technology Specialist National Institutes of Health Library Division of Library Services Office of Research Services 10 Center Drive, Room 1L07, MSC 1150 Bethesda, MD 20892-1150 T. 301.496.1506 maryp...@mail.nih.gov<mailto:maryp...@mail.nih.gov> Stay connected with the NIH Library NIH Library: http://nihlibrary.nih.gov<http://nihlibrary.nih.gov/> Facebook: http://www.facebook.com/nihlibrary Twitter: http://www.twitter.com/nihlib Mary Pham, BS Information Technology Specialist National Institutes of Health Library Division of Library Services Office of Research Services 10 Center Drive, Room 1L07, MSC 1150 Bethesda, MD 20892-1150 T. 301.496.1506 maryp...@mail.nih.gov Stay connected with the NIH Library NIH Library: http://nihlibrary.nih.gov<http://nihlibrary.nih.gov/> Facebook: http://www.facebook.com/nihlibrary Twitter: http://www.twitter.com/nihlib _
RE: Active Directory User Authentication Apache Tomcat 5.5 Struts Servlets JSP
Date: Tue, 24 Feb 2015 20:45:09 +0100
From: a...@ice-sa.com
To: users@tomcat.apache.org
Subject: Re: Active Directory User Authentication Apache Tomcat 5.5 Struts
Servlets JSP
Seema Patel wrote:
Hi,
We are using Apache Tomcat 5.5, JDK 1.5 and have a internal portal on our
intranet which is written in java jsp struts and jsp.
I know that the tomcat and Java versions are old, but upgrading isn't a
quick thing to do without lots of testing.
The issue we have is that the users keep getting the authentication box
popping up asking for username and password when using the portal in
Internet Explorer.
One of the users has noticed that when they use Chrome, they don't seem to
get this popup constantly. Authentication is against the Active Directory
using JCIFS (I know it's discontinued, but to re-write and test is not
feasible at the moment). The users are meant to be using Internet Explorer
as not everything works in Chrome.
We have been trying to work out this issue for some time, with no success.
The user saying that it works in Chrome makes us wonder if there's
something within Internet Explorer that is possibly dropping the connection
or something for it to keep asking the user for username and password. Or
is there something that Internet Explorer doesn't like with Apache Tomcat?
Any help/guidance on this issue is greatly appreciated.
Hi.
Tomcat 5.5 is old.
The JCIFS http/NTLM authentication filter is old and deprecated and does not
work anymore
in any recent Windows Domain setup, because it only works with NTLM v1.
Please read the first paragraph in blue here :
http://jcifs.samba.org/src/docs/ntlmhttpauth.html
and *believe what it says, it is true*.
(Look at Jespa @ www.ioplex.com for a painless replacement)
(look at a more recent version of Tomcat and the SPNEGO authentication valve
for another
possible replacement)
A login dialog that pops up in the browser when it should not, indicates one
thing for
sure : /something/ is not working in the WIA (Windows Integrated
Authentication).
But what that something is in your case, is impossible to say from outside of
your network.
It is almost certainly not a browser problem.
It may be things like :
- some of the clients are running newer versions of Windows and/or browsers
which will not
accept NTLMv1 authentication anymore
- in your network, there are multiple Domain Controllers, some of which
younger than
others. Some still accept to do NTLMv1 authentication, some do not. As your
clients get
one or the other (quasi randomly) it sometimes works, and sometimes not.
- and a large number of possible other reasons
The one certainty is : you are using obsolete software and solutions, and
nobody will be
able to give you any miracle solution for that. The sooner you accept that,
the less
time you will lose in the end.
Thanks Andre. I think we do use NTLM v2, so that could be why we're getting
the issues.
I have been looking into upgrading, on and off, so not sure if what I have done
is right or not as I've not looked at it in a while.
I do remember looking into Jespa and SPNEGO but I don't think we want to go
down those routes.
I have been looking at and trying to get traditional LDAP authentication, but I
don't know much about this (previous developers have said to use this method
but are no longer available to assist).
I am hoping if you could guide/assist me in knowing if what I have done and am
trying to do is right.
So in my server.xml I now have:
Realm className=org.apache.catalina.realm.LockOutRealm
!-- This Realm uses the UserDatabase configured in the global JNDI
resources under the key UserDatabase. Any edits
that are performed against this UserDatabase are immediately
available for use by the Realm. --
Realm className=org.apache.catalina.realm.UserDatabaseRealm
resourceName=UserDatabase/
Realm className=org.apache.catalina.realm.JNDIRealm
connectionName=xxx@xxx.local
connectionPassword=xxx connectionURL=xxx referrals=follow
roleBase=dc=xxx,dc=local roleName=cn roleSearch=(member={0})
roleSubtree=true userBase=dc=vtlwavenet,dc=local
userSearch=(sAMAccountName={0}) userSubtree=true/
/Realm
I have also removed all JCIFS and NTLM filters etc from my web.xml, I now have:
filter
filter-nameADGroupFilter/filter-name
filter-classcom.xxx.xxx.ADGroupFilter/filter-class
init-param
param-nameAllowedGroups/param-name
param-valuexxx,xxx,xxx/param-value
/init-param
/filter
filter
filter-nameAuth Filter/filter-name
filter-classcom.xxx.xxx.RequestFilter/filter-class
init-param
param-nameLogonPage/param-name
param-valuexxx.do/param-value
/init-param
init-param
Re: Active Directory User Authentication Apache Tomcat 5.5 Struts Servlets JSP
Seema Patel wrote: Hi, We are using Apache Tomcat 5.5, JDK 1.5 and have a internal portal on our intranet which is written in java jsp struts and jsp. I know that the tomcat and Java versions are old, but upgrading isn't a quick thing to do without lots of testing. The issue we have is that the users keep getting the authentication box popping up asking for username and password when using the portal in Internet Explorer. One of the users has noticed that when they use Chrome, they don't seem to get this popup constantly. Authentication is against the Active Directory using JCIFS (I know it's discontinued, but to re-write and test is not feasible at the moment). The users are meant to be using Internet Explorer as not everything works in Chrome. We have been trying to work out this issue for some time, with no success. The user saying that it works in Chrome makes us wonder if there's something within Internet Explorer that is possibly dropping the connection or something for it to keep asking the user for username and password. Or is there something that Internet Explorer doesn't like with Apache Tomcat? Any help/guidance on this issue is greatly appreciated. Hi. Tomcat 5.5 is old. The JCIFS http/NTLM authentication filter is old and deprecated and does not work anymore in any recent Windows Domain setup, because it only works with NTLM v1. Please read the first paragraph in blue here : http://jcifs.samba.org/src/docs/ntlmhttpauth.html and *believe what it says, it is true*. (Look at Jespa @ www.ioplex.com for a painless replacement) (look at a more recent version of Tomcat and the SPNEGO authentication valve for another possible replacement) A login dialog that pops up in the browser when it should not, indicates one thing for sure : /something/ is not working in the WIA (Windows Integrated Authentication). But what that something is in your case, is impossible to say from outside of your network. It is almost certainly not a browser problem. It may be things like : - some of the clients are running newer versions of Windows and/or browsers which will not accept NTLMv1 authentication anymore - in your network, there are multiple Domain Controllers, some of which younger than others. Some still accept to do NTLMv1 authentication, some do not. As your clients get one or the other (quasi randomly) it sometimes works, and sometimes not. - and a large number of possible other reasons The one certainty is : you are using obsolete software and solutions, and nobody will be able to give you any miracle solution for that. The sooner you accept that, the less time you will lose in the end. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Active Directory User Authentication Apache Tomcat 5.5 Struts Servlets JSP
Hi, We are using Apache Tomcat 5.5, JDK 1.5 and have a internal portal on our intranet which is written in java jsp struts and jsp. I know that the tomcat and Java versions are old, but upgrading isn't a quick thing to do without lots of testing. The issue we have is that the users keep getting the authentication box popping up asking for username and password when using the portal in Internet Explorer. One of the users has noticed that when they use Chrome, they don't seem to get this popup constantly. Authentication is against the Active Directory using JCIFS (I know it's discontinued, but to re-write and test is not feasible at the moment). The users are meant to be using Internet Explorer as not everything works in Chrome. We have been trying to work out this issue for some time, with no success. The user saying that it works in Chrome makes us wonder if there's something within Internet Explorer that is possibly dropping the connection or something for it to keep asking the user for username and password. Or is there something that Internet Explorer doesn't like with Apache Tomcat? Any help/guidance on this issue is greatly appreciated. Thanks Seema
Re: Active Directory User Authentication Apache Tomcat 5.5 Struts Servlets JSP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Seema, On 2/24/15 7:59 AM, Seema Patel wrote: We are using Apache Tomcat 5.5, JDK 1.5 and have a internal portal on our intranet which is written in java jsp struts and jsp. I know that the tomcat and Java versions are old, but upgrading isn't a quick thing to do without lots of testing. The issue we have is that the users keep getting the authentication box popping up asking for username and password when using the portal in Internet Explorer. One of the users has noticed that when they use Chrome, they don't seem to get this popup constantly. Authentication is against the Active Directory using JCIFS (I know it's discontinued, but to re-write and test is not feasible at the moment). The users are meant to be using Internet Explorer as not everything works in Chrome. We have been trying to work out this issue for some time, with no success. The user saying that it works in Chrome makes us wonder if there's something within Internet Explorer that is possibly dropping the connection or something for it to keep asking the user for username and password. Or is there something that Internet Explorer doesn't like with Apache Tomcat? So, this was a system working in the past, and now it does not work? Or you have been having problems for years and you are finally investigating it? If something changed recently, what was it? Are your users using a newer version of Internet Explorer (i.e. they finally migrated from MSIE 6 to something more modern)? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJU7JG5AAoJEBzwKT+lPKRYWy4P/1a2xLQEr4PWIpFvZ8+QVc27 CZ4fEJ5TVzCrOE0WqwN4COe/9M5XjvACYbLH1dKaDKXTVc/1R8sZpiQyXDGBZ7De +C5Gs76JibsmYgwECRHwJozrKbm0cZNu1JZLjTBnhHgxAxAXHw99a+EPZBisutSu 3keEL64BYmMRboKW50qVYP2PiYpcqtyCgO2uew8nwca6nPDTt2AXMAC2vd/dgNds IQ8g1RIe8ndPIl0g7YvW7t4oMzm/keMPEvLew5cbs8q47ZnE4mlukC9HtyoDEjcU NW0FvDxktF9kdnLll//xqrPB6PkF4zW+5wENBvgJcQqoZbjaNc5sUf+SOUJj+iH5 5k/klIydaCHnMjmANOwvu0z/doj3wpKVNiS12D5FTlRNzEkrmqwNlvTA2xy5P8Kt LbJwDGhBzAFQBPQGmLCKJeQMOvWn5GzXv/zzAAM1D062yaNH855JPNbUYZo0ZOub FroFiBeNdm5rLRTm4EHbFAMc2VCvpCWlAtUYh/ltTTC7ZN6tYWC8M2erfm2/8tqS /PHcnoXjAB0ADS/Yd1cNwx4//jsDmfeXZIlOPwS63gjs7goRQKbvkIdTBhRKEJYU ghOnI3vALYq7bMMjRUc6xfrfLnqt3DzGayUTTjEw7efTgO6Z436qo4hu8js2TJ6H 6GctCFmQou5ZK6I+693Z =DM3L -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [Bug][Tomcat 5.5.x] Tomcat loses request parameters
Chris, Thank you for your answer. You are right about tomcat itself not being involved. I was fooled by the class ByteChunk belonging to tomcat, and didn't see that the MultipartStream belongs in fact to commons-fileupload.jar. The jbossweb-tomcat55.sar module in jboss 4.0.4.GA does come with commons-fileupload-1.2.jar. I found out that the bug I see was fixed in version 1.2.1 (issue FILEUPLOAD-144 related to issue FILEUPLOAD-135) and verified it solves my problem. Thanks again, Didier DUQUENNOY Didier, On 6/4/14, 11:30 AM, DDU DUQUENNOY Didier wrote: I think I found a problem in the way Tomcat parses the POST Http Request. It might be related to issues n°40860, 31523 and 42347 submitted to bugzilla https://issues.apache.org/bugzilla. I am running on a JBoss 4.0.4 GA server on a windows platform. I know it uses a 5.5.x tomcat, but I don't know exactly which version. Tomcat 5.5.x is no longer supported. We don't support JBoss, here, either. You'll have to get support from Red Hat at this point, or upgrade to a version of Tomcat that is supported. Symptoms : When I submit a POST request, sometimes one parameter get lost. I can tell using Eclipse's TCP/IP proxy that the value was submitted in the request. Without knowing what version of 5.5.x you are using, nobody is going to be able to tell you if a) there is a bug and b) if it was fixed in a version of Tomcat later than the one you are running. I can tell you pretty confidently that Tomcat does not lose request parameters, even old unsupported versions. ;) Analysis: The POST request looks like that and is 15kB long: -7de35e1c190e9e Content-Disposition: form-data; name=autoScroll 0,0 -7de35e1c190e9e Content-Disposition: form-data; name=principal:arbre::focused false -7de35e1c190e9e Content-Disposition: form-data; name=principal:arbre::expandedNodes It's worth pointing-out that Tomcat did not directly handle multipart requests until version 7.0.x. If you are having problems with multipart requests, the problem is likely with either /your/ (of JBoss's) multipart library or your own code. (Oddly, Tomcat does have the package-renamed classes from commons-http-upload available in the Tomcat 6 source...) Using remote debugging, I found that a MultipartStream object analyses the request using a 4KB buffer; this buffer is fed by a 8kB buffer used by a ByteChunk object. The pattern -7de35e1c190e9e is called 'boundary'. and is repeated for each field. I noted that the hex part of the boundary may not be the same length from one POST to another, I think that is why the problem does not always occur. when MultipartStream arrives at the end of its buffer and there is not enough bytes left to read the next boundary, it moves the few unread bytes to the beginning of the buffer, then loads the next chunk of data from the ByteChunk object (see MultipartStream$ItemInputStream.makeAvailable()) That class does not exist in Tomcat prior to Tomcat 6, and in Tomcat 6 does not have the makeAvailable method. In Tomcat 7, makeAvailable appears. I suspect you are using commons-http-upload, and probably a fairly old version. If this ever was a problem with commons-http-upload, I'm sure it's been fixed. In any case, you are going to have to upgrade at least commons-http-upload. I would recommend upgrading just about every component you currently have, as you are likely to be very out of date. Security patches, performance improvements, bug fixes, etc. are all available between your version and the current. - -chris Consultez nos sites internet : http://www.sofaxis.com http://www.sofcap-sofcah.com Sofaxis disclaimer : http://www.sofaxis.com/disclaimer-1.html - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [Bug][Tomcat 5.5.x] Tomcat loses request parameters
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Didier, On 6/5/14, 4:10 AM, DDU DUQUENNOY Didier wrote: Chris, Thank you for your answer. You are right about tomcat itself not being involved. I was fooled by the class ByteChunk belonging to tomcat, and didn't see that the MultipartStream belongs in fact to commons-fileupload.jar. The jbossweb-tomcat55.sar module in jboss 4.0.4.GA does come with commons-fileupload-1.2.jar. I found out that the bug I see was fixed in version 1.2.1 (issue FILEUPLOAD-144 related to issue FILEUPLOAD-135) and verified it solves my problem. Glad to see it was only a point-version that you needed. Kind of a no-brainer :) I'm surprised that JBoss shipped with that broken version of commons-fileupload. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTkIr4AAoJEBzwKT+lPKRY1MgP/iiuu/72Ym/XD4j2K7n38tsK Ykum444vZkgp+XnyTMz3LDK6Y7UyHoxmJW4Yfbc0c6xI42ltrlekDjrnU7l7G+tc IXal7oSGhW8Y1jMg79TVzs/Uta9cz1U+sdSu2X/XuEWkcpJcmEH35ua+D/U4ihdL b1z7npiIHSfRrHPYvpdNxL9u5ohk98Pi1BrfIj96ADvgP4P92XPO090OBoVjTm2O q97Pz7Eer2KOApC7oDP65lnkPNzkmVVSRaminvKcSPQIVD39X7ZMoZs8pXVckm2/ qPlEb57EztI6Y4FL1rW5iQa2QqndyVGlrmKVgAyUGelQI04bDFidDKnZ8ZKXQ9tC 8rC41cr+0Iw58EGzBavwhLv6qQ+nBzviTWUUgyekUCMVhE5+SlryK+s3yZH3T6X7 R6vJSA+wrsFzwZyU3DK4plz0NCAeA5x7e5amuNHpKMwDpyaCwvxgnVxr0KjljEie i/TexZhQno7W5cWH5JhlBvGi8LYCR9aTer255U5bKmGv2EeCyqIu69sY5Ytuyf1k GaIEyTjXjHaUzw8lsA9uji0ge86JiQ3oX0ezwDiJx8donR3U/NGQEpf2ah16KcAw jXEhp2N6IH6u733FbDMS6aQdo1bBa/sg7yMndvBWnwdrTcZr462I8KTR9COTdcZE M8XmQbATZuRnzJplaSc7 =zIfA -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[Bug][Tomcat 5.5.x] Tomcat loses request parameters
RequestParameterMap.getAttribute(String) line: 42 Can anybody tell me if this is a known problem? Maybe it has been solved some other way. I know Tomcat 5.5 if rather old... Thanks, Didier DUQUENNOY Consultez nos sites internet : http://www.sofaxis.com http://www.sofcap-sofcah.com Sofaxis disclaimer : http://www.sofaxis.com/disclaimer-1.html - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [Bug][Tomcat 5.5.x] Tomcat loses request parameters
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Didier, On 6/4/14, 11:30 AM, DDU DUQUENNOY Didier wrote: I think I found a problem in the way Tomcat parses the POST Http Request. It might be related to issues n°40860, 31523 and 42347 submitted to bugzilla https://issues.apache.org/bugzilla. I am running on a JBoss 4.0.4 GA server on a windows platform. I know it uses a 5.5.x tomcat, but I don't know exactly which version. Tomcat 5.5.x is no longer supported. We don't support JBoss, here, either. You'll have to get support from Red Hat at this point, or upgrade to a version of Tomcat that is supported. Symptoms : When I submit a POST request, sometimes one parameter get lost. I can tell using Eclipse's TCP/IP proxy that the value was submitted in the request. Without knowing what version of 5.5.x you are using, nobody is going to be able to tell you if a) there is a bug and b) if it was fixed in a version of Tomcat later than the one you are running. I can tell you pretty confidently that Tomcat does not lose request parameters, even old unsupported versions. ;) Analysis: The POST request looks like that and is 15kB long: -7de35e1c190e9e Content-Disposition: form-data; name=autoScroll 0,0 -7de35e1c190e9e Content-Disposition: form-data; name=principal:arbre::focused false -7de35e1c190e9e Content-Disposition: form-data; name=principal:arbre::expandedNodes It's worth pointing-out that Tomcat did not directly handle multipart requests until version 7.0.x. If you are having problems with multipart requests, the problem is likely with either /your/ (of JBoss's) multipart library or your own code. (Oddly, Tomcat does have the package-renamed classes from commons-http-upload available in the Tomcat 6 source...) Using remote debugging, I found that a MultipartStream object analyses the request using a 4KB buffer; this buffer is fed by a 8kB buffer used by a ByteChunk object. The pattern -7de35e1c190e9e is called 'boundary'. and is repeated for each field. I noted that the hex part of the boundary may not be the same length from one POST to another, I think that is why the problem does not always occur. when MultipartStream arrives at the end of its buffer and there is not enough bytes left to read the next boundary, it moves the few unread bytes to the beginning of the buffer, then loads the next chunk of data from the ByteChunk object (see MultipartStream$ItemInputStream.makeAvailable()) That class does not exist in Tomcat prior to Tomcat 6, and in Tomcat 6 does not have the makeAvailable method. In Tomcat 7, makeAvailable appears. I suspect you are using commons-http-upload, and probably a fairly old version. If this ever was a problem with commons-http-upload, I'm sure it's been fixed. In any case, you are going to have to upgrade at least commons-http-upload. I would recommend upgrading just about every component you currently have, as you are likely to be very out of date. Security patches, performance improvements, bug fixes, etc. are all available between your version and the current. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTj7StAAoJEBzwKT+lPKRYrmQP/iDgbuW2j0UxCn6IM2Skra4z PUIj1O4tBMz4Q668sjxboJHpMHYDPsW8uUtChIFH2UbyxQ8yonqjhugybPE3jBf3 jwmw+tk+x8FbW+tiGeQl/KxPdvgo5l7i51Hb7/SA8Wzhu82gGm9J3zjo5g7FhMje 8H8T9qMpSijUJO1QLfnNiGuXeLlDVOAL35lTihW+rTiuFjn+hy/rqwM01lGMyw0n hrh8d9ZHFZGorDBoIFnPc+Jbo+qhI+wZB/tgPgYFQrk1MTBgmvbiJ0Zd4wmV7mGj fOMCQF3Xbf8iJvkQBVq8C+17Yr/AHFH96t6zDCWfPLdwWIUtRVOA86EYvmxqd4cb lWBdPvf5o3+MCYHp4nX/JSMgD7oAKwZYsi0rTSj9MadWUHSgkZT31zD8VCQET5WQ M7BuAI8P3rsMvopCEF+eLLgjc5wOvqoW/egrldkenxeNA1EN7g8mqiFWIkDXcoh4 +mNciaag3fk0XmkmLfl9MGrGc+/81aQBoa2R1ge0QIZFGEhUnrLrVESCPwyZGfvB Wwpdy86KUTIJD1nwW5v4ghmDhVdYs3r3NYbcBsGv927UXSnsaFsoWpAzz7xYJNn7 JUG23HcPgG7Ff8jO1osE9AjLyua9hJKgxVM9vzwj1ctCS1TlZ4EAlEoufnJY5OOF 7AEjGq+cRV57F04cdGw2 =vxm6 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 5.5 vs 7.0 SSL
Hi.
Faced with very odd behavior of Tomcat 7...
Have two instances on same box - Tomcat 5.5 and Tomcat 7.
Both have same configuration - first from 5.5:
Connector port=${port.https} maxHttpHeaderSize=8192
maxThreads=150 minSpareThreads=25 maxSpareThreads=75
enableLookups=false disableUploadTimeout=true
acceptCount=100 scheme=https secure=true
clientAuth=want sslProtocol=TLS
keystoreFile=conf/.ssl/tomcat.jks
keyAlias=tomcat
keystorePass=pass
truststoreFile=conf/.ssl/trustcacerts.jks
truststorePass=pass /
Next - from 7.0:
Connector
port=${port.https}
protocol=HTTP/1.1
SSLEnabled=true
enableLookups=false
disableUploadTimeout=true
scheme=https
secure=true
clientAuth=want
sslProtocol=TLS
keystoreFile=conf/.ssl/tomcat.jks
keyAlias=tomcat
keystorePass=pass
truststoreFile=conf/.ssl/trustcacerts.jks
truststorePass=pass
/
Also - both configured for CLIENT-CERT authentification (same applicaion
with same web.xml).
In browser installed cert, but - when I'm trying open connection to 7
Tomcat - I got 401 - Cannot authenticate with the provided credentials and
no authentification attempt in log:
10.***.***.15 - - [02/Jun/2014:17:10:31 +0300] GET /service/ HTTP/1.1 401
1049
But connection to 5.5 - succsessfull with same browser certificate.
Also, in ssldump I see that browser can't make handshake with 7.0 server:
1 2 0.0317 (0.0308) SC Handshake
ServerHello
Version 3.1
session_id[32]=
53 8c 85 d7 cf 17 a1 45 8a 4e 64 e6 95 7f 2b f3
cb 74 0a f3 13 40 71 e8 74 50 53 1a 00 24 a0 76
cipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA
compressionMethod NULL
Certificate
ServerKeyExchange
CertificateRequest
certificate_types rsa_sign
certificate_types dss_sign
certificate_authority
30 62 31 0b 30 09 06 03 55 04 06 13 02 55 41 31
10 30 0e 06 03 55 04 08 13 07 55 6e 6b 6e 6f 77
6e 31 0d 30 0b 06 03 55 04 07 13 04 4b 69 65 76
31 0f 30 0d 06 03 55 04 0a 13 06 4c 75 78 6f 66
74 31 0c 30 0a 06 03 55 04 0b 13 03 4c 4d 53 31
13 30 11 06 03 55 04 03 13 0a 61 7a 69 6e 63 68
65 6e 6b 6f
certificate_authority
30 60 31 0b 30 09 06 03 55 04 06 13 02 55 41 31
// and that's all
But on 5.5 - everyting OK:
1 2 0.0213 (0.0195) SC Handshake
ServerHello
Version 3.1
session_id[32]=
53 8c 85 89 be 1f c5 63 e2 16 a0 a0 dc 5b aa 68
0d 1c 8d b7 24 c5 13 0a 24 0a 66 9b 54 f4 b0 0f
cipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA
compressionMethod NULL
Certificate
ServerKeyExchange
ServerHelloDone
1 3 0.0256 (0.0042) CS Handshake
ClientKeyExchange
DiffieHellmanClientPublicValue[96]=
4a 39 5e f5 2a c1 58 13 6b 7c 98 0b 44 d7 9a 42
bf 48 c2 6e a4 c6 6d 50 a7 89 8f 53 a4 54 92 a5
81 18 1b 22 63 cf c1 63 8f 36 9f d2 59 c3 3e 67
1f 4e 18 01 db f2 9d 07 0b 81 12 39 64 62 83 84
78 dc 36 9b 00 34 f5 34 44 2d 92 eb d9 f6 b0 7e
c4 66 d9 ad f2 bf 7f fb 07 56 eb 58 5d 58 41 2e
What I'm doing wrong?
Thanks.
Re: Tomcat 5.5 vs 7.0 SSL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Арсений,
On 6/2/14, 10:24 AM, Арсений Зинченко wrote:
Hi.
Faced with very odd behavior of Tomcat 7...
Have two instances on same box - Tomcat 5.5 and Tomcat 7.
Both have same configuration - first from 5.5:
Connector port=${port.https} maxHttpHeaderSize=8192
maxThreads=150 minSpareThreads=25 maxSpareThreads=75
enableLookups=false disableUploadTimeout=true acceptCount=100
scheme=https secure=true clientAuth=want sslProtocol=TLS
keystoreFile=conf/.ssl/tomcat.jks keyAlias=tomcat
keystorePass=pass truststoreFile=conf/.ssl/trustcacerts.jks
truststorePass=pass /
Next - from 7.0:
Connector port=${port.https} protocol=HTTP/1.1
SSLEnabled=true enableLookups=false
disableUploadTimeout=true scheme=https secure=true
clientAuth=want sslProtocol=TLS
keystoreFile=conf/.ssl/tomcat.jks keyAlias=tomcat
keystorePass=pass truststoreFile=conf/.ssl/trustcacerts.jks
truststorePass=pass /
Also - both configured for CLIENT-CERT authentification (same
applicaion with same web.xml).
In browser installed cert, but - when I'm trying open connection
to 7 Tomcat - I got 401 - Cannot authenticate with the provided
credentials and no authentification attempt in log:
10.***.***.15 - - [02/Jun/2014:17:10:31 +0300] GET /service/
HTTP/1.1 401 1049
But connection to 5.5 - succsessfull with same browser
certificate.
Also, in ssldump I see that browser can't make handshake with 7.0
server:
1 2 0.0317 (0.0308) SC Handshake ServerHello Version 3.1
session_id[32]= 53 8c 85 d7 cf 17 a1 45 8a 4e 64 e6 95 7f 2b f3 cb
74 0a f3 13 40 71 e8 74 50 53 1a 00 24 a0 76 cipherSuite
TLS_DHE_DSS_WITH_AES_128_CBC_SHA compressionMethod
NULL Certificate ServerKeyExchange CertificateRequest
certificate_types rsa_sign certificate_types
dss_sign certificate_authority 30 62 31 0b 30 09 06 03 55 04 06 13
02 55 41 31 10 30 0e 06 03 55 04 08 13 07 55 6e 6b 6e 6f 77 6e 31
0d 30 0b 06 03 55 04 07 13 04 4b 69 65 76 31 0f 30 0d 06 03 55 04
0a 13 06 4c 75 78 6f 66 74 31 0c 30 0a 06 03 55 04 0b 13 03 4c 4d
53 31 13 30 11 06 03 55 04 03 13 0a 61 7a 69 6e 63 68 65 6e 6b 6f
certificate_authority 30 60 31 0b 30 09 06 03 55 04 06 13 02 55 41
31 // and that's all
But on 5.5 - everyting OK:
1 2 0.0213 (0.0195) SC Handshake ServerHello Version 3.1
session_id[32]= 53 8c 85 89 be 1f c5 63 e2 16 a0 a0 dc 5b aa 68 0d
1c 8d b7 24 c5 13 0a 24 0a 66 9b 54 f4 b0 0f cipherSuite
TLS_DHE_DSS_WITH_AES_128_CBC_SHA compressionMethod
NULL Certificate ServerKeyExchange ServerHelloDone 1 3 0.0256
(0.0042) CS Handshake ClientKeyExchange
DiffieHellmanClientPublicValue[96]= 4a 39 5e f5 2a c1 58 13 6b 7c
98 0b 44 d7 9a 42 bf 48 c2 6e a4 c6 6d 50 a7 89 8f 53 a4 54 92 a5
81 18 1b 22 63 cf c1 63 8f 36 9f d2 59 c3 3e 67 1f 4e 18 01 db f2
9d 07 0b 81 12 39 64 62 83 84 78 dc 36 9b 00 34 f5 34 44 2d 92 eb
d9 f6 b0 7e c4 66 d9 ad f2 bf 7f fb 07 56 eb 58 5d 58 41 2e
What I'm doing wrong?
Anything in the catalina.out or other log files in logs/* ?
Are both Tomcats running on the same server?
In the Tomcat 7 case, does ssldump tell you whether the SC has hung?
Can you tell if the TCP message is incomplete? Can you get a thread
dump on the Tomcat 7 side?
The configuration itself looks okay to me.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJTjKygAAoJEBzwKT+lPKRYVJEQAKlVEFFwEyfyYFML/aArNHqb
00qGyoyzu7+mLNlZlMvP4wvuXivK13Sxy+NNJ/TqkijZ4ZlaSTx82vUBHt2HNX9J
Rsq5lTL1FRHNDzHABoXwkDLj64xhJ41iBFUcdsGENJ9K9mpFtPXi3wSRsQK4eguv
ynRr+f3pJwWsiPlXxWiGICV55mKGsUvSwjKzXhG6RYMpUmHeT1V7SOyOfPA73Jks
GGPaDsc0tNT9K6c8NGX+c5+u0h5Af5UQn10Rcpp/22QSzfIDwq4kv1MPZ9I+TTQa
l/S/L6VfVtbacUuvVMsnN15eIEQDfTVA9RoKjacG0rsrB+oqoSG0UDjFhuP8LXHx
huvhim7CJcZyaNR3Ydp8Q+NFz5ON4w6tlP/APA48x6HUgAJq3DoSlFbrbJGu4HVV
NgziXOdlwz7KD7yVdUckrbCsLVCFrxkBENtOUdQ5a6dp1bjPBfOcxrtPcEduvLUR
mdNsoXQA8pOFBLHwIJSONBn7lSXQPBR+XCkxGJDqYzdmaykoz2OrB7aA4DqtYXCD
iwA0bvwFCOOzq/DiNlLgqscQz9+sAbT7ROjCvkKpDfjJYBi7S26eNx9Gg1S39scX
uAlDoRe96CQDmcitZ8Oqrn5ErKReTpbhGULn0YnHB1uL9Vxd5M8EkAI0whTQMQ5u
qYcRj4u7cd24Okq8KQUd
=zoKs
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 5.5 vs 7.0 SSL
02.06.2014 19:56, Christopher Schultz пишет:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Арсений,
On 6/2/14, 10:24 AM, Арсений Зинченко wrote:
Hi.
Faced with very odd behavior of Tomcat 7...
Have two instances on same box - Tomcat 5.5 and Tomcat 7.
Both have same configuration - first from 5.5:
Connector port=${port.https} maxHttpHeaderSize=8192
maxThreads=150 minSpareThreads=25 maxSpareThreads=75
enableLookups=false disableUploadTimeout=true acceptCount=100
scheme=https secure=true clientAuth=want sslProtocol=TLS
keystoreFile=conf/.ssl/tomcat.jks keyAlias=tomcat
keystorePass=pass truststoreFile=conf/.ssl/trustcacerts.jks
truststorePass=pass /
Next - from 7.0:
Connector port=${port.https} protocol=HTTP/1.1
SSLEnabled=true enableLookups=false
disableUploadTimeout=true scheme=https secure=true
clientAuth=want sslProtocol=TLS
keystoreFile=conf/.ssl/tomcat.jks keyAlias=tomcat
keystorePass=pass truststoreFile=conf/.ssl/trustcacerts.jks
truststorePass=pass /
Also - both configured for CLIENT-CERT authentification (same
applicaion with same web.xml).
In browser installed cert, but - when I'm trying open connection
to 7 Tomcat - I got 401 - Cannot authenticate with the provided
credentials and no authentification attempt in log:
10.***.***.15 - - [02/Jun/2014:17:10:31 +0300] GET /service/
HTTP/1.1 401 1049
But connection to 5.5 - succsessfull with same browser
certificate.
Also, in ssldump I see that browser can't make handshake with 7.0
server:
1 2 0.0317 (0.0308) SC Handshake ServerHello Version 3.1
session_id[32]= 53 8c 85 d7 cf 17 a1 45 8a 4e 64 e6 95 7f 2b f3 cb
74 0a f3 13 40 71 e8 74 50 53 1a 00 24 a0 76 cipherSuite
TLS_DHE_DSS_WITH_AES_128_CBC_SHA compressionMethod
NULL Certificate ServerKeyExchange CertificateRequest
certificate_types rsa_sign certificate_types
dss_sign certificate_authority 30 62 31 0b 30 09 06 03 55 04 06 13
02 55 41 31 10 30 0e 06 03 55 04 08 13 07 55 6e 6b 6e 6f 77 6e 31
0d 30 0b 06 03 55 04 07 13 04 4b 69 65 76 31 0f 30 0d 06 03 55 04
0a 13 06 4c 75 78 6f 66 74 31 0c 30 0a 06 03 55 04 0b 13 03 4c 4d
53 31 13 30 11 06 03 55 04 03 13 0a 61 7a 69 6e 63 68 65 6e 6b 6f
certificate_authority 30 60 31 0b 30 09 06 03 55 04 06 13 02 55 41
31 // and that's all
But on 5.5 - everyting OK:
1 2 0.0213 (0.0195) SC Handshake ServerHello Version 3.1
session_id[32]= 53 8c 85 89 be 1f c5 63 e2 16 a0 a0 dc 5b aa 68 0d
1c 8d b7 24 c5 13 0a 24 0a 66 9b 54 f4 b0 0f cipherSuite
TLS_DHE_DSS_WITH_AES_128_CBC_SHA compressionMethod
NULL Certificate ServerKeyExchange ServerHelloDone 1 3 0.0256
(0.0042) CS Handshake ClientKeyExchange
DiffieHellmanClientPublicValue[96]= 4a 39 5e f5 2a c1 58 13 6b 7c
98 0b 44 d7 9a 42 bf 48 c2 6e a4 c6 6d 50 a7 89 8f 53 a4 54 92 a5
81 18 1b 22 63 cf c1 63 8f 36 9f d2 59 c3 3e 67 1f 4e 18 01 db f2
9d 07 0b 81 12 39 64 62 83 84 78 dc 36 9b 00 34 f5 34 44 2d 92 eb
d9 f6 b0 7e c4 66 d9 ad f2 bf 7f fb 07 56 eb 58 5d 58 41 2e
What I'm doing wrong?
Anything in the catalina.out or other log files in logs/* ?
Are both Tomcats running on the same server?
In the Tomcat 7 case, does ssldump tell you whether the SC has hung?
Can you tell if the TCP message is incomplete? Can you get a thread
dump on the Tomcat 7 side?
The configuration itself looks okay to me.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJTjKygAAoJEBzwKT+lPKRYVJEQAKlVEFFwEyfyYFML/aArNHqb
00qGyoyzu7+mLNlZlMvP4wvuXivK13Sxy+NNJ/TqkijZ4ZlaSTx82vUBHt2HNX9J
Rsq5lTL1FRHNDzHABoXwkDLj64xhJ41iBFUcdsGENJ9K9mpFtPXi3wSRsQK4eguv
ynRr+f3pJwWsiPlXxWiGICV55mKGsUvSwjKzXhG6RYMpUmHeT1V7SOyOfPA73Jks
GGPaDsc0tNT9K6c8NGX+c5+u0h5Af5UQn10Rcpp/22QSzfIDwq4kv1MPZ9I+TTQa
l/S/L6VfVtbacUuvVMsnN15eIEQDfTVA9RoKjacG0rsrB+oqoSG0UDjFhuP8LXHx
huvhim7CJcZyaNR3Ydp8Q+NFz5ON4w6tlP/APA48x6HUgAJq3DoSlFbrbJGu4HVV
NgziXOdlwz7KD7yVdUckrbCsLVCFrxkBENtOUdQ5a6dp1bjPBfOcxrtPcEduvLUR
mdNsoXQA8pOFBLHwIJSONBn7lSXQPBR+XCkxGJDqYzdmaykoz2OrB7aA4DqtYXCD
iwA0bvwFCOOzq/DiNlLgqscQz9+sAbT7ROjCvkKpDfjJYBi7S26eNx9Gg1S39scX
uAlDoRe96CQDmcitZ8Oqrn5ErKReTpbhGULn0YnHB1uL9Vxd5M8EkAI0whTQMQ5u
qYcRj4u7cd24Okq8KQUd
=zoKs
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Hi, Chris.
Thanks for replay and sorry spending your time - there was my error in
server.xml - include ojdbc Realm in wrong place (our from Host element).
I think so... Because I made a lot of experiments today trying fix it...
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
NoClassDefErrors found in Tomcat 5.5
Dear friends, In a set up, where we have Tomcat 5.5 running on Java 1.6, I have been seeing NoClassDefErrors thrown for a set of classes. I am not too sure as to why these exceptions occur? And this particular error happens at times, and when it happens, Tomcat will not respond.The packaged jar files are found in the CLASSPATH. I am suspecting about Garbage Collection and as JVM might have unloaded some of these classes. But, I am not too very sure at the moment. Is there anything in Tomcat's Classloading mechanism that can provide a clue? Any help, providing direction, to attack this issue, is deeply appreciated. Regards, Thulasiram Sent from my iPhone - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: NoClassDefErrors found in Tomcat 5.5
Thulasiram, 1. Tomcat 5.5.x (what is your x?) is no longer supported 2. Java 1.6 is no longer supported unless you have a contract 3. CLASSPATH is almost never the place to put web dependencies Steps to address the issue: 1. Move to the latest Tomcat 6 or Tomcat 7 (preferably 7) 2. Move to the latest JRE (1.7.0_40) 3. Remove extra stuff from your CLASSPATH 4. For your application dependencies a. put all classes in WEB-INF/classes b. put all libs in WEB-INF/lib c. Container-managed resources go in CATALINA_BASE/lib Most people writing about issues with classpath are using Eclipse. Are you trying to run this from Eclipse? If so, follow the above, and do the following: 1. Use the latest (or next to latest) J2EE version of Eclipse 2. Use either Eclipse's project structure or Maven a. If you're using Maven i. Use the latest Eclipse ii. I like JBoss Tools plugin as well iii. Maven takes care of dependencies for you b. If you're using the standard Eclipse environment i. extra libs go in WebContent/WEB-INF/lib ii. extra classes go in WebContent/WEB-INF/classes iii. Eclipse adds these to the build path for you iv. Eclipse places compiled sources in classes 3. Add the Tomcat server to a Servers project (follow the wizard) just my two cents . . . /mde/ On 9/29/2013 9:38 AM, Thulasiram Gopalakrishna wrote: Dear friends, In a set up, where we have Tomcat 5.5 running on Java 1.6, I have been seeing NoClassDefErrors thrown for a set of classes. I am not too sure as to why these exceptions occur? And this particular error happens at times, and when it happens, Tomcat will not respond.The packaged jar files are found in the CLASSPATH. I am suspecting about Garbage Collection and as JVM might have unloaded some of these classes. But, I am not too very sure at the moment. Is there anything in Tomcat's Classloading mechanism that can provide a clue? Any help, providing direction, to attack this issue, is deeply appreciated. Regards, Thulasiram - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Invalid Jar Index : Java 6/tomcat 5.5/linux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Sabari, On 9/16/13 9:36 AM, Sabari Gandhi wrote: I am sending this error again with more details: I am currently using Java 6 and tomcat 5.5 and my environment is linux. You are about to hear this from every reply: upgrade. Tomcat 5.5 is no longer supported. I am unaware of any critical security issues in Tomcat 5.5.latest, but if any are identified, they will not be fixed. You should upgrade as soon as possible to Tomcat 7.0. Most webapps should have no trouble running with the new version of Tomcat, as the servlet spec is supposed to be (mostly) backward-compatible. Newer versions of Tomcat are more strict with a lot of spec concepts, though, so you may have to make some modifications in order to upgrade. But you really need to do it ASAP. I see an mysterious exception when I try to access a simple jsp page after tomcat is started. *When I added a new maven project (which in turn will create a new jar) I see the exception when i am trying to access an simple index.jsp. When I name the project and jar as mhs-beacon-agent I see the following error and when the project is renamed as mhs-sample-agent I don't see this error*. [...] sun.misc.InvalidJarIndexException: Invalid index sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:931) sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:840) sun.misc.URLClassPath$JarLoader.findResource(URLClassPath.java:810) sun.misc.URLClassPath.findResource(URLClassPath.java:176) Looks like a damaged JAR file. What happens if you try this from the command-line: $ jar tf /path/to/file.jar We also set up remote debugging in linux and see the exception is happening when it is trying to look up for javax/servlet , since sun.misc.URLClassPath is suns own proprietary code i am not able to debug the code. When I extracted two jar file and did an folder / folder comparison I don't see any differences in index.list file or manifest.mf apart from the name differences. I am seeing this exception only in linux environment and not on mac (which is my developer environment)Any help is greatly appreciated. How are you transferring the JAR file from your Mac to Linux? Possibly a newline-mangling during FTP? (I'm reaching, here). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSNxJxAAoJEBzwKT+lPKRYuMAQAJmjgNGGlwl4b83vk6MdUCXe uDFVBQqo9BAj2MDXV8o7FxmCm35xDDlHcDkV5fpg5jAvHscaMf409NjNXZBIE3om IVbere8KTlSu0VekjhJ35O/guto/B/j/gOu/g6iL3ARPfo9tAnIAGAAWlB+Up+cr 62+7bBbUB67VR8GiOxwboD5J27LSCt5mq8t3N9HfKb264HBpdb9ssYeopGQXD5p7 zAijNYULjL3Dp7I0hnH+RFWXID6OC7OuE02iYwmUy6sbPU6vnMWDTKa1fRTLXsPd lnvto3a91e3RvdVC8PczXsS3qfvWokANZOaDU93qqV1IJEfGW5ZTBSuAGcR/scWu 0+3wB/ocdtN4NbNGSO9v39f5NkJxGUpDIhucW4Eq+NMUJabNCTp1mwz/iUf3h1O1 XnEEwwqSxUGb2xdECfjXeFO9hdaY59TONbr5FKmO5iWniBPYAZNYYiSQnN9DnPRM 1t7ob34uQRYloV5+FR8X0oSwwvKhTEPgxrDx/LJDOFx4NhuFVY4i1g8iuPvhqK/3 pq3wgExD9cMDIa2MaJqnNV9pi395Mnlkj7gEgi+jtGhgSJ6A6WvfZxQryA0zyLO4 tcZwO/Potpq+oOJvehwMD8kAN1v73FC10pWM1gSm6bpMzwF3wXr9jSPJDxRPUiHH 0fXuVGWFjwn1JXgnRJ8Y =mwfN -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Invalid Jar Index : Java 6/tomcat 5.5/linux
On Sep 16, 2013, at 9:36 AM, Sabari Gandhi sgan...@kivasystems.com wrote: Hi, I am sending this error again with more details: I am currently using Java 6 and tomcat 5.5 Don't use Tomcat 5.5. It has not been supported for almost a year now. Upgrade ASAP. and my environment is linux. I see an mysterious exception when I try to access a simple jsp page after tomcat is started. When I added a new maven project (which in turn will create a new jar) I see the exception when i am trying to access an simple index.jsp. When I name the project and jar as mhs-beacon-agent I see the following error and when the project is renamed as mhs-sample-agent I don't see this error. We also set up remote debugging in linux and see the exception is happening when it is trying to look up for javax/servlet , since sun.misc.URLClassPath is suns own proprietary code i am not able to debug the code. When I extracted two jar file and did an folder / folder comparison I don't see any differences in index.list file or manifest.mf apart from the name differences. I am seeing this exception only in linux environment and not on mac (which is my developer environment)Any help is greatly appreciated. Thanks !! Exception: sun.misc.InvalidJarIndexException: Invalid index Sounds like your JAR might be corrupted. If this is a custom JAR, rebuild it. If it's a dependency you've downloaded with Maven, you might try clearing out the folders for the problem JAR(s) under ~/.m2/repository and rebuilding. If a JAR downloaded by Maven is corrupted, the corrupted file it will sit on your local HD forever and cause problems. Manually deleting the Maven folders for the JAR usually clears up the problem. Other thought. Upgrade your JVM. If it's as old as your Tomcat version, you could be simply hitting a bug. Dan sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:931) sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:840) sun.misc.URLClassPath$JarLoader.findResource(URLClassPath.java:810) sun.misc.URLClassPath.findResource(URLClassPath.java:176) java.net.URLClassLoader$2.run(URLClassLoader.java:551) java.net.URLClassLoader$2.run(URLClassLoader.java:549) java.security.AccessController.doPrivileged(Native Method) java.net.URLClassLoader.findResource(URLClassLoader.java:548) java.lang.ClassLoader.getResource(ClassLoader.java:1139) java.net.URLClassLoader.getResourceAsStream(URLClassLoader.java:227) org.apache.catalina.loader.WebappClassLoader.getResourceAsStream(WebappClassLoader.java:1177) org.apache.jasper.servlet.JasperLoader.getResourceAsStream(JasperLoader.java:144) org.apache.jasper.compiler.JDTCompiler$1.findType(JDTCompiler.java:194) org.apache.jasper.compiler.JDTCompiler$1.findType(JDTCompiler.java:179) org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:119) org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:178) org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:407) org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.checkAndSetImports(CompilationUnitScope.java:167) org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.completeTypeBindings(LookupEnvironment.java:190) org.eclipse.jdt.internal.compiler.Compiler.beginToCompile(Compiler.java:301) org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:315) org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:425) org.apache.jasper.compiler.Compiler.compile(Compiler.java:298) org.apache.jasper.compiler.Compiler.compile(Compiler.java:277) org.apache.jasper.compiler.Compiler.compile(Compiler.java:265) org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:564) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:299) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:315) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:265) javax.servlet.http.HttpServlet.service(HttpServlet.java:806) org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch(ServletExternalContextImpl.java:415) org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:234) org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:300) javax.faces.webapp.FacesServlet.service(FacesServlet.java:95) org.apache.myfaces.component.html.util.ExtensionsFilter.doFilter(ExtensionsFilter.java:122) Code: For complete code see the following URL. http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/sun/misc/URLClassPath.java#URLClassPath.JarLoader.validIndex%28java.lang.String%29 /* Note that the addition of the url to the list of visited 850 * jars incorporates a check for presence in the hashmap 851 */ 852boolean
Re: Java 7 support on Tomcat 5.5
On Apr 1, 2013, at 3:44 PM, Satheesh Babu wrote: Good Evening! We're running our production applications in Tomcat 5.5/JRE 1.5, and there is a need for us to migrate our applications to Java 7(JRE 1.7). There is no information available either on java or on Apace Tomcat site regrading the compatibility of java 7 with tomcat 5.5. Could you please let me know the compatibility of Java 7/Tomcat 5.5 (or) do we need to upgrade tomcat to 6 (or) 7, for java 7. I truly appreciate your response, thanks for your timely help. Thanks, Satheesh Babu First, this is the wrong list for such a question. This question belongs on the User's list. I am cross-posting on both lists this one time to inform you of this and to relocate the topic. Second, good to hear that your organization is making the jump to Java 7. Java 6 is no longer supported and Java 8 will be out soon. Third, upgrade Tomcat. Tomcat 5.5 is extremely old and no longer supported. That's why you won't even find it on the Tomcat site proper [1] anymore, you can only find it in the archives. You will likely not find anyone on these lists willing to help you much with 5.5. Finally, Tomcat 6 and 7 will both run quite fine on Java 7, but they will not compile on Java 7. If you want a version of Tomcat that compiles on Java 7, you will need to wait for Tomcat 8, which is currently in development and should (hopefully) be out later this year. [1] http://tomcat.apache.org/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [ANN] End of life for Apache Tomcat 5.5.x
On 10/08/2011 13:00, Mark Thomas wrote: The Apache Tomcat team announces that support for Apache Tomcat 5.5.x will end on 30 September 2012. This means that after 30 September 2012: - releases from the 5.5.x branch are highly unlikely - bugs affecting only the 5.5.x branch will not be addressed - security vulnerability reports will not be checked against the 5.5.x branch Three months later (i.e. after 31 December 2012) - the 5.5.x download pages will be removed - the latest 5.5.x release will be removed from the mirror system - the 5.5.x branch in svn will move from /tomcat/tc5.5.x to /tomcat/archive/tc5.5.x - the links to the 5.5.x documentation will be removed from tomcat.apache.org - The bugzilla project for 5.5.x will be made read-only This has all been completed. Note that all 5.5.x releases will always be available from the archive. It is anticipated that the final 5.5.x release will be made shortly before 30 September 2012. The final release was 5.5.36 on 10 Oct 2012 and is, and will always remain, available from the archives. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 5.5 context.xml question.
Wow, has it really been that long since I've asked questions here? On to the meat and potatoes... I have a tomcat 5.5.23 installation here that I am trying to do some changes too and I am a bit lost.. Let me try to explain what I want to do. The application has both a context defined in the server.xml and in the context.xml file in the META-INF directory. I've currently removed the context in the server.xml and moved it into it's own context.xml file. I have removed all context references in the server.xml so it looks like this now minus the server name for obvious reasons: Server port=8005 shutdown=SHUTDOWN debug=0 Listener className=org.apache.catalina.mbeans.ServerLifecycleListener debug=0/ Listener className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener debug=0/ GlobalNamingResources Environment name=simpleValue type=java.lang.Integer value=30/ /GlobalNamingResources Service name=Catalina Connector port=8009 enableLookups=false redirectPort=8443 debug=0 protocol=AJP/1.3 / Connector port=8080 maxHttpHeaderSize=8192 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false redirectPort=8443 acceptCount=100 connectionTimeout=2 disableUploadTimeout=true / Engine name=Catalina defaultHost=server.com debug=0 Host name=server.com debug=0 appBase=webapps deployOnStartup=true unpackWARs=true autoDeploy=true xmlValidation=false xmlNamespaceAware=false / /Engine /Service /Server It's pretty simple and elegant. Not hard to follow. So in my project, I've created a META-INF/context.xml file with the following declaration: Context Realm className=org.apache.catalina.realm.JDBCRealm debug=99 driverName=com.mysql.jdbc.Driver connectionURL=jdbc:mysql://dbreader/.. connectionName=emr_jsp connectionPassword=. userTable=TomcatUsers userNameCol=UserID userCredCol=Password userRoleTable=TomcatUserRoles roleNameCol=RoleID digest=MD5/ Manager className=org.apache.catalina.session.PersistentManager saveOnRestart=true distributable=true Store className=org.apache.catalina.session.FileStore directory=/tmp/tc_sessions// /Manager /Context again, not hard to follow. this project is packaged up in the WebEMR.war and resides under the $CATALINA_HOME/webapps/billing-1.0.4 directory I have deleted everything under the $CATALINA_HOME/work directory and also the $CATALINA_HOME/conf/[Engine] directory. The war successfully builds, and I had it deploys with the server.xml configuration below, when the contexts are defined within it. According to the docs, your supposed to remove the path= and docBase= attributes from the new context declaration within the context.xml file, so I have done that. When I start up tomcat, nothing outputs to catalina.out, so I attached log4j to the server and I get this little gem of a message: DEBUG ContainerBackgroundProcessor[StandardEngine[Catalina]] org.apache.catalina.startup.HostConfig - Checking context[/billing-1.0.4] redeploy resource /opt/tomcat/webapps/billing-1.0.4/META-INF/context.xml. There's something missing there it appears that the WebEMR.war is not being deployed and it is looking for the files at the billing-1.0.4 directory. I've got to be missing something, but for the life of me I cannot figure out what it is. Can someone give me some insight please? This is the working server.xml file. With this one, the WebEMR.war is sitting in $CATALINA_HOME/webapps/billing-1.0.4/. It deploys out to $CATALINA_HOME/webapps/1.0.4 Server port=8005 shutdown=SHUTDOWN debug=0 Listener className=org.apache.catalina.mbeans.ServerLifecycleListener debug=0/ Listener className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener debug=0/ GlobalNamingResources Environment name=simpleValue type=java.lang.Integer value=30/ /GlobalNamingResources Service name=Catalina Connector port=8009 enableLookups=false redirectPort=8443 debug=0 protocol=AJP/1.3 / Connector port=8080 maxHttpHeaderSize=8192 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false redirectPort=8443 acceptCount=100 connectionTimeout=2 disableUploadTimeout=true / Engine name=Catalina defaultHost=server.com debug=0 Host name=server.com debug=0 appBase=webapps
Re: Tomcat 5.5 context.xml question.
2012/8/24 Josh Gooding josh.good...@gmail.com: Server port=8005 shutdown=SHUTDOWN debug=0 All those debug= attributes... - Tomcat 5.5 does not support them. See Configuration Reference chapters of documentation, where these attributes are not mentioned. (Well, nothing fatal - they will be just silently ignored). GlobalNamingResources Environment name=simpleValue type=java.lang.Integer value=30/ Sample value? /GlobalNamingResources Service name=Catalina Connector port=8009 enableLookups=false redirectPort=8443 debug=0 protocol=AJP/1.3 / Connector port=8080 maxHttpHeaderSize=8192 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false redirectPort=8443 acceptCount=100 connectionTimeout=2 disableUploadTimeout=true / Do you need both connectors? Engine name=Catalina defaultHost=server.com debug=0 Host name=server.com debug=0 appBase=webapps deployOnStartup=true unpackWARs=true autoDeploy=true xmlValidation=false xmlNamespaceAware=false / /Engine /Service /Server It's pretty simple and elegant. Not hard to follow. So in my project, I've created a META-INF/context.xml file with the following declaration: Context Realm className=org.apache.catalina.realm.JDBCRealm It'd be better to use DataSourceRealm instead of JDBCRealm. ... /Context again, not hard to follow. this project is packaged up in the WebEMR.war and resides under the $CATALINA_HOME/webapps/billing-1.0.4 directory According to your configuration (the appBase attribute of Host), every subdirectory and every war file in the $CATALINA_HOME/webapps/ is a web application. So billing-1.0.4 is a web application and WebEMR.war is just a static resource in it, that you can download via http://localhost:8080/billing-1.0.4/WebEMR.war If you want the application to be exposed as http://localhost:8080/1.0.4/, rename the war to the same name as the path you are looking for (1.0.4) and place it directly into webapps directory. That would be $CATALINA_HOME/webapps/1.0.4.war Tomcat will autodeploy it (which involves unpacking it into $CATALINA_HOME/webapps/1.0.4). Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 5.5 context.xml question.
Yeah you see what I'm given to work with. The sever.xml will be cleaned up, but i'm trying to get this fixed to upgrade to 6.0.35 or 7. So let me ask this, given that billing-1.0.4 is a branch that contains 4 war files. Am I able to deploy say billing-1.0.5 on the fly without having to restart tomcat from a CI server like hudson? If I have hudson (as the TC user) make a new directory in tomcat's webapps folder while it was still running and push the 4 wars? The current solution they have, they have locked a single branch to each tomcat server (dumb dumb dumb) and I'm trying to give them access to EVERY development server they have for multiple branches. So I want to have webapps/billing-1.0.4/WebEMR.war, foo.war, bar.war, thing.war. Then also have billing-1.0.5/WebEMR.war, foo.war, etc. It just has to be dynamic enough to not need restarted everytime I need to add a new branch to the server. I want it to be localhost:8080/billing-1.0.4/WebEMR, to locahost:8080/billing-x.n.y/WebEMR According to your configuration (the appBase attribute of Host), every subdirectory and every war file in the $CATALINA_HOME/webapps/ is a web application. So billing-1.0.4 is a web application and WebEMR.war is just a static resource in it, that you can download via http://localhost:8080/billing-1.0.4/WebEMR.warhttp://localhost:8080/billing-1.0.4/WebEMR.war If you want the application to be exposed as .http://localhost:8080/1.0.4/ http://localhost:8080/1.0.4/, rename the war to the same name as the path you are looking for (1.0.4) and place it directly into webapps directory. That would be $CATALINA_HOME/webapps/1.0.4. war Tomcat will autodeploy it (which involves unpacking it into $CATALINA_HOME/webapps/1.0.4). Best regards, Konstantin Kolinko On Fri, Aug 24, 2012 at 2:58 PM, Konstantin Kolinko knst.koli...@gmail.comwrote: 2012/8/24 Josh Gooding josh.good...@gmail.com: Server port=8005 shutdown=SHUTDOWN debug=0 All those debug= attributes... - Tomcat 5.5 does not support them. See Configuration Reference chapters of documentation, where these attributes are not mentioned. (Well, nothing fatal - they will be just silently ignored). GlobalNamingResources Environment name=simpleValue type=java.lang.Integer value=30/ Sample value? /GlobalNamingResources Service name=Catalina Connector port=8009 enableLookups=false redirectPort=8443 debug=0 protocol=AJP/1.3 / Connector port=8080 maxHttpHeaderSize=8192 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false redirectPort=8443 acceptCount=100 connectionTimeout=2 disableUploadTimeout=true / Do you need both connectors? Engine name=Catalina defaultHost=server.com debug=0 Host name=server.com debug=0 appBase=webapps deployOnStartup=true unpackWARs=true autoDeploy=true xmlValidation=false xmlNamespaceAware=false / /Engine /Service /Server It's pretty simple and elegant. Not hard to follow. So in my project, I've created a META-INF/context.xml file with the following declaration: Context Realm className=org.apache.catalina.realm.JDBCRealm It'd be better to use DataSourceRealm instead of JDBCRealm. ... /Context again, not hard to follow. this project is packaged up in the WebEMR.war and resides under the $CATALINA_HOME/webapps/billing-1.0.4 directory According to your configuration (the appBase attribute of Host), every subdirectory and every war file in the $CATALINA_HOME/webapps/ is a web application. So billing-1.0.4 is a web application and WebEMR.war is just a static resource in it, that you can download via http://localhost:8080/billing-1.0.4/WebEMR.war If you want the application to be exposed as http://localhost:8080/1.0.4/, rename the war to the same name as the path you are looking for (1.0.4) and place it directly into webapps directory. That would be $CATALINA_HOME/webapps/1.0.4.war Tomcat will autodeploy it (which involves unpacking it into $CATALINA_HOME/webapps/1.0.4). Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 5.5 context.xml question.
On 24/08/2012 20:53, Josh Gooding wrote: Yeah you see what I'm given to work with. The sever.xml will be cleaned up, but i'm trying to get this fixed to upgrade to 6.0.35 or 7. So let me ask this, given that billing-1.0.4 is a branch that contains 4 war files. Am I able to deploy say billing-1.0.5 on the fly without having to restart tomcat from a CI server like hudson? If I have hudson (as the TC user) make a new directory in tomcat's webapps folder while it was still running and push the 4 wars? The current solution they have, they have locked a single branch to each tomcat server (dumb dumb dumb) and I'm trying to give them access to EVERY development server they have for multiple branches. So I want to have webapps/billing-1.0.4/WebEMR.war, foo.war, bar.war, thing.war. Then also have billing-1.0.5/WebEMR.war, foo.war, etc. It just has to be dynamic enough to not need restarted everytime I need to add a new branch to the server. I want it to be localhost:8080/billing-1.0.4/WebEMR, to locahost:8080/billing-x.n.y/WebEMR Rename the WAR to billing-x.n.y#WebEMR.war and place it directly in the webapps directory. Providing autoDeploy is enabled (it is by default) it should just work. See http://tomcat.apache.org/tomcat-5.5-doc/config/context.html#Introduction for why this works. (Search for #) Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 5.5 context.xml question.
Mark, Konstantin, thank you very much. As usual I highly appreciate it. On Fri, Aug 24, 2012 at 4:05 PM, Mark Thomas ma...@apache.org wrote: On 24/08/2012 20:53, Josh Gooding wrote: Yeah you see what I'm given to work with. The sever.xml will be cleaned up, but i'm trying to get this fixed to upgrade to 6.0.35 or 7. So let me ask this, given that billing-1.0.4 is a branch that contains 4 war files. Am I able to deploy say billing-1.0.5 on the fly without having to restart tomcat from a CI server like hudson? If I have hudson (as the TC user) make a new directory in tomcat's webapps folder while it was still running and push the 4 wars? The current solution they have, they have locked a single branch to each tomcat server (dumb dumb dumb) and I'm trying to give them access to EVERY development server they have for multiple branches. So I want to have webapps/billing-1.0.4/WebEMR.war, foo.war, bar.war, thing.war. Then also have billing-1.0.5/WebEMR.war, foo.war, etc. It just has to be dynamic enough to not need restarted everytime I need to add a new branch to the server. I want it to be localhost:8080/billing-1.0.4/WebEMR, to locahost:8080/billing-x.n.y/WebEMR Rename the WAR to billing-x.n.y#WebEMR.war and place it directly in the webapps directory. Providing autoDeploy is enabled (it is by default) it should just work. See http://tomcat.apache.org/tomcat-5.5-doc/config/context.html#Introduction for why this works. (Search for #) Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 5.5 context.xml question.
2012/8/25 Mark Thomas ma...@apache.org: On 24/08/2012 20:53, Josh Gooding wrote: Yeah you see what I'm given to work with. The sever.xml will be cleaned up, but i'm trying to get this fixed to upgrade to 6.0.35 or 7. So let me ask this, given that billing-1.0.4 is a branch that contains 4 war files. Am I able to deploy say billing-1.0.5 on the fly without having to restart tomcat from a CI server like hudson? If I have hudson (as the TC user) make a new directory in tomcat's webapps folder while it was still running and push the 4 wars? The current solution they have, they have locked a single branch to each tomcat server (dumb dumb dumb) and I'm trying to give them access to EVERY development server they have for multiple branches. So I want to have webapps/billing-1.0.4/WebEMR.war, foo.war, bar.war, thing.war. Then also have billing-1.0.5/WebEMR.war, foo.war, etc. It just has to be dynamic enough to not need restarted everytime I need to add a new branch to the server. I want it to be localhost:8080/billing-1.0.4/WebEMR, to locahost:8080/billing-x.n.y/WebEMR Rename the WAR to billing-x.n.y#WebEMR.war and place it directly in the webapps directory. Providing autoDeploy is enabled (it is by default) it should just work. See http://tomcat.apache.org/tomcat-5.5-doc/config/context.html#Introduction for why this works. (Search for #) According to changelog, support for '#' was backported to 5.5 in 5.5.27. (Mentioned as 44021, 43013 in the changelog). So for 5.5.23 Mark's advise would not work, but it will work for all current versions of 5.5, 6, 7. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat building problems: Apache Tomcat 5.5 Servelet/JSP container
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck, On 7/12/12 6:49 PM, Caldarale, Charles R wrote: tar.gz (pgp, md5) Should be labelled competent software engineers should download this one. ;) I kid: I feel bad for anyone who is forced to run any Microsoft Windows-based server, though. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAA2oEACgkQ9CaO5/Lv0PB56wCgh6WT1Y29IqRqS+FLY5Dv+RIG GQIAoJ5WFUfg6SAfaCGW2S1DKtWiGc9C =8LMd -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat building problems: Apache Tomcat 5.5 Servelet/JSP container
On 11/07/2012 22:26, Wei, Mingzhen wrote: Konstantin, I followed the RUNNING.TXT after installing the binary release of Tomcat 5.5. But I cannot find the catalina.bat and catalina.sh for more environmental variables to set. Why tomcat is such a pain for installation? It's not. You're making it harder. Seriously, just download the actual binaries: http://tomcat.apache.org/download-70.cgi http://tomcat.apache.org/download-60.cgi http://tomcat.apache.org/download-55.cgi Those are for Tomcat 7.0, 6.0 and 5.5. p Thanks for your help. -Original Message- From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] Sent: Tuesday, July 10, 2012 10:57 AM To: Tomcat Users List Subject: Re: Tomcat building problems: Apache Tomcat 5.5 Servelet/JSP container 2012/7/10 Wei, Mingzhen w...@mst.edu: Konstantin Kolinko, Could you tell me the point in more detail? I am new with Tomcat and need it badly to be able to run another application. Do you mean I need to try the combination of ant5.5 download + Ant 1.8.4 and JDK 1.4.2_19? 1. Why are you trying to build it from source? Why the existing binary releases are not good enough for you? 2. Have you read the BUILDING.txt file? 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 -- [key:62590808] signature.asc Description: OpenPGP digital signature
Re: Tomcat building problems: Apache Tomcat 5.5 Servelet/JSP container
Pid wrote: On 11/07/2012 22:26, Wei, Mingzhen wrote: Konstantin, I followed the RUNNING.TXT after installing the binary release of Tomcat 5.5. But I cannot find the catalina.bat and catalina.sh for more environmental variables to set. Why tomcat is such a pain for installation? It's not. You're making it harder. Seriously, just download the actual binaries: http://tomcat.apache.org/download-70.cgi http://tomcat.apache.org/download-60.cgi http://tomcat.apache.org/download-55.cgi Those are for Tomcat 7.0, 6.0 and 5.5. My quarter : Yes, but I believe that the OP's confusion is due (again) to the fact that for Windows, there are two possibilities (the zip and the Service installer), and that the Service installer version does not contain all the same files as the zip version. Considering the number of times this has come up on the list, I do not understand why the people who make the Service installer don't just add the missing files in (tomcat)/bin and bring this matter to rest once and for all. Of course, then we'd still have to explain that the Service, once installed, does not use the .bat files when running as a service. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat building problems: Apache Tomcat 5.5 Servelet/JSP container
From: André Warnier [mailto:a...@ice-sa.com] Subject: Re: Tomcat building problems: Apache Tomcat 5.5 Servelet/JSP container Considering the number of times this has come up on the list, I do not understand why the people who make the Service installer don't just add the missing files in (tomcat)/bin and bring this matter to rest once and for all. Of course, then we'd still have to explain that the Service, once installed, does not use the .bat files when running as a service. Possibly exactly because of that - the service users will be wondering why their highly inappropriate muckings about with startup.bat and catalina.bat aren't effective. I think it would be better if the links on the download page looked something like this: zip (pgp, md5) - runs only via scripts on Windows tar.gz (pgp, md5) 32-bit Windows zip (pgp, md5) - runs via scripts or as a service 64-bit Windows zip (pgp, md5) - runs via scripts or as a service 32-bit/64-bit Windows Service Installer (pgp, md5) - runs only as a service - 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: Tomcat building problems: Apache Tomcat 5.5 Servelet/JSP container
Konstantin, I followed the RUNNING.TXT after installing the binary release of Tomcat 5.5. But I cannot find the catalina.bat and catalina.sh for more environmental variables to set. Why tomcat is such a pain for installation? Thanks for your help. -Original Message- From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] Sent: Tuesday, July 10, 2012 10:57 AM To: Tomcat Users List Subject: Re: Tomcat building problems: Apache Tomcat 5.5 Servelet/JSP container 2012/7/10 Wei, Mingzhen w...@mst.edu: Konstantin Kolinko, Could you tell me the point in more detail? I am new with Tomcat and need it badly to be able to run another application. Do you mean I need to try the combination of ant5.5 download + Ant 1.8.4 and JDK 1.4.2_19? 1. Why are you trying to build it from source? Why the existing binary releases are not good enough for you? 2. Have you read the BUILDING.txt file? 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
war file extraction issues in tomcat 5.5
I am finding many issues in it but still not able to resolve this. Is there
any expert opinion on this... I have this setup in Cpanel.
Apache Tomcat/5.5.35 OS - Linux 2.6.18-028stab099.3 JVM Version:
1.6.0_29-b11
I have added export JAVA_OPTS=-XX:PermSize=128M -XX:MaxPermSize=524M in
catlina.sh but dint help.
*Log file info in catalina.err*
**
Jul 10, 2012 3:23:16 AM org.apache.catalina.core.AprLifecycleListener init
INFO: The APR based Apache Tomcat Native library which allows
optimal performance in production environments was not found on the
java.library.path:
/usr/local/jdk/jre/lib/i386/client:/usr/local/jdk/jre/lib/i386:/usr/java/packages/lib/i386:/lib:/usr/lib
Jul 10, 2012 3:23:17 AM org.apache.coyote.http11.Http11BaseProtocol init
INFO: Initializing Coyote HTTP/1.1 on http-8080
Jul 10, 2012 3:23:17 AM org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 434 ms
Jul 10, 2012 3:23:17 AM org.apache.catalina.core.StandardService start
INFO: Starting service Catalina
Jul 10, 2012 3:23:17 AM org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/5.5.35
Jul 10, 2012 3:23:17 AM org.apache.catalina.core.StandardHost start
INFO: XML validation disabled
Jul 10, 2012 3:23:17 AM org.apache.catalina.startup.HostConfig deployWAR
INFO: Deploying web application archive sample.war
Jul 10, 2012 3:23:17 AM org.apache.catalina.startup.ContextConfig init
SEVERE: Exception fixing docBase: {0}
java.io.FileNotFoundException:
/home/surgnet/public_html/sample/META-INF/MANIFEST.MF (No such file or
directory)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.init(FileOutputStream.java:194)
at java.io.FileOutputStream.init(FileOutputStream.java:145)
at org.apache.catalina.startup.ExpandWar.expand(ExpandWar.java:457)
at org.apache.catalina.startup.ExpandWar.expand(ExpandWar.java:173)
at
org.apache.catalina.startup.ContextConfig.fixDocBase(ContextConfig.java:864)
at
org.apache.catalina.startup.ContextConfig.init(ContextConfig.java:999)
at
org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:279)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:120)
at
org.apache.catalina.core.StandardContext.init(StandardContext.java:5095)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:4024)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:760)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:740)
at
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:544)
at
org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:884)
at
org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:737)
at
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:498)
at
org.apache.catalina.startup.HostConfig.start(HostConfig.java:1203)
at
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:319)
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:597)
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:597)
at
org.apache.commons.daemon.support.DaemonLoader.start(DaemonLoader.java:243)
Jul 10, 2012 3:23:17 AM org.apache.catalina.startup.HostConfig deployWAR
INFO: Deploying web application archive surgeryplanet.war
Jul 10, 2012 3:23:17 AM
RE: Tomcat building problems: Apache Tomcat 5.5 Servelet/JSP container
Konstantin Kolinko, Could you tell me the point in more detail? I am new with Tomcat and need it badly to be able to run another application. Do you mean I need to try the combination of ant5.5 download + Ant 1.8.4 and JDK 1.4.2_19? Thanks. --- Mingzhen Wei, PhD Assistant Research Professor Petroleum Engineering Program Department of Geological Sciences and Engineering 330 McNutt Hall, 1400 N. Bishop Ave. Missouri University of Science and Technology Rolla, Missouri 65409-0410 Email: w...@mst.edu Office phone: (573) 341-4657 Cell phone: (573) 201-3924 Fax: (573)-341-6935 --- -Original Message- From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] Sent: Friday, July 06, 2012 2:56 PM To: Tomcat Users List Subject: Re: Tomcat building problems: Apache Tomcat 5.5 Servelet/JSP container 2012/7/6 Christopher Schultz ch...@christopherschultz.net: On 7/6/12 12:54 PM, Konstantin Kolinko wrote: 2012/7/6 Wei, Mingzhen w...@mst.edu: I was trying to build Apache Tomcat 5.5 Servelet for another application. I followed the steps from the link: http://tomcat.apache.org/tomcat-5.5-doc/building.html. I have done the following: 1. Installed JDK1.6 2. Download and installed Apache Ant 1.8.4 3. Download Tomcat 5.5 source package in zip file 4. Set and updated the environment parameters for JAVA_HOME, PATH, ANT_HOME I cannot run the following step ant download correctly. It complains the includeantruntime setup, and alerting me with errors for classes as BasicDataSource, DelegatingStatement, DelegatingPreparedStatement, and many more. The errors say that those classes as not abstract and do not override the abstract methods in other sources. 1. You need JDK 1.4 to build Tomcat 5.5. 2. The version of Ant targeted by the build script is 1.6.2. With only a little bit of digging, I couldn't find an earliest-version of Ant that supports the includeAntRuntime attribute for javac. But, I suspect that 1.6.2 *does* support it, so there doesn't seem to be a reason not to specify a value for it in the build file. That will allow Tomcat 5.5 to be built with later ant versions (but, of course, using the proper JDK version). It is an interesting note. Anyway, 1. ant download deploy in 5.5 builds correctly with Ant 1.8.4 and JDK 1.4.2_19. So I do not see what the fix will bring besides a silenced warning. 2. Anyone may propose a patch for 5.5 (either in STATUS or in bugzilla). 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: Tomcat building problems: Apache Tomcat 5.5 Servelet/JSP container
2012/7/10 Wei, Mingzhen w...@mst.edu: Konstantin Kolinko, Could you tell me the point in more detail? I am new with Tomcat and need it badly to be able to run another application. Do you mean I need to try the combination of ant5.5 download + Ant 1.8.4 and JDK 1.4.2_19? 1. Why are you trying to build it from source? Why the existing binary releases are not good enough for you? 2. Have you read the BUILDING.txt file? Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: war file extraction issues in tomcat 5.5
Rajesh,
I'm not quite sure where to start with this. I'll make a few comments inline.
The comments will be bracketed with:
= COMMENT =
so that they're easier to see.
However, you really need to read and understand the following documentation.
http://tomcat.apache.org/tomcat-5.5-doc/index.html
Please note that Tomcat 5.5 is rapidly approaching EOL. It would be a good idea
to move to at least Tomcat 6 (and preferably Tomcat 7) if at all possible.
- Original Message -
From: Rajesh Kumar rajeshkumarmaht...@gmail.com
To: users@tomcat.apache.org
Cc:
Sent: Monday, July 9, 2012 11:56 PM
Subject: war file extraction issues in tomcat 5.5
I am finding many issues in it but still not able to resolve this. Is there
any expert opinion on this... I have this setup in Cpanel.
Apache Tomcat/5.5.35 OS - Linux 2.6.18-028stab099.3 JVM Version:
1.6.0_29-b11
I have added export JAVA_OPTS=-XX:PermSize=128M -XX:MaxPermSize=524M
in
catlina.sh but dint help.
= COMMENT =
This has nothing to do with your problem. This doesn't even increase heap
memory. It increases permgen memory, which is a permanent storage space for the
JVM. For example, class definitions are stored here.
You probably wanted to expand heap memory. However by default heap memory is
256 M and should be enough for small to medium sized applications.
Don't add this to JAVA_OPTS, because this will add memory to both the Tomcat
process and the shutdown process. Add it to CATALINA_OPTS instead.
Finally, don't edit catalina.sh. Create a file called setenv.sh in
$CATALINA_HOME/bin. Add your options there.
= COMMENT =
*Log file info in catalina.err*
**
Jul 10, 2012 3:23:16 AM org.apache.catalina.core.AprLifecycleListener init
INFO: The APR based Apache Tomcat Native library which allows
optimal performance in production environments was not found on the
java.library.path:
/usr/local/jdk/jre/lib/i386/client:/usr/local/jdk/jre/lib/i386:/usr/java/packages/lib/i386:/lib:/usr/lib
Jul 10, 2012 3:23:17 AM org.apache.coyote.http11.Http11BaseProtocol init
INFO: Initializing Coyote HTTP/1.1 on http-8080
Jul 10, 2012 3:23:17 AM org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 434 ms
Jul 10, 2012 3:23:17 AM org.apache.catalina.core.StandardService start
INFO: Starting service Catalina
Jul 10, 2012 3:23:17 AM org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/5.5.35
Jul 10, 2012 3:23:17 AM org.apache.catalina.core.StandardHost start
INFO: XML validation disabled
Jul 10, 2012 3:23:17 AM org.apache.catalina.startup.HostConfig deployWAR
INFO: Deploying web application archive sample.war
Jul 10, 2012 3:23:17 AM org.apache.catalina.startup.ContextConfig init
SEVERE: Exception fixing docBase: {0}
= COMMENT =
From the above line, it looks like you've not specified the docBase properly.
= COMMENT =
java.io.FileNotFoundException:
/home/surgnet/public_html/sample/META-INF/MANIFEST.MF (No such file or
directory)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.init(FileOutputStream.java:194)
at java.io.FileOutputStream.init(FileOutputStream.java:145)
at
org.apache.catalina.startup.ExpandWar.expand(ExpandWar.java:457)
at
org.apache.catalina.startup.ExpandWar.expand(ExpandWar.java:173)
at
org.apache.catalina.startup.ContextConfig.fixDocBase(ContextConfig.java:864)
at
org.apache.catalina.startup.ContextConfig.init(ContextConfig.java:999)
at
org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:279)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:120)
at
org.apache.catalina.core.StandardContext.init(StandardContext.java:5095)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:4024)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:760)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:740)
at
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:544)
at
org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:884)
at
org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:737)
at
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:498)
at
org.apache.catalina.startup.HostConfig.start(HostConfig.java:1203)
at
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:319)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:120)
at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1022
Re: [OT] war file extraction issues in tomcat 5.5
Mark Eggers wrote: ... . . . . just my nickel Better. Keep doing that, and you'll reach a normal consultancy tariff in about 12 of your thoughtful answers. Which I think are worth as much; I hope you got that aspect of my earlier comment. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: war file extraction issues in tomcat 5.5
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Rajesh,
On 7/10/12 2:56 AM, Rajesh Kumar wrote:
I am finding many issues in it but still not able to resolve this.
Is there any expert opinion on this... I have this setup in
Cpanel.
I have added export JAVA_OPTS=-XX:PermSize=128M
-XX:MaxPermSize=524M in catlina.sh but dint help.
As Mark Eggers says, these settings are not relevant. All comments he
makes about them are spot-on: move to startup.sh, use CATALINA_OPTS,
and you probably meant -Xms and -Xmx, though some people really do
need a huge PermGen. Are you sure you're one of them?
SEVERE: Exception fixing docBase: {0}
java.io.FileNotFoundException:
/home/surgnet/public_html/sample/META-INF/MANIFEST.MF (No such file
or directory) at java.io.FileOutputStream.open(Native Method) at
java.io.FileOutputStream.init(FileOutputStream.java:194) at
java.io.FileOutputStream.init(FileOutputStream.java:145) at
org.apache.catalina.startup.ExpandWar.expand(ExpandWar.java:457)
ExpandWar.expand is trying to write to the file
/home/surgnet/public_html/sample/META-INF/MANIFEST.MF and it can't:
No such file or directory is a stupid exception message. What it
really means is that the parent directory
(/home/surgnet/public_html/sample/META-INF/) does not exist. Try a
simple test like this and you'll see you get the same exception message:
import java.io.*;
public class FileTest
{
public static void main(String[] args)
throws Exception
{
File file = new File(./nosuchdir/a_file);
new FileOutputStream(file);
}
}
So, the problem is that the parent directory doesn't exist. Why? Well,
ExpandWar.expand, on line 165 does this:
161 int last = name.lastIndexOf('/');
162 if (last = 0) {
163 File parent = new File(docBase,
164 name.substring(0, last));
165 parent.mkdirs();
166 }
There is no check of the return value of parent.mkdirs(), which can
fail with no exception (part of the charm of the java.io package:
sometimes you get an exception and sometimes you don't).
Technically, one could argue that this is a bug in Tomcat (which I
will log, though it will probably not be fixed since it isn't serious
enough to warrant a fix to a Tomcat version which is in
maintenance-mode -- that is, one that really only gets security
updates) because the return value of File.mkdirs should really be
checked for false which indicates a problem. Then, an exception could
be thrown that says I can't create [parent dir] and bombs, so you
don't get the stupid FileNotFoundException.
At any rate, I highly suspect that this is a file-permissions error:
can your Tomcat user write to the /home/surgnet/public_html/sample/
directory? Remember that the user will require both write *and*
execute privileges to really use a directory on a *NIX filesystem.
SEVERE: Exception fixing docBase: {0}
java.io.FileNotFoundException:
/home/surgnet/public_html/surgeryplanet/META-INF/MANIFEST.MF (No
such file or directory) at java.io.FileOutputStream.open(Native
Method) at
java.io.FileOutputStream.init(FileOutputStream.java:194) at
java.io.FileOutputStream.init(FileOutputStream.java:145) at
org.apache.catalina.startup.ExpandWar.expand(ExpandWar.java:457) at
org.apache.catalina.startup.ExpandWar.expand(ExpandWar.java:173)
This is certainly the same error.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk/81/kACgkQ9CaO5/Lv0PDotACff+q6Z13Q4ofUK9iyQwqjdvWF
y8oAoKQCEe3ylZe2a3zD7+mGH92vZC2s
=Ohgw
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: war file extraction issues in tomcat 5.5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, On 7/10/12 9:33 PM, Christopher Schultz wrote: Technically, one could argue that this is a bug in Tomcat (which I will log, though it will probably not be fixed since it isn't serious enough to warrant a fix to a Tomcat version which is in maintenance-mode -- that is, one that really only gets security updates) because the return value of File.mkdirs should really be checked for false which indicates a problem. Then, an exception could be thrown that says I can't create [parent dir] and bombs, so you don't get the stupid FileNotFoundException. https://issues.apache.org/bugzilla/show_bug.cgi?id=53531 - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/83j0ACgkQ9CaO5/Lv0PBosQCgr423Aiuvz+xB/qn/aXArpZto spIAn3T0R4bKeyAXqgn+/nC8de7YXRV7 =HQOK -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat building problems: Apache Tomcat 5.5 Servelet/JSP container
I was trying to build Apache Tomcat 5.5 Servelet for another application. I followed the steps from the link: http://tomcat.apache.org/tomcat-5.5-doc/building.html. I have done the following: 1. Installed JDK1.6 2. Download and installed Apache Ant 1.8.4 3. Download Tomcat 5.5 source package in zip file 4. Set and updated the environment parameters for JAVA_HOME, PATH, ANT_HOME I cannot run the following step ant download correctly. It complains the includeantruntime setup, and alerting me with errors for classes as BasicDataSource, DelegatingStatement, DelegatingPreparedStatement, and many more. The errors say that those classes as not abstract and do not override the abstract methods in other sources. Please tell me how to fix the problem, thank you very much. Mingzhen
Re: Tomcat building problems: Apache Tomcat 5.5 Servelet/JSP container
2012/7/6 Wei, Mingzhen w...@mst.edu: I was trying to build Apache Tomcat 5.5 Servelet for another application. I followed the steps from the link: http://tomcat.apache.org/tomcat-5.5-doc/building.html. I have done the following: 1. Installed JDK1.6 2. Download and installed Apache Ant 1.8.4 3. Download Tomcat 5.5 source package in zip file 4. Set and updated the environment parameters for JAVA_HOME, PATH, ANT_HOME I cannot run the following step ant download correctly. It complains the includeantruntime setup, and alerting me with errors for classes as BasicDataSource, DelegatingStatement, DelegatingPreparedStatement, and many more. The errors say that those classes as not abstract and do not override the abstract methods in other sources. 1. You need JDK 1.4 to build Tomcat 5.5. 2. The version of Ant targeted by the build script is 1.6.2. One of the reasons why you cannot build it with Java 6, is that the version of Apache Commons DBCP used in it has to run on Java 1.4 and cannot be built with Java 6 because of java.sql API changes. See also BUILDING.txt in the source distributive or in svn repository. It is more authoritative than building.html. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat building problems: Apache Tomcat 5.5 Servelet/JSP container
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Konstantin, On 7/6/12 12:54 PM, Konstantin Kolinko wrote: 2012/7/6 Wei, Mingzhen w...@mst.edu: I was trying to build Apache Tomcat 5.5 Servelet for another application. I followed the steps from the link: http://tomcat.apache.org/tomcat-5.5-doc/building.html. I have done the following: 1. Installed JDK1.6 2. Download and installed Apache Ant 1.8.4 3. Download Tomcat 5.5 source package in zip file 4. Set and updated the environment parameters for JAVA_HOME, PATH, ANT_HOME I cannot run the following step ant download correctly. It complains the includeantruntime setup, and alerting me with errors for classes as BasicDataSource, DelegatingStatement, DelegatingPreparedStatement, and many more. The errors say that those classes as not abstract and do not override the abstract methods in other sources. 1. You need JDK 1.4 to build Tomcat 5.5. 2. The version of Ant targeted by the build script is 1.6.2. With only a little bit of digging, I couldn't find an earliest-version of Ant that supports the includeAntRuntime attribute for javac. But, I suspect that 1.6.2 *does* support it, so there doesn't seem to be a reason not to specify a value for it in the build file. That will allow Tomcat 5.5 to be built with later ant versions (but, of course, using the proper JDK version). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/3JJ8ACgkQ9CaO5/Lv0PDrGQCgt8WyLNF65G+bc+VReUE2hiEd IXUAn2vf6qqGa/+r7TzlJ1c94A3qpdpj =3kIJ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat building problems: Apache Tomcat 5.5 Servelet/JSP container
2012/7/6 Christopher Schultz ch...@christopherschultz.net: On 7/6/12 12:54 PM, Konstantin Kolinko wrote: 2012/7/6 Wei, Mingzhen w...@mst.edu: I was trying to build Apache Tomcat 5.5 Servelet for another application. I followed the steps from the link: http://tomcat.apache.org/tomcat-5.5-doc/building.html. I have done the following: 1. Installed JDK1.6 2. Download and installed Apache Ant 1.8.4 3. Download Tomcat 5.5 source package in zip file 4. Set and updated the environment parameters for JAVA_HOME, PATH, ANT_HOME I cannot run the following step ant download correctly. It complains the includeantruntime setup, and alerting me with errors for classes as BasicDataSource, DelegatingStatement, DelegatingPreparedStatement, and many more. The errors say that those classes as not abstract and do not override the abstract methods in other sources. 1. You need JDK 1.4 to build Tomcat 5.5. 2. The version of Ant targeted by the build script is 1.6.2. With only a little bit of digging, I couldn't find an earliest-version of Ant that supports the includeAntRuntime attribute for javac. But, I suspect that 1.6.2 *does* support it, so there doesn't seem to be a reason not to specify a value for it in the build file. That will allow Tomcat 5.5 to be built with later ant versions (but, of course, using the proper JDK version). It is an interesting note. Anyway, 1. ant download deploy in 5.5 builds correctly with Ant 1.8.4 and JDK 1.4.2_19. So I do not see what the fix will bring besides a silenced warning. 2. Anyone may propose a patch for 5.5 (either in STATUS or in bugzilla). Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: ClassNotFoundException Error in Tomcat 5.5 and Tomcat 6.0
2012/6/10 Venkata Pavan Kumar Sannisetty sunny...@gmail.com: I am having this strange issue with the tomcat 5.5 and tomcat 6.0 servers. I have two web applications which will be installed on tomcat.When tomcat is started these two web applications also get started simultaneously but sometimes one web application fails to initialize because of the init failure in one application another application is getting classnotfoundexception errors while running. In tomcat 7.0 the application is running fine even if the other application failed to initialize. After some debugging i came to know there is one jar named crystal.jar which is in the web-inf/lib folder of both applications. I have moved the jar to common/lib folder of tomcat then it started working fine. I want to know why it is working fine in tomcat 7.0 not in tomcat 5.x and tomcat 6.x versions. Is there any change in classloading architecture between these versions ? Guessing on a crystal jar^H^H^H ball,.. There exist a known kind of PermGen memory leaks, when a library class is referenced by a system class and thus lives beyond its age. One example is when Java discovers a JDBC driver, or some other service and automatically registers it. It keeps reference to it in a system, but the class itself belongs to the web application and has to be unloaded when application stops - but cannot, because of that reference. Not all such references are easy to clear. One typical symptom in such a case is that the first web application that relies on this system feature will succeed, but the second and other ones will fail (because the service that is registered in the system belongs to first web application and cannot see classes from classloader of the second application and vice versa). Tomcat 7 and recent versions of Tomcat 6 have better protection against certain known PermGen memory leaks in their default configuration. Tomcat 5.5 does not have such protection at all. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: ClassNotFoundException Error in Tomcat 5.5 and Tomcat 6.0
Hi Konstantin Kolinko, Thanks for the response. Can you point out some reference where i can know about this permgen memory leak. I am unable to find good article/material on it to understand furthur. Thanks, Pavan. On 10 June 2012 06:59, Konstantin Kolinko knst.koli...@gmail.com wrote: 2012/6/10 Venkata Pavan Kumar Sannisetty sunny...@gmail.com: I am having this strange issue with the tomcat 5.5 and tomcat 6.0 servers. I have two web applications which will be installed on tomcat.When tomcat is started these two web applications also get started simultaneously but sometimes one web application fails to initialize because of the init failure in one application another application is getting classnotfoundexception errors while running. In tomcat 7.0 the application is running fine even if the other application failed to initialize. After some debugging i came to know there is one jar named crystal.jar which is in the web-inf/lib folder of both applications. I have moved the jar to common/lib folder of tomcat then it started working fine. I want to know why it is working fine in tomcat 7.0 not in tomcat 5.x and tomcat 6.x versions. Is there any change in classloading architecture between these versions ? Guessing on a crystal jar^H^H^H ball,.. There exist a known kind of PermGen memory leaks, when a library class is referenced by a system class and thus lives beyond its age. One example is when Java discovers a JDBC driver, or some other service and automatically registers it. It keeps reference to it in a system, but the class itself belongs to the web application and has to be unloaded when application stops - but cannot, because of that reference. Not all such references are easy to clear. One typical symptom in such a case is that the first web application that relies on this system feature will succeed, but the second and other ones will fail (because the service that is registered in the system belongs to first web application and cannot see classes from classloader of the second application and vice versa). Tomcat 7 and recent versions of Tomcat 6 have better protection against certain known PermGen memory leaks in their default configuration. Tomcat 5.5 does not have such protection at all. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: ClassNotFoundException Error in Tomcat 5.5 and Tomcat 6.0
2012/6/10 Venkata Pavan Kumar Sannisetty sunny...@gmail.com: Hi Konstantin Kolinko, Thanks for the response. Can you point out some reference where i can know about this permgen memory leak. I am unable to find good article/material on it to understand furthur. It should be somewhere here: 1) http://people.apache.org/~markt/presentations/ 2010-08-05-Memory-Leaks-JavaOne-60mins.pdf 2010-11-04-Memory-Leaks-60mins.pdf 2) http://eclipse.org/mat/ 3) http://wiki.apache.org/tomcat/FAQ/Troubleshooting_and_Diagnostics http://wiki.apache.org/tomcat/MemoryLeakProtection Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: ClassNotFoundException Error in Tomcat 5.5 and Tomcat 6.0
Thanks a Lot. On 10 June 2012 14:29, Konstantin Kolinko knst.koli...@gmail.com wrote: 2012/6/10 Venkata Pavan Kumar Sannisetty sunny...@gmail.com: Hi Konstantin Kolinko, Thanks for the response. Can you point out some reference where i can know about this permgen memory leak. I am unable to find good article/material on it to understand furthur. It should be somewhere here: 1) http://people.apache.org/~markt/presentations/ 2010-08-05-Memory-Leaks-JavaOne-60mins.pdf 2010-11-04-Memory-Leaks-60mins.pdf 2) http://eclipse.org/mat/ 3) http://wiki.apache.org/tomcat/FAQ/Troubleshooting_and_Diagnostics http://wiki.apache.org/tomcat/MemoryLeakProtection Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Enabling logging in Tomcat 5.5
All: I am forced by a client's requirement to use Java 1.4.2 (I know, antediluvian, right?) and so to test on Tomcat 5.5 with the compatibility package. So far, Tomcat works fine, with one exception: I get no logs. I have set up logging just as suggested (in detail) in http://tomcat.apache.org/tomcat-5.5-doc/logging.html, but without avail. Any other ideas? My application isn't deploying, and I can't find out why without logs, of course. David
Re: Enabling logging in Tomcat 5.5
2012/4/3 David Sills dsi...@datasourceinc.com: I am forced by a client's requirement to use Java 1.4.2 (I know, antediluvian, right?) and so to test on Tomcat 5.5 with the compatibility package. So far, Tomcat works fine, with one exception: I get no logs. I have set up logging just as suggested (in detail) in http://tomcat.apache.org/tomcat-5.5-doc/logging.html, but without avail. Any other ideas? My application isn't deploying, and I can't find out why without logs, of course. 1. Do you intend to use java.util.logging or log4j ? I'd recommend the former. But if you have log4j.jar among common libraries then commons-logging library will autoconfigure itself to use Log4J instead of java.util.logging. So the question is what libraries do you have and where. 2. java.util.logging should be configured by startup script to use Tomcat implementation of it. See how catalina.sh does that (with -Djava.util.logging etc). So the question is how do you start your Tomcat. 3. There should be only one logging.properties for java.util.logging (or log4j.properties for juli) in a classpath of certain class-loader. If there are several files, one of them wins. Do you have logging output on your console? (or catalina.out file where it is usually redirected)? Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Enabling logging in Tomcat 5.5
Konstantin: Many thanks for your questions. I am using log4j (again, client requirement - they like the formatting and they're familiar with the configuration files). I'm currently using a fairly current version of log4j (1.2.16), as it seems to be compiled against the JDK 1.2 or lower APIs (thank heavens!). It is in the common/lib and the log4j.properties is in common/classes, as specified in the instructions referred to below (which also specifies the contents of the log4j.properties file), but that didn't produce any logging output, either in the standard out or in files. It seems to be better if I create a setenv.bat file with this content: set CLASSPATH=..\common\classes;..\common\lib\org.apache.log4j-1.2.16.jar When this is placed in the bin directory, it is automatically run by the catalina.bat file (which I discovered on walking through the process). By default, such a file doesn't exist. This produces, at least, a tomcat.log file. So I am getting something. What, exactly, especially when it comes to application logging, I'm still working through. David Sills -Original Message- From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] Sent: Tuesday, April 03, 2012 10:03 AM To: Tomcat Users List Subject: Re: Enabling logging in Tomcat 5.5 2012/4/3 David Sills dsi...@datasourceinc.com: I am forced by a client's requirement to use Java 1.4.2 (I know, antediluvian, right?) and so to test on Tomcat 5.5 with the compatibility package. So far, Tomcat works fine, with one exception: I get no logs. I have set up logging just as suggested (in detail) in http://tomcat.apache.org/tomcat-5.5-doc/logging.html, but without avail. Any other ideas? My application isn't deploying, and I can't find out why without logs, of course. 1. Do you intend to use java.util.logging or log4j ? I'd recommend the former. But if you have log4j.jar among common libraries then commons-logging library will autoconfigure itself to use Log4J instead of java.util.logging. So the question is what libraries do you have and where. 2. java.util.logging should be configured by startup script to use Tomcat implementation of it. See how catalina.sh does that (with -Djava.util.logging etc). So the question is how do you start your Tomcat. 3. There should be only one logging.properties for java.util.logging (or log4j.properties for juli) in a classpath of certain class-loader. If there are several files, one of them wins. Do you have logging output on your console? (or catalina.out file where it is usually redirected)? 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: Enabling logging in Tomcat 5.5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David, On 4/3/12 1:02 PM, David Sills wrote: It seems to be better if I create a setenv.bat file with this content: set CLASSPATH=..\common\classes;..\common\lib\org.apache.log4j-1.2.16.jar You shouldn't have to do that: Tomcat should auto-configure its CLASSPATH including the common locations you have specified above. Does it really not work unless you explicitly set the CLASSPATH environment variable? When this is placed in the bin directory, it is automatically run by the catalina.bat file (which I discovered on walking through the process). Correct. It's kind of silly to ship a completely empty file, though one could argue that a no-op file with comments in it might be a nice thing to do. So I am getting something. What, exactly, especially when it comes to application logging, I'm still working through. Let us know how things go for you. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk97MgYACgkQ9CaO5/Lv0PCqKwCfQ1NfnI4WeKa9H7gus3eY2ftI x2YAn3iMEtBa2XMEtcLfNkp9ejg5SQLS =yRwx -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Enabling logging in Tomcat 5.5
Actually, yes, it really doesn't work unless I explicitly set the opening classpath. I sort of got the hint when the famous error message about log4j not being configured correctly started popping up. -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Tuesday, April 03, 2012 1:23 PM To: Tomcat Users List Subject: Re: Enabling logging in Tomcat 5.5 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David, On 4/3/12 1:02 PM, David Sills wrote: It seems to be better if I create a setenv.bat file with this content: set CLASSPATH=..\common\classes;..\common\lib\org.apache.log4j-1.2.16.jar You shouldn't have to do that: Tomcat should auto-configure its CLASSPATH including the common locations you have specified above. Does it really not work unless you explicitly set the CLASSPATH environment variable? When this is placed in the bin directory, it is automatically run by the catalina.bat file (which I discovered on walking through the process). Correct. It's kind of silly to ship a completely empty file, though one could argue that a no-op file with comments in it might be a nice thing to do. So I am getting something. What, exactly, especially when it comes to application logging, I'm still working through. Let us know how things go for you. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk97MgYACgkQ9CaO5/Lv0PCqKwCfQ1NfnI4WeKa9H7gus3eY2ftI x2YAn3iMEtBa2XMEtcLfNkp9ejg5SQLS =yRwx -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
How to generate heap dump in Tomcat 5.5 (Windows)
Hi guys, Good afternoon! How can I generate a heap dump from tomcat 5.5 (windows version). I have downloaded an Eclipse Memory Ananlyzer and the input is .hprof file. Kindly advise. Thank you in advance. Best regards, Adrian - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to generate heap dump in Tomcat 5.5 (Windows)
2012/3/22 Adrian Zara adrian.z...@aonhewitt.com: Hi guys, Good afternoon! How can I generate a heap dump from tomcat 5.5 (windows version). I have downloaded an Eclipse Memory Ananlyzer and the input is .hprof file. Kindly advise. There are instructions in the Eclipse MAT help, http://wiki.eclipse.org/index.php/MemoryAnalyzer#Getting_a_Heap_Dump Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 5.5 IIS 7.5 2008 64bit
It is getting 404.0 error. I verified all steps. even added IIS_IUSR to the ISAPI folder. On Mon, Mar 12, 2012 at 3:07 PM, Mladen Turk mt...@apache.org wrote: On 03/12/2012 05:37 PM, Bradford Matthews wrote: Here is my steps that I used to install tomcat isapi connector. 5. EditTomcat-install-folder\conf\server.xml to allow localhost on port 8009 by adding address=127.0.0.1: !-- Define an AJP 1.3 Connector on port 8009 -- Connector port=8009 address=127.0.0.1 enableLookups=false redirectPort=8443 protocol=AJP/1.3 To test the connector: From a supported browser, enter the following URL: https://localhost/tomcat-docs The Apache Tomcat Documentation page is displayed. Requested URL https://localhost:443/docs/ Any suggestions? Seems you are requesting this over ssl so you will probably need to add scheme=https to the AJP/1.3 connector Regards -- ^TM - 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 IIS 7.5 2008 64bit
On 03/16/2012 06:15 PM, Bradford Matthews wrote: It is getting 404.0 error. I verified all steps. even added IIS_IUSR to the ISAPI folder. well are you or are you not using http:// or https://? Requested URL https://localhost:443/docs/ Any suggestions? Seems you are requesting this over ssl so you will probably need to add scheme=https to the AJP/1.3connector Regards -- ^TM - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 5.5 IIS 7.5 2008 64bit
https. I went and used the 32 bit isapi, downgraded java to 1.5jdk and it now works On Fri, Mar 16, 2012 at 5:21 PM, Mladen Turk mt...@apache.org wrote: On 03/16/2012 06:15 PM, Bradford Matthews wrote: It is getting 404.0 error. I verified all steps. even added IIS_IUSR to the ISAPI folder. well are you or are you not using http:// or https://? Requested URL https://localhost:443/docs/ Any suggestions? Seems you are requesting this over ssl so you will probably need to add scheme=https to the AJP/1.3connector Regards -- ^TM - 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
Tomcat 5.5 IIS 7.5 2008 64bit
Here is my steps that I used to install tomcat isapi connector. To install Jakarta ISAPI redirector on IIS 7, follow these steps: 1. Under the Tomcat installation folder, for example, create a folder ISAPI 2. Copy isapi_redirect-1.2.28.dll file (or the latest one) to the ISAPI folder from your Tomcat installation folder and rename it to isapi_redirect.dll. 3. Create isapi_redirect.properties file in the same location and type the given lines: #configuration file for the jakarta ISAPI redirector #The path to the ISAPI redirector Extension, relative to the website # This must be in a virtual directory with execute privileges extension_uri=/jakarta/isapi_redirect.dll #Full path to the log file for the ISAPI redirector log_file=C:\Program Files\Apache Software Foundation\Tomcat 5.5\logs\isapi_redirect.log log_level=info worker_file=C:\Program Files\Apache Software Foundation\Tomcat 5.5\conf\workers.properties worker_mount_file=C:\Program Files\Apache Software Foundation\Tomcat 5.5\conf\uriworkermap.properties 4. Under the Tomcat installation folder in conf directory, create workers.properties file and uriworkermap.properties file. For uriworkermap.properties: # uriworkermap.properties - IIS /*=ajp13w For workers.properties: # workers.properties # # This file provides minimal jk configuration properties needed to # connect to Tomcat. # # The workers that jk should create and work with # worker.list=ajp13w,jkstatus # # Defining a worker named ajp13w and of type ajp13 # Note that the name and the type do not have to match. # worker.ajp13w.type=ajp13 worker.ajp13w.host=localhost worker.ajp13w.port=8009 # # Define status worker # worker.jkstatus.type=status 5. Edit Tomcat-install-folder\conf\server.xml to allow localhost on port 8009 by adding address=127.0.0.1: !-- Define an AJP 1.3 Connector on port 8009 -- Connector port=8009 address=127.0.0.1 enableLookups=false redirectPort=8443 protocol=AJP/1.3 6. Open IIS Manager: a. In the left pane, Under Server node Sites Default Web Site select Add Virtual Directory node. b. Type jakarta in the Alias text box.and specify the location of the isapi_redirect.dll file in the Physical path. c. Under Default Web Site, double-click on ISAPI Filters. d. In ISAPI Filters window, right-click and select Add button, give Jakarta as the filter name. e. Click Browse, select the isapi_redirect.dll and click OK. f. Click OK 7. Under Default Host name, Double-click ISAPI CGI Restrictions: a. In the ISAPI and CGI Restrictions window, right-click and select Add. b. Click Browse and select isapi_redirect.dll. c. Provide Jakarta in the Description text box. d. Select Allow extension path to execute option and click OK. 8. Under Default Web Site, select the virtual directory Jakarta: a. In the right pane, double-click Handler Mappings. b. In the Handler Mappings window, right-click and select Edit Features Permissions. c. Select the Execute checkbox and click OK. 9. Stop Tomcat 10. Restart IIS 11. Start Tomcat To test the connector: From a supported browser, enter the following URL: https://localhost/tomcat-docs The Apache Tomcat Documentation page is displayed. Now following this steps I get: Error Summary HTTP Error 500.0 - Internal Server Error The page cannot be displayed because an internal server error has occurred. Detailed Error Information Module IsapiFilterModule NotificationAuthenticateRequest Handler StaticFile Error Code 0x80070001 Requested URL https://localhost:443/docs/ Physical Path C:\inetpub\wwwroot\docs\ Logon MethodAnonymous Logon User Anonymous Any suggestions? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 5.5 IIS 7.5 2008 64bit
On 03/12/2012 05:37 PM, Bradford Matthews wrote: Here is my steps that I used to install tomcat isapi connector. 5. EditTomcat-install-folder\conf\server.xml to allow localhost on port 8009 by adding address=127.0.0.1: !-- Define an AJP 1.3 Connector on port 8009 -- Connector port=8009 address=127.0.0.1 enableLookups=false redirectPort=8443 protocol=AJP/1.3 To test the connector: From a supported browser, enter the following URL: https://localhost/tomcat-docs The Apache Tomcat Documentation page is displayed. Requested URL https://localhost:443/docs/ Any suggestions? Seems you are requesting this over ssl so you will probably need to add scheme=https to the AJP/1.3 connector Regards -- ^TM - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 5.5 JDK version compatibility
Hi all, I have a question about a comment on this bug report: https://issues.apache.org/bugzilla/show_bug.cgi?id=52545 Mark Thomas noted that: The application can not be compiled using a 1.4 JDK (the minimum Java version required by Servlet 2.4) since it uses annotations. While applications may be compiled with a later Java version, they must be compilable with the minimum Java version. I just want to make sure I'm understanding this correctly. Does this mean that if a web application is deployed in Tomcat 5.5, it may not use any language features that were introduced in J2SE 5.0 or later (e.g. annotations and generics), even if those features are supported by the JRE? I looked through both the servlet 2.4 specification and Tomcat's documentation and couldn't find anywhere this was documented, but I may have missed something. Thanks, -- David - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 5.5 JDK version compatibility
From: David Wahler [mailto:dwah...@indeed.com] Subject: Tomcat 5.5 JDK version compatibility Does this mean that if a web application is deployed in Tomcat 5.5, it may not use any language features that were introduced in J2SE 5.0 or later (e.g. annotations and generics), even if those features are supported by the JRE? It's not the JRE that's the issue, it's the servlet spec version that your webapp is claiming compliance with. Annotations don't appear there until 2.5 (if I remember correctly). Generics will likely work, because there's nothing in the servlet spec related to those. - 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: Tomcat 5.5 JDK version compatibility
On Thu, Mar 8, 2012 at 12:58 PM, Caldarale, Charles R chuck.caldar...@unisys.com wrote: From: David Wahler [mailto:dwah...@indeed.com] Subject: Tomcat 5.5 JDK version compatibility Does this mean that if a web application is deployed in Tomcat 5.5, it may not use any language features that were introduced in J2SE 5.0 or later (e.g. annotations and generics), even if those features are supported by the JRE? It's not the JRE that's the issue, it's the servlet spec version that your webapp is claiming compliance with. Annotations don't appear there until 2.5 (if I remember correctly). Generics will likely work, because there's nothing in the servlet spec related to those. True, neither annotations nor generics are mentioned in the servlet 2.4 spec, but both are supported at the language level by JRE/JDK 5 and up. In particular, my test case refers to @javax.annotation.Resource, which is part of J2SE 6 and understood by dependency-injection frameworks like Spring and Guice. But as per Servlet 2.5, that annotation is also interpreted by Tomcat 7 and used to inject JNDI dependencies. My expectation was that Tomcat's annotation processing would only happen if web.xml referred to version 2.5 of the spec or later. Hence the question: does the fact that annotations are a Java 5 feature automatically make a webapp that uses them non-compliant with servlet spec 2.4? (Mark seems to be assuming that I compiled my test case against Tomcat 7 APIs and then tried to deploy the resulting app with Tomcat 5.5, which isn't the case.) -- David - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 5.5 JDK version compatibility
2012/3/8 David Wahler dwah...@indeed.com: Hi all, I have a question about a comment on this bug report: https://issues.apache.org/bugzilla/show_bug.cgi?id=52545 Mark Thomas noted that: The application can not be compiled using a 1.4 JDK (the minimum Java version required by Servlet 2.4) since it uses annotations. While applications may be compiled with a later Java version, they must be compilable with the minimum Java version. I just want to make sure I'm understanding this correctly. Does this mean that if a web application is deployed in Tomcat 5.5, it may not use any language features that were introduced in J2SE 5.0 or later (e.g. annotations and generics), even if those features are supported by the JRE? I looked through both the servlet 2.4 specification and Tomcat's documentation and couldn't find anywhere this was documented, but I may have missed something. I would say that it is just useless exercise to mark application as 2.4 but rely on newer features in it. The issue of servlet 2.4 compatibility is that you have some old application that you want to run as is on newer Tomcat. The javax.annotation.Resource class is part of annotations-api.jar which is not present in Tomcat 5.5. So a person is not able to compile your application if he uses correct Servlet Specification JARs. Just open a text editor and edit your web.xml so that it specifies the correct version. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 5.5 JDK version compatibility
On 08/03/2012 19:33, David Wahler wrote: On Thu, Mar 8, 2012 at 12:58 PM, Caldarale, Charles R chuck.caldar...@unisys.com wrote: From: David Wahler [mailto:dwah...@indeed.com] Subject: Tomcat 5.5 JDK version compatibility Does this mean that if a web application is deployed in Tomcat 5.5, it may not use any language features that were introduced in J2SE 5.0 or later (e.g. annotations and generics), even if those features are supported by the JRE? It means that *if* you do that, you run the risk that your application that claims to be a Servlet 2.4 application will not run on a specification compliant Servlet 2.4 container. Therefore, your application is not specification complaint. You can compile with a later JRE and take advantage of features available in the newer JRE version but you then place additional restrictions on the JRE that the container can use over and above those defined in the specification. It's not the JRE that's the issue, it's the servlet spec version that your webapp is claiming compliance with. Annotations don't appear there until 2.5 (if I remember correctly). Generics will likely work, because there's nothing in the servlet spec related to those. True, neither annotations nor generics are mentioned in the servlet 2.4 spec, but both are supported at the language level by JRE/JDK 5 and up. In particular, my test case refers to @javax.annotation.Resource, which is part of J2SE 6 and understood by dependency-injection frameworks like Spring and Guice. But as per Servlet 2.5, that annotation is also interpreted by Tomcat 7 and used to inject JNDI dependencies. My expectation was that Tomcat's annotation processing would only happen if web.xml referred to version 2.5 of the spec or later. Hence the question: does the fact that annotations are a Java 5 feature automatically make a webapp that uses them non-compliant with servlet spec 2.4? (Mark seems to be assuming that I compiled my test case against Tomcat 7 APIs and then tried to deploy the resulting app with Tomcat 5.5, which isn't the case.) There is no way you compiled an application that uses javax.annotation.Resource against the Servlet 2.4 / Java EE 1.4 API. If you try that you'll get an error. If you compile against a later API, claim to use an older API and then run on a container that supports the later API then you should expect some odd behaviour and that is exactly what you got. Tomcat is never going to add the necessary checking to prevent this because of the overhead it adds to fix what is a build time issue. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 5.5 JDK version compatibility
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David, On 3/8/12 2:33 PM, David Wahler wrote: On Thu, Mar 8, 2012 at 12:58 PM, Caldarale, Charles R chuck.caldar...@unisys.com wrote: From: David Wahler [mailto:dwah...@indeed.com] Subject: Tomcat 5.5 JDK version compatibility Does this mean that if a web application is deployed in Tomcat 5.5, it may not use any language features that were introduced in J2SE 5.0 or later (e.g. annotations and generics), even if those features are supported by the JRE? It's not the JRE that's the issue, it's the servlet spec version that your webapp is claiming compliance with. Annotations don't appear there until 2.5 (if I remember correctly). Generics will likely work, because there's nothing in the servlet spec related to those. True, neither annotations nor generics are mentioned in the servlet 2.4 spec, but both are supported at the language level by JRE/JDK 5 and up. In particular, my test case refers to @javax.annotation.Resource, which is part of J2SE 6 and understood by dependency-injection frameworks like Spring and Guice. But as per Servlet 2.5, that annotation is also interpreted by Tomcat 7 and used to inject JNDI dependencies. My expectation was that Tomcat's annotation processing would only happen if web.xml referred to version 2.5 of the spec or later. Hence the question: does the fact that annotations are a Java 5 feature automatically make a webapp that uses them non-compliant with servlet spec 2.4? (Mark seems to be assuming that I compiled my test case against Tomcat 7 APIs and then tried to deploy the resulting app with Tomcat 5.5, which isn't the case.) Without further specifics, I would agree with you: if your webapp says it's 2.4-spec, then no annotation processing should occur (at least by Tomcat: Spring, etc. is free to process annotations). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9ZEggACgkQ9CaO5/Lv0PCNagCfRwlwZtaNfCTVo9IbYZfhouCy HyUAn22/b5YgHey6hwWBpZvb0DKBWKpx =FgjU -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 5.5 JDK version compatibility
On Thu, Mar 8, 2012 at 1:59 PM, Mark Thomas ma...@apache.org wrote: There is no way you compiled an application that uses javax.annotation.Resource against the Servlet 2.4 / Java EE 1.4 API. If you try that you'll get an error. As I said, javax.annotation.Resource is included with J2SE 6 (as specified in JSR-250, Common Annotations for the Java(tm) Platform). http://docs.oracle.com/javase/6/docs/api/javax/annotation/Resource.html So the code I posted compiles just fine under Java 6 with the Tomcat 5.5 APIs. If you compile against a later API, claim to use an older API and then run on a container that supports the later API then you should expect some odd behaviour and that is exactly what you got. Tomcat is never going to add the necessary checking to prevent this because of the overhead it adds to fix what is a build time issue. Fair enough. Thanks, -- David - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 5.5 JDK version compatibility
On 08/03/2012 20:10, David Wahler wrote: On Thu, Mar 8, 2012 at 1:59 PM, Mark Thomas ma...@apache.org wrote: There is no way you compiled an application that uses javax.annotation.Resource against the Servlet 2.4 / Java EE 1.4 API. If you try that you'll get an error. As I said, javax.annotation.Resource is included with J2SE 6 (as specified in JSR-250, Common Annotations for the Java(tm) Platform). http://docs.oracle.com/javase/6/docs/api/javax/annotation/Resource.html So the code I posted compiles just fine under Java 6 with the Tomcat 5.5 APIs. Sorry, I had missed that someone in their infinite wisdom decided to move classes from JavaEE to JavaSE. That is certainly a recipe for a screw-up. Looking at the JavaSE 6 Javadoc it refers to containers everywhere which suggests to me that this should have stayed in the JavaEE space since the concept of a container is very much a JavaEE concept. Unfortunately, that genie can't be put back in the bottle. This changes my analysis but not the end result. Behaviour of those JavaSE language features are undefined in Servlet 2.4 since they didn't exist when it was written. Reading the JavaSE 6 javadoc certainly suggests that they should be processed. On the other hand, from a Servlet spec point of view they weren't introduced until 2.5. I could construct an argument to do either. Given that not processing them is going to be very messy, I don't see the Tomcat code changing. Returning to an earlier point, if you want to write a 2.4 web application and be sure that that is what you have, then you really need to make sure that is compiles against JavaEE 1.4 using Java 1.4. That doesn't have to be your standard build environment but it should probably be a CI test somewhere. Mark If you compile against a later API, claim to use an older API and then run on a container that supports the later API then you should expect some odd behaviour and that is exactly what you got. Tomcat is never going to add the necessary checking to prevent this because of the overhead it adds to fix what is a build time issue. Fair enough. Thanks, -- David - 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: migrating Tomcat 5.5 SSL Connector to 7.0
There's been one request for follow up so I'll post our current findings. This is what we've identified that we need to do to get Tomcat running after moving from 5.5 to 7.0. At this point web application porting can commence. 1. We used several Tomcat classes (e.g. EndPoint, ServerSocketFactory) Application code had to be ported. 2. We chose Tomcat 7.0.23 so the attribute 'sslImplementationName' is spelled correctly. 3. In our SSL Implementation - public ServerSocketFactory getServerSocketFactory() + public ServerSocketFactory getServerSocketFactory(AbstractEndpoint) 4. In our ServerSocketFactoryImplementation - public class BrightmailServerSocketFactory extends ServerSocketFactory + public class BrightmailServerSocketFactory implements ServerSocketFactory Plus appropriate porting since ServerSocketFactory is an interface in 7.0 5. To initialize FIPS mode, we used to kick that off in our security listener at Lifecyle.INIT_EVENT, but in 7.0 INIT_EVENT is deprecated and we use Lifecycle.AFTER_INIT_EVENT Example in server.xml: Listener className=your.class.here.SecurityProviderSetup/Listener 6. Connector element was correct in OP, but needed steps 1-5 previous. 7. In catalina properties we moved our security classes to the common classloader. 8. set org.apache.jasper.compiler.Parser.STRICT_QUOTE_ESCAPING=false or else we have to escape every instance of double quote in every jsp ever. Clearly jsps should be reviewed. 9. In application web.xml add jsp-config around taglib elements. 10. The best way to create server.xml and web.xml was to take the default files as starting points and add application specific settings piece by piece. On 1/6/12 4:38 PM, ma...@apache.org ma...@apache.org wrote: Mark Lim mark_...@symantec.com wrote: It seems that tomcat is trying the default JSSE implementation despite the sslImplementationName attribute being set. Are there internal precedence controls or does the classloader hierarchy matter or what? No, but what makes you assume what you are trying will work? You have two options. 1. Configure the JSSE implementation to be used at the JVM. 2. Write a wrapper along the lines of the default one used in 7.0.x but for the custom JSSE implementation you are using and then specify that in the connector. Mark - 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: [OT] migrating Tomcat 5.5 SSL Connector to 7.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark, On 1/6/12 7:05 PM, Mark Lim wrote: We are in the process of upgrading Tomcat 5.5 to Tomcat 7.0. These Tomcat deployments use a custom FIPS 140-2 certified JSSE implementation for their SSL Connectors. In case you are interested, Tomcats 7.0.23 and 6.0.36 (along with tcnative 1.1.23) are capable of going into FIPS-mode with an appropriately-build openssl. If such things interest you, please let me know and we can help you get set up. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk85gbsACgkQ9CaO5/Lv0PD9tgCgqcXtTAmZ4nzQwf5+AIrU3b2S cMMAn1O+S7qghZWFKUxE0riI4CHV6IQb =FHSn -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] migrating Tomcat 5.5 SSL Connector to 7.0
Thanks for offering, but we're already in certification. When recertification comes up we'll certainly consider consolidating security modules. On 2/13/12 1:33 PM, Christopher Schultz ch...@christopherschultz.net wrote: * PGP Signed by an unknown key Mark, On 1/6/12 7:05 PM, Mark Lim wrote: We are in the process of upgrading Tomcat 5.5 to Tomcat 7.0. These Tomcat deployments use a custom FIPS 140-2 certified JSSE implementation for their SSL Connectors. In case you are interested, Tomcats 7.0.23 and 6.0.36 (along with tcnative 1.1.23) are capable of going into FIPS-mode with an appropriately-build openssl. If such things interest you, please let me know and we can help you get set up. -chris * Unknown Key * 0xF2EFD0F0(L) - 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: [OT] migrating Tomcat 5.5 SSL Connector to 7.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark, On 2/13/12 4:45 PM, Mark Lim wrote: Thanks for offering, but we're already in certification. When recertification comes up we'll certainly consider consolidating security modules. Okay. Well, if you're willing to put our code into testing, it would give us some good data points. We essentially applied a heavily-modified set of patches from a contributor who was using an old version and kind of hacked it together. I cleaned it up and committed it to Tomcat and tcnative, but I don't have a good environment in which to test it: all I can verify is that OpenSSL appears to have gone into FIPS mode and didn't complain. If you have a battery of tests you could run against it, it would be very helpful just to validate the work done thus far. Alternatively, if you have some kind of test suite that could be used, I wouldn't mind performing the actual testing myself. Thanks, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk85h08ACgkQ9CaO5/Lv0PDLZACeLn6fY2TGzuflkK5wtgEzau8D ybkAoIHxmYzgGAtXUna9NGc41yK3P9ow =7b+d -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
migrating Tomcat 5.5 SSL Connector to 7.0
We are in the process of upgrading Tomcat 5.5 to Tomcat 7.0. These Tomcat deployments use a custom FIPS 140-2 certified JSSE implementation for their SSL Connectors. In Tomcat 5.5, the Connectors are configured like this: !-- Define a SSL Coyote HTTP/1.1 Connector on port specified by the installer (default 41443) -- Connector port=41443 minProcessors=5 maxProcessors=75 enableLookups=true disableUploadTimeout=true redirectPort=41443 acceptCount=100 debug=0 scheme=https secure=true connectionTimeout=6 useURIValidationHack=false clientAuth=false sslProtocol=SSLv2Hello,TLSv1 ciphers=TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA keystorePass=symantec keystoreFile=/data/bcc/conf/keystore SSLImplementation=com.symantec.smg.controlcenter.internal.security.ssl.BrightmailSSLImplementation / which works fine. ( a listener appears on 41443 and one can do HTTPS to it) In Tomcat 7.0.23 we are trying to use !-- Define a SSL Coyote HTTP/1.1 Connector on port specified by the installer (default 41443) -- Connector port=41443 enableLookups=true disableUploadTimeout=true redirectPort=41443 acceptCount=100 scheme=https secure=true connectionTimeout=6 clientAuth=false sslProtocol=SSLv2Hello,TLSv1 ciphers=TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA keystorePass=symantec keystoreFile=/data/bcc/conf/keystore sslImplementationName=com.symantec.smg.controlcenter.internal.security.ssl.BrightmailSSLImplementation SSLEnabled=true/ but this does not work (no listener appears on 41443) and catalina.out has this: Jan 6, 2012 8:09:14 AM org.apache.catalina.core.StandardService initInternal SEVERE: Failed to initialize connector [Connector[HTTP/1.1-41443]]org.apache.catalina.LifecycleException: Failed to initialize component [Connector[HTTP/1.1-41443]] at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:106) at org.apache.catalina.core.StandardService.initInternal(StandardService .java:559) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102) at org.apache.catalina.core.StandardServer.initInternal(StandardServer.j ava:781) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102) at org.apache.catalina.startup.Catalina.load(Catalina.java:573) at org.apache.catalina.startup.Catalina.load(Catalina.java:598) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:281) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:449) Caused by: org.apache.catalina.LifecycleException: Protocol handler initializati on failed at org.apache.catalina.connector.Connector.initInternal(Connector.java:9 39) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102) ... 12 more Caused by: java.io.IOException: SSLv2Hello,TLSv1 SSLContext not available at org.apache.tomcat.util.net.jsse.JSSESocketFactory.init(JSSESocketFactory.java:475) at org.apache.tomcat.util.net.jsse.JSSESocketFactory.createSocket(JSSESocketFactory.java:158) at org.apache.tomcat.util.net.JIoEndpoint.bind(JIoEndpoint.java:369) at org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:553) at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:369) at org.apache.coyote.http11.AbstractHttp11JsseProtocol.init(AbstractHttp11JsseProtocol.java:119) at org.apache.catalina.connector.Connector.initInternal(Connector.java:9 37) ... 13 more Caused by: java.security.NoSuchAlgorithmException: SSLv2Hello,TLSv1 SSLContext n ot available at sun.security.jca.GetInstance.getInstance(Unknown Source) at javax.net.ssl.SSLContext.getInstance(Unknown Source) at org.apache.tomcat.util.net.jsse.JSSESocketFactory.createSSLContext(JS SESocketFactory.java:488)at org.apache.tomcat.util.net.jsse.JSSESocketFactory.init(JSSESocketFactory.java:448) ... 19 more It seems that tomcat is trying the default JSSE implementation despite the sslImplementationName attribute being set. Are there internal precedence controls or does the classloader hierarchy
Re: migrating Tomcat 5.5 SSL Connector to 7.0
Mark Lim mark_...@symantec.com wrote: It seems that tomcat is trying the default JSSE implementation despite the sslImplementationName attribute being set. Are there internal precedence controls or does the classloader hierarchy matter or what? No, but what makes you assume what you are trying will work? You have two options. 1. Configure the JSSE implementation to be used at the JVM. 2. Write a wrapper along the lines of the default one used in 7.0.x but for the custom JSSE implementation you are using and then specify that in the connector. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 5.5 crashes after changing server IP
On 12/12/2011 00:29, sir...@8host.pl wrote:
One more log:
2011-12-12 00:52:15 org.apache.catalina.core.AprLifecycleListener init
INFO: The APR based Apache Tomcat Native library which allows optimal
performance in production environments was not found on the
java.library.path:
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server:/usr/lib/jvm/java-1$
2011-12-12 00:52:16 org.apache.tomcat.util.digester.Digester endElement
WARNING: No rules found matching 'Server/Service/Context'.
You can't define a Context directly under Service in server.xml, it must
be inside a Host.
You should avoid defining the Context in server.xml at all. Instead,
put it in 'torun/META-INF/context.xml'
2011-12-12 00:52:16 org.apache.tomcat.util.digester.SetPropertiesRule begin
WARNING: [SetPropertiesRule]{Server/Service/Engine/Host} Setting
property 'debug' to '0' did not find a matching property.
There is no debug property on Host.
2011-12-12 00:52:16 org.apache.tomcat.util.digester.SetPropertiesRule begin
WARNING: [SetPropertiesRule]{Server/Service/Engine/Host/Context} Setting
property 'debug' to '0' did not find a matching property.
There is no debug property on Context.
2011-12-12 00:52:16 org.apache.coyote.http11.Http11Protocol init
INFO: Initializing Coyote HTTP/1.1 on http-8080
2011-12-12 00:52:16 org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 1020 ms
2011-12-12 00:52:16 org.apache.catalina.core.StandardService start
INFO: Starting service Catalina
2011-12-12 00:52:16 org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/6.0.32
2011-12-12 00:52:17 org.apache.catalina.loader.WebappClassLoader
validateJarFile
INFO: validateJarFile(/var/www/torun/WEB-INF/lib/servletapi-2.2.jar) -
jar not loaded. See Servlet Spec 2.3, section 9.7.2. Offending class:
javax/servlet/Servlet.class
You have a JAR in your application that you should not have.
If you have published /var/www/ (or /var/www/torun) as an Apache HTTPD
DocumentRoot you are increasing the risk of exposing data that should be
protected, because Apache HTTPD will bypass Tomcat controls.
2011-12-12 00:52:18 org.apache.catalina.startup.HostConfig deployDescriptor
INFO: Deploying configuration descriptor host-manager.xml
2011-12-12 00:52:18 org.apache.catalina.startup.HostConfig deployDescriptor
INFO: Deploying configuration descriptor manager.xml
2011-12-12 00:52:18 org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deploying web application directory docs
2011-12-12 00:52:18 org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deploying web application directory ROOT
2011-12-12 00:52:18 org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deploying web application directory examples
2011-12-12 00:52:18 org.apache.coyote.http11.Http11Protocol start
INFO: Starting Coyote HTTP/1.1 on http-8080
2011-12-12 00:52:18 org.apache.jk.common.ChannelSocket init
INFO: JK: ajp13 listening on /0.0.0.0:8009
2011-12-12 00:52:18 org.apache.jk.server.JkMain start
INFO: Jk running ID=0 time=0/10 config=null
2011-12-12 00:52:18 org.apache.catalina.startup.Catalina start
INFO: Server startup in 1976 ms
2011-12-12 00:53:09 org.apache.coyote.http11.Http11Protocol pause
INFO: Pausing Coyote HTTP/1.1 on http-8080
2011-12-12 00:53:10 org.apache.catalina.core.StandardService stop
INFO: Stopping service Catalina
This looks like a normal stop.
2011-12-12 00:53:10 org.apache.catalina.core.StandardWrapper unload
INFO: Waiting for 1 instance(s) to be deallocated
2011-12-12 00:53:11 org.apache.catalina.core.StandardWrapper unload
INFO: Waiting for 1 instance(s) to be deallocated
2011-12-12 00:53:12 org.apache.catalina.core.StandardWrapper unload
INFO: Waiting for 1 instance(s) to be deallocated
2011-12-12 00:53:12 org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads
SEVERE: The web application [] is still processing a request that has
yet to finish. This is very likely to create a memory leak. You can
control the time allowed for requests to finish by using the unloadDelay
attribute of the standard$
2011-12-12 00:53:12 org.apache.coyote.http11.Http11Protocol destroy
INFO: Stopping Coyote HTTP/1.1 on http-8080
A request was taking a long time to process was still running when the
server stopped.
It is probly Tomcat + Xen (KVM) + Intel (?) releted problem.
I really have no idea how you come to that conclusion.
I install
tomcat from 5 to 7 on diferent VPS's, always have the same result but
always i have Xen or KVM and Intel CPU, old serwer has AMD cpu and all
works great (and some older version of Xen also), but on new Xen or KVM
based VPS i always have the same problem. But when i run XEN machine
with Windows 8 and run on it VirtuaBox and starts new 32 bit CentOS all
work great (but i have virtualization on virtualized machine ;) ). Its
realy strange problem, and have no idea how to solve it.
Fix one
Re: Tomcat 5.5 crashes after changing server IP
It is probly Tomcat + Xen (KVM) + Intel (?) releted problem.
I really have no idea how you come to that conclusion.
Like i said when i install Windows 8 on Xen machine, starts Virtuabox
on it and new 32bit Centos, tomcat and my api works perfectly. It was
running for a 2 years on AMD procesor (with the same config files) and
it works like charm also. Problem starts when we switch to new Intel
machine. I also try to install the same version of xen on AMD server and
it works, that only dont work on xen or kvm. Also i dowload whole Xen
disk image and run it on different intel procesor on virtuabox (Windoiws
7) and the same error. Its realy strange situation when i have to
virtualize 2 systems to make it work ;). When i convert working
virtuabox machine to Xen image, i have the same error.
I install
tomcat from 5 to 7 on diferent VPS's, always have the same result
but
always i have Xen or KVM and Intel CPU, old serwer has AMD cpu and
all
works great (and some older version of Xen also), but on new Xen or
KVM
based VPS i always have the same problem. But when i run XEN machine
with Windows 8 and run on it VirtuaBox and starts new 32 bit CentOS
all
work great (but i have virtualization on virtualized machine ;) ).
Its
realy strange problem, and have no idea how to solve it.
Fix one thing at a time. Start with your config.
It was log from oryginal Tomcat instalation, on new install we have
only AJP stops and Memory Leak.
Best wishes
Marcin
On 12.12.2011 09:03, Pid wrote:
On 12/12/2011 00:29, sir...@8host.pl wrote:
One more log:
2011-12-12 00:52:15 org.apache.catalina.core.AprLifecycleListener
init
INFO: The APR based Apache Tomcat Native library which allows
optimal
performance in production environments was not found on the
java.library.path:
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server:/usr/lib/jvm/java-1$
2011-12-12 00:52:16 org.apache.tomcat.util.digester.Digester
endElement
WARNING: No rules found matching 'Server/Service/Context'.
You can't define a Context directly under Service in server.xml, it
must
be inside a Host.
You should avoid defining the Context in server.xml at all. Instead,
put it in 'torun/META-INF/context.xml'
2011-12-12 00:52:16
org.apache.tomcat.util.digester.SetPropertiesRule begin
WARNING: [SetPropertiesRule]{Server/Service/Engine/Host} Setting
property 'debug' to '0' did not find a matching property.
There is no debug property on Host.
2011-12-12 00:52:16
org.apache.tomcat.util.digester.SetPropertiesRule begin
WARNING: [SetPropertiesRule]{Server/Service/Engine/Host/Context}
Setting
property 'debug' to '0' did not find a matching property.
There is no debug property on Context.
2011-12-12 00:52:16 org.apache.coyote.http11.Http11Protocol init
INFO: Initializing Coyote HTTP/1.1 on http-8080
2011-12-12 00:52:16 org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 1020 ms
2011-12-12 00:52:16 org.apache.catalina.core.StandardService start
INFO: Starting service Catalina
2011-12-12 00:52:16 org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/6.0.32
2011-12-12 00:52:17 org.apache.catalina.loader.WebappClassLoader
validateJarFile
INFO: validateJarFile(/var/www/torun/WEB-INF/lib/servletapi-2.2.jar)
-
jar not loaded. See Servlet Spec 2.3, section 9.7.2. Offending
class:
javax/servlet/Servlet.class
You have a JAR in your application that you should not have.
If you have published /var/www/ (or /var/www/torun) as an Apache
HTTPD
DocumentRoot you are increasing the risk of exposing data that should
be
protected, because Apache HTTPD will bypass Tomcat controls.
2011-12-12 00:52:18 org.apache.catalina.startup.HostConfig
deployDescriptor
INFO: Deploying configuration descriptor host-manager.xml
2011-12-12 00:52:18 org.apache.catalina.startup.HostConfig
deployDescriptor
INFO: Deploying configuration descriptor manager.xml
2011-12-12 00:52:18 org.apache.catalina.startup.HostConfig
deployDirectory
INFO: Deploying web application directory docs
2011-12-12 00:52:18 org.apache.catalina.startup.HostConfig
deployDirectory
INFO: Deploying web application directory ROOT
2011-12-12 00:52:18 org.apache.catalina.startup.HostConfig
deployDirectory
INFO: Deploying web application directory examples
2011-12-12 00:52:18 org.apache.coyote.http11.Http11Protocol start
INFO: Starting Coyote HTTP/1.1 on http-8080
2011-12-12 00:52:18 org.apache.jk.common.ChannelSocket init
INFO: JK: ajp13 listening on /0.0.0.0:8009
2011-12-12 00:52:18 org.apache.jk.server.JkMain start
INFO: Jk running ID=0 time=0/10 config=null
2011-12-12 00:52:18 org.apache.catalina.startup.Catalina start
INFO: Server startup in 1976 ms
2011-12-12 00:53:09 org.apache.coyote.http11.Http11Protocol pause
INFO: Pausing Coyote HTTP/1.1 on http-8080
2011-12-12 00:53:10 org.apache.catalina.core.StandardService stop
INFO: Stopping service Catalina
This looks like a normal stop.
2011-12-12
Re: Tomcat 5.5 crashes after changing server IP
sir...@8host.pl wrote: It is probly Tomcat + Xen (KVM) + Intel (?) releted problem. I really have no idea how you come to that conclusion. Like i said when i install Windows 8 on Xen machine, starts Virtuabox on it and new 32bit Centos, tomcat and my api works perfectly. It was running for a 2 years on AMD procesor (with the same config files) and it works like charm also. Problem starts when we switch to new Intel machine. I also try to install the same version of xen on AMD server and it works, that only dont work on xen or kvm. Also i dowload whole Xen disk image and run it on different intel procesor on virtuabox (Windoiws 7) and the same error. Its realy strange situation when i have to virtualize 2 systems to make it work ;). When i convert working virtuabox machine to Xen image, i have the same error. It seems really unclear what all of this has to do with Tomcat. Tomcat is Java code. It runs under a JVM, and uses that JVM's code for anything to do with the interface to the underlying OS or hardware. So it should not make an iota of difference to Tomcat under which OS and machine it is running. On the other hand, the /JVM/ which you are using may have problems, but again that has nothing to do fundamentally with Tomcat. I install tomcat from 5 to 7 on diferent VPS's, always have the same result but always i have Xen or KVM and Intel CPU, old serwer has AMD cpu and all works great (and some older version of Xen also), but on new Xen or KVM based VPS i always have the same problem. But when i run XEN machine with Windows 8 and run on it VirtuaBox and starts new 32 bit CentOS all work great (but i have virtualization on virtualized machine ;) ). Its realy strange problem, and have no idea how to solve it. Fix one thing at a time. Start with your config. It was log from oryginal Tomcat instalation, on new install we have only AJP stops and Memory Leak. Then provide the new log, or do you just want us to keep guessing ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 5.5 crashes after changing server IP
On 12/12/2011 12:02, André Warnier wrote: sir...@8host.pl wrote: It is probly Tomcat + Xen (KVM) + Intel (?) releted problem. I really have no idea how you come to that conclusion. Like i said when i install Windows 8 on Xen machine, starts Virtuabox on it and new 32bit Centos, tomcat and my api works perfectly. It was running for a 2 years on AMD procesor (with the same config files) and it works like charm also. Problem starts when we switch to new Intel machine. I also try to install the same version of xen on AMD server and it works, that only dont work on xen or kvm. Also i dowload whole Xen disk image and run it on different intel procesor on virtuabox (Windoiws 7) and the same error. Its realy strange situation when i have to virtualize 2 systems to make it work ;). When i convert working virtuabox machine to Xen image, i have the same error. Correlation != causation Have you fixed the other errors in your config? p It seems really unclear what all of this has to do with Tomcat. Tomcat is Java code. It runs under a JVM, and uses that JVM's code for anything to do with the interface to the underlying OS or hardware. So it should not make an iota of difference to Tomcat under which OS and machine it is running. On the other hand, the /JVM/ which you are using may have problems, but again that has nothing to do fundamentally with Tomcat. I install tomcat from 5 to 7 on diferent VPS's, always have the same result but always i have Xen or KVM and Intel CPU, old serwer has AMD cpu and all works great (and some older version of Xen also), but on new Xen or KVM based VPS i always have the same problem. But when i run XEN machine with Windows 8 and run on it VirtuaBox and starts new 32 bit CentOS all work great (but i have virtualization on virtualized machine ;) ). Its realy strange problem, and have no idea how to solve it. Fix one thing at a time. Start with your config. It was log from oryginal Tomcat instalation, on new install we have only AJP stops and Memory Leak. Then provide the new log, or do you just want us to keep guessing ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- [key:62590808] signature.asc Description: OpenPGP digital signature
Re: Tomcat 5.5 crashes after changing server IP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 SirWiz, On 12/12/11 6:26 AM, sir...@8host.pl wrote: It is probly Tomcat + Xen (KVM) + Intel (?) releted problem. I really have no idea how you come to that conclusion. Like i said when i install Windows 8 on Xen machine, starts Virtuabox on it and new 32bit Centos, tomcat and my api works perfectly. It was running for a 2 years on AMD procesor (with the same config files) and it works like charm also. So, you are running a doubly-virtualized environment? That seems ... unnecessary. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7mXugACgkQ9CaO5/Lv0PCMSQCfd71oa1BjWJMrj3nmPC5lo3SL wbYAoKz4/5McJD6sw7dWkDxzJOaM+cO/ =vdWF -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 5.5 crashes after changing server IP
One more log:
2011-12-12 00:52:15 org.apache.catalina.core.AprLifecycleListener init
INFO: The APR based Apache Tomcat Native library which allows optimal
performance in production environments was not found on the
java.library.path:
/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server:/usr/lib/jvm/java-1$
2011-12-12 00:52:16 org.apache.tomcat.util.digester.Digester endElement
WARNING: No rules found matching 'Server/Service/Context'.
2011-12-12 00:52:16 org.apache.tomcat.util.digester.SetPropertiesRule
begin
WARNING: [SetPropertiesRule]{Server/Service/Engine/Host} Setting
property 'debug' to '0' did not find a matching property.
2011-12-12 00:52:16 org.apache.tomcat.util.digester.SetPropertiesRule
begin
WARNING: [SetPropertiesRule]{Server/Service/Engine/Host/Context}
Setting property 'debug' to '0' did not find a matching property.
2011-12-12 00:52:16 org.apache.coyote.http11.Http11Protocol init
INFO: Initializing Coyote HTTP/1.1 on http-8080
2011-12-12 00:52:16 org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 1020 ms
2011-12-12 00:52:16 org.apache.catalina.core.StandardService start
INFO: Starting service Catalina
2011-12-12 00:52:16 org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/6.0.32
2011-12-12 00:52:17 org.apache.catalina.loader.WebappClassLoader
validateJarFile
INFO: validateJarFile(/var/www/torun/WEB-INF/lib/servletapi-2.2.jar) -
jar not loaded. See Servlet Spec 2.3, section 9.7.2. Offending class:
javax/servlet/Servlet.class
2011-12-12 00:52:18 org.apache.catalina.startup.HostConfig
deployDescriptor
INFO: Deploying configuration descriptor host-manager.xml
2011-12-12 00:52:18 org.apache.catalina.startup.HostConfig
deployDescriptor
INFO: Deploying configuration descriptor manager.xml
2011-12-12 00:52:18 org.apache.catalina.startup.HostConfig
deployDirectory
INFO: Deploying web application directory docs
2011-12-12 00:52:18 org.apache.catalina.startup.HostConfig
deployDirectory
INFO: Deploying web application directory ROOT
2011-12-12 00:52:18 org.apache.catalina.startup.HostConfig
deployDirectory
INFO: Deploying web application directory examples
2011-12-12 00:52:18 org.apache.coyote.http11.Http11Protocol start
INFO: Starting Coyote HTTP/1.1 on http-8080
2011-12-12 00:52:18 org.apache.jk.common.ChannelSocket init
INFO: JK: ajp13 listening on /0.0.0.0:8009
2011-12-12 00:52:18 org.apache.jk.server.JkMain start
INFO: Jk running ID=0 time=0/10 config=null
2011-12-12 00:52:18 org.apache.catalina.startup.Catalina start
INFO: Server startup in 1976 ms
2011-12-12 00:53:09 org.apache.coyote.http11.Http11Protocol pause
INFO: Pausing Coyote HTTP/1.1 on http-8080
2011-12-12 00:53:10 org.apache.catalina.core.StandardService stop
INFO: Stopping service Catalina
2011-12-12 00:53:10 org.apache.catalina.core.StandardWrapper unload
INFO: Waiting for 1 instance(s) to be deallocated
2011-12-12 00:53:11 org.apache.catalina.core.StandardWrapper unload
INFO: Waiting for 1 instance(s) to be deallocated
2011-12-12 00:53:12 org.apache.catalina.core.StandardWrapper unload
INFO: Waiting for 1 instance(s) to be deallocated
2011-12-12 00:53:12 org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads
SEVERE: The web application [] is still processing a request that has
yet to finish. This is very likely to create a memory leak. You can
control the time allowed for requests to finish by using the unloadDelay
attribute of the standard$
2011-12-12 00:53:12 org.apache.coyote.http11.Http11Protocol destroy
INFO: Stopping Coyote HTTP/1.1 on http-8080
It is probly Tomcat + Xen (KVM) + Intel (?) releted problem. I install
tomcat from 5 to 7 on diferent VPS's, always have the same result but
always i have Xen or KVM and Intel CPU, old serwer has AMD cpu and all
works great (and some older version of Xen also), but on new Xen or KVM
based VPS i always have the same problem. But when i run XEN machine
with Windows 8 and run on it VirtuaBox and starts new 32 bit CentOS all
work great (but i have virtualization on virtualized machine ;) ). Its
realy strange problem, and have no idea how to solve it.
Best wishes,
Marcin
On 29.11.2011 23:05, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sirwiz,
On 11/29/11 11:51 AM, sir...@8host.pl wrote:
I can run tomcat with examples scripts (i just install t 7.0.23)
and i have this error:
2011-11-29 17:38:43 org.apache.coyote.AbstractProtocol start INFO:
Starting ProtocolHandler [http-bio-8080] 2011-11-29 17:38:43
org.apache.coyote.AbstractProtocol start INFO: Starting
ProtocolHandler [ajp-bio-8009] 2011-11-29 17:38:43
org.apache.catalina.startup.Catalina start INFO: Server startup in
645 ms 2011-11-29 17:39:50 org.apache.coyote.AbstractProtocol
pause INFO: Pausing ProtocolHandler [http-bio-8080] 2011-11-29
17:39:50 org.apache.coyote.AbstractProtocol pause INFO: Pausing
ProtocolHandler [ajp-bio-8009] 2011-11-29 17:39:50
