| View previous topic :: View next topic |
| Author |
Message |
lostinspace2011
Apprentice
Joined: 09 Sep 2005
Posts: 230
|
 Posted: Sat Apr 16, 2011 6:36 pm Post subject: Classpath from /etc/conf/tomcat is ignored |
 |
|
I posted a couple of days about this, and did not receive any response. So I started thinking that I might have missed something simple. Since then I did a complete new installation from scratch using the currently available versions of Tomcat 6.0.32-r1 and r2. However the problem still exists.
For some reason tomcat stopped behaving today. I am not quite sure which update caused this or for how long it was not working, but today I noticed that the classpath I set in /etc/conf/tomcat-6 was not being honours. My application relies on JAI being installed and on the classpath. To add JAI onto the classpath I set the following parameters in /etc/conf/tomcat-6. I am beginning to think that the unset CLASSPATH statement in /etc/init.d/tomcat6 is the cause of this problem, yet I do understand it's purpose of cleaning out the CLASSPATH to prevent any libraries present to interfere with the classpath specified for tomcat.
During the rebuilt I
| Code: |
JAVA_OPTS="$JAVA_OPTS -Djava.library.path=$(java-config -i mDNSResponder):$(java-config -i sun-jai-bin)"
...
CATALINA_LIBDIR=/usr/share/tomcat-6/lib/:$(java-config -p sun-jai-bin):$(java-config -p mDNSResponder):$(java-config -p jdbc-postgresql):$(java-config -p log4j):$(java-config -p sun-jaf):$(java-config -p javamail)
|
This used to work some time ago, but for some reason it stopped working. After a fair amount of digging around I found that the /etc/init.d/tomcat-6 script constructed the classpath after unsetting it. This prevented it from including any special customisation. As a quick fix I added the ${CATALINA_LIBDIR} myself as shown in the example below.
| Code: | # Populate the classpath
unset CLASSPATH
CLASSPATH="${CATALINA_HOME}/lib:${JAVA_HOME}/lib/tools.jar"
if [ -n "${JSSE_HOME}" ]; then
CLASSPATH="${CLASSPATH}:${JSSE_HOME}/lib/jcert.jar:${JSSE_HOME}/lib/jnet.jar:${JSSE_HOME}/lib/jsse.jar"
fi
CLASSPATH="${CLASSPATH}:${CATALINA_HOME}/bin/bootstrap.jar:${CATALINA_HOME}/bin/tomcat-juli.jar"
OPTS_CP="${JAVA_OPTS} ${CATALINA_OPTS} -classpath ${CLASSPATH}:${CATALINA_LIBDIR}"
|
This resolved the problem for now, but maybe there is a better solution. I would also be grateful for any insight into when this stopped working. |
|
| Back to top |
|
 |
alistair
Retired Dev
Joined: 15 Jul 2005
Posts: 869
|
| Posted: Wed Apr 20, 2011 2:15 am Post subject: |
|
|
Ok so I answer this in the other thread but will answer it here as well.
| Quote: | Why are you wanting to add jars to tomcats classpath?
Read class-loader-howto for more information on tomcat and classloading. |
Essentually the question you need to be asking your self is why are you adding a library that your application needs to the entire tomcat server. You should instead only be providing it to the common classloader or even better to only your web applications class loader.
_________________
______________
Help the gentoo-java project. Visit Gentoo Java Project
what good are admin powers if you don't abuse them for personal gain - mark_alec |
|
| Back to top |
|
|
lostinspace2011
Apprentice
Joined: 09 Sep 2005
Posts: 230
|
| Posted: Wed Apr 20, 2011 3:27 am Post subject: |
|
|
Hi Alistair,
The reason I want to specify my tomcat classpath in /etc/conf/tomcat6 is that this allows me to use the currently installed versions of various libraries. I know I can put JARS into the lib folder, but this would mean I can't use java-config -p ... Also the libraries I need are extension to tomcat and don't really belong within the application. Given the separation offered by JPA and J5EE I don't think JDBC drivers should be part of the application either.
My suggested solution has the benefit of allowing me to use java-config -p .. which is great and doesn't require me to check the version of JARS inside the lib folder. Also remove keeping duplicate JARS etc.
Rather then asking why I would want this you should be asking why I would not want this. How is adding a JAR to the lib folder better ?
Regards
Alex |
|
| Back to top |
|
|
alistair
Retired Dev
Joined: 15 Jul 2005
Posts: 869
|
| Posted: Wed Apr 20, 2011 7:46 am Post subject: |
|
|
| lostinspace2011 wrote: | Hi Alistair,
The reason I want to specify my tomcat classpath in /etc/conf/tomcat6 is that this allows me to use the currently installed versions of various libraries. I know I can put JARS into the lib folder, but this would mean I can't use java-config -p ... Also the libraries I need are extension to tomcat and don't really belong within the application. Given the separation offered by JPA and J5EE I don't think JDBC drivers should be part of the application either.
|
No, but then are JDBC drivers a part of the tomcat server. They are a common library and therefore don't belong on tomcats classpath.
| lostinspace2011 wrote: |
My suggested solution has the benefit of allowing me to use java-config -p .. which is great and doesn't require me to check the version of JARS inside the lib folder. Also remove keeping duplicate JARS etc.
Rather then asking why I would want this you should be asking why I would not want this. How is adding a JAR to the lib folder better ?
Regards
Alex |
To give you a bit of background. The java team has implemented java-config and all the other tools to get users away from setting CLASSPATH. Why? because we strongly believe that applications should manage there own classpath's. There can be unexpected consequences of adding classes via CLASSPATH. ant is an example where we had issues. Potentially there could be security issues with doing it tho in this case these would also exist by adding these libraries to the lib folder as well. Have you configured a SecurityManager?
What I would consider a proper solution would be a way to manage the libraries within $CATALINA_HOME/lib. Possible /etc/conf.d/tomcat-* could have a COMMON_EXTRA_CLASSPATH which could copy/link/.... the java packages listed into $CATALINA_HOME/lib. Provide a way to cleanup that directory, etc, etc, etc. or maybe it should be similar to the webapp functionality we have. While I haven't thought this thru it seems an interesting project and probably isn't particularly large. What do you think?
_________________
______________
Help the gentoo-java project. Visit Gentoo Java Project
what good are admin powers if you don't abuse them for personal gain - mark_alec |
|
| Back to top |
|
|
lostinspace2011
Apprentice
Joined: 09 Sep 2005
Posts: 230
|
| Posted: Wed Apr 20, 2011 9:54 am Post subject: |
|
|
I could not disagree more with you. Sorry, I appreciate all the great work you guys are doing but forcing each application to manage it's own classpath is a terrible idea. Might as well remove all other java packages from portage and let everybody manage this themselves. I appreciate that having a global classpath is not good and can introduce problems. However this is not what I am after. I only want to be able to include specific libraries and extension to tomcat. If you look at my solution I am not proposing to set a global CLASSPATH, but the option of setting CATALINA_LIBDIR in /etc/conf/tomcat6 and have this included in /etc/init.d/tomcat6.
By allowing users to specify the classpath in /etc/conf/tomcat6 they are able to emerge the required packaged, add any additional ones which are not in portage and don't have to worry about much else. It also makes upgrading both tomcat and the libraries much simpler as all the pre-requisites will be maintained as well as tomcat being able to keep its own libraries in its own place. Lets say I wanted to upgrade the database version. With your model I have to emerge the new drivers and then copy them over. If the driver names are different I have to remember to delete the old ones. While with my "solution" all I would have to do is to emerge the drivers and all it good.
If you are going to insist on removing the option to configure the tomcat classpath, please update the /etc/conf/tomcat file with a description that this is no longer possible. As things currently stand one gets the idea that it may work, but then due to the "issues" with /etc/init.d/tomcat6 not respecting /etc/conf/tomcat6 it will not work.
I agree with you that most users would not require changing the tomcat classpath, but there are good cases for when one really needs to do this.
1.) I have a tomcat extension which publishes its presence on the network via mdns. This requires some custom code as well as the mDNS... jar in the classpath at startup.
2.) Apache have provided the option to extend the classpath. Extract from catalina.sh for tomcat 6.0.26
| Quote: | # Ensure that any user defined CLASSPATH variables are not used on startup,
# but allow them to be specified in setenv.sh, in rare case when it is needed.
CLASSPATH= |
|
|
| Back to top |
|
|
|
Portage & Programming
