CATALINA_BASE allows you to have separate config files and a separate shared/lib (along with a separate webapps and work dirs). However, most everything such as core libraries in server/lib and common/lib are used in each CATALINA_BASE instance. I guess it would be nice if there were a place to put jars which the core server can see, but can be different per/CATALINA_BASE. For instance when configuring a datasource, one app might need a certain set of, say... Oracle drivers while another might need different ones. Tomcat must be able to see the driver in order to use container managed datasources but, as things stand, the only place to put them is in common/lib which would be seen by all CATALINA_BASE instances. The only solution is to have two entirely separate Tomcat installs. I think that is what you'll have to do unless the classloading hierarchy gets changed.
As a side note (and this probably wouldn't solve the problem above, but...) it would be nice if Tomcat supported the deployment of ear files, but only used them for deploying contained .war files and shared libraries (not EJB's, of course). That would make deploying related apps and shared libs so much easier and under the control of the developer/deployer rather than the server admin since. Anyway, just a thought. Jake Quoting "CARROLL, Chris, FM" <[EMAIL PROTECTED]>: > I couldn't agree with you more about the logical differences between the web > app(s) and the app server itself. However, I would have thought that the > CATALINA_BASE is the instance of the app server which requires the classes > and not the "raw" installation in CATALINA_HOME. I am trying to understand > why jars in $CATALINA_BASE/common/lib are not included in the app server > (common classloader) classpath. The base common/lib augments the > home/common/lib. I realise that there will be problems if you placed > conflicting versions of the jars in the base that were already in the home > but if you were halfway sensible that wouldn't be done. > > Cheers again, > Chris > > -----Original Message----- > From: Benjamin Armintor [mailto:[EMAIL PROTECTED] > Sent: 21 May 2004 15:27 > To: Tomcat Users List > Subject: RE: Tomcat 5: Location of 3rd party JNDI datasource jars in > $CATALINA _HOME/common/lib > > > I understand where you're coming from. Maybe Yoav will correct me if I'm > wrong, but the important caveat is that classes are only specific to the > instance if the app server classes don't need to know about them. The > problem with JNDI is that the naming context is created by the app server, > and not the web app - but of course, the web app is the one that uses the > naming context. If you wanted to isolate the drivers by instance, you could > forego JNDI as the access mechanism for the JDBC pools (create some > singleton pool in the shared classloader, etc.)- although this would need > kludging some things like password files, etc. It would, though, give you > some ways to leave the code in shared/lib. > > Benjamin J. Armintor > Systems Analyst > ITS-Systems: Mainframe Group > University of Texas - Austin > tele: (512) 232-6562 > email: [EMAIL PROTECTED] > > > > -----Original Message----- > From: CARROLL, Chris, FM [mailto:[EMAIL PROTECTED] > Sent: Friday, May 21, 2004 8:13 AM > To: 'Tomcat Users List' > Subject: RE: Tomcat 5: Location of 3rd party JNDI datasource jars in > $CATALINA _HOME/common/lib > > > Thanks for the info Ben. The only counter argument I have is > "...$CATALINA_BASE is for instance specific information...". Making a > datasource reference available to a single instance would imply > CATALINA_BASE. ALL Tomcat instances would imply CATALINA_HOME. It's a > picky point and maybe I misunderstand the use of CATALINA_BASE. > > To me CATALINA_HOME is the a basic installation and CATALINA_BASE is the > fully configured instance (including shared resources). Not every instance > based off a "shared tomcat installation" would use the same resources. > Dtasources would be specific to individual instances. > > Cheers, > > Chris > > > -----Original Message----- > From: Benjamin Armintor [mailto:[EMAIL PROTECTED] > Sent: 21 May 2004 14:03 > To: Tomcat Users List > Subject: RE: Tomcat 5: Location of 3rd party JNDI datasource jars in > $CATALINA _HOME/common/lib > > > If a class needs to be accessed by both server components and web apps, it > must be in the common classloader. The classes in the common class loader > are all in $CATALINA_HOME. $CATALINA_BASE is for instance specific > information, and the shared class loader is for classes that only need to be > available to web apps (not server components); all $CATALINA_BASEs share the > same server classes. The unpredictable behavior mentioned is that the > classloaders that web apps use do not necessarily delegate to their parents > (ie, by default they prioritize the local version of a class), which means > you might get nasty class definition errors if you put copies of the same > classes in, say, shared/lib and server/lib. > > Benjamin J. Armintor > Systems Analyst > ITS-Systems: Mainframe Group > University of Texas - Austin > tele: (512) 232-6562 > email: [EMAIL PROTECTED] > > > > -----Original Message----- > From: CARROLL, Chris, FM [mailto:[EMAIL PROTECTED] > Sent: Friday, May 21, 2004 7:54 AM > To: '[EMAIL PROTECTED]' > Subject: Tomcat 5: Location of 3rd party JNDI datasource jars in $CATALINA > _HOME/common/lib > > > > Hi all, > > This probably a simple question but I cannot find any answer to this in the > FAQ or buglist. Why is it that the required jars for 3rd party JNDI > datasource (such as JDBC pools) have to be placed in > $CATALINA_HOME/common/lib? Why does the Tomcat instance not use > $CATALINA_BASE/[common|shared]/lib instead? I've tried various different > ways but the only one that works is the CATALINA_HOME approach. > > >From the JNDI Datasource HOW-TO: > "NOTE: Third Party drivers should be in jarfiles, not zipfiles. Tomcat only > adds $CATALINA_HOME/common/lib/*.jar to the classpath. > NOTE: Do not install these jarfiles in your /WEB-INF/lib, or > $JAVA_HOME/jre/lib/ext, or anywhere else. You will experience problems if > you install them anyplace other than $CATALINA_HOME/common/lib." > > There may be something blindingly obvious that I am missing here but it > seems to mean that you can only have a partially shared tomcat installation. > Resource jars from the different instances have to be placed in the > CATALINA_HOME "common" area somewhat negating the benefits of using a > separate server via CATALINA_BASE. > > Cheer, > > Chris Carroll > > > > *********************************************************************************** > The Royal Bank of Scotland plc. Registered in Scotland No 90312. > Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. > Authorised and regulated by the Financial Services Authority > > This e-mail message is confidential and for use by the > addressee only. If the message is received by anyone other > than the addressee, please return the message to the sender > by replying to it and then delete the message from your > computer. Internet e-mails are not necessarily secure. The > Royal Bank of Scotland plc does not accept responsibility for > changes made to this message after it was sent. > > Whilst all reasonable care has been taken to avoid the > transmission of viruses, it is the responsibility of the recipient to > ensure that the onward transmission, opening or use of this > message and any attachments will not adversely affect its > systems or data. No responsibility is accepted by The Royal > Bank of Scotland plc in this regard and the recipient should carry > out such virus and other checks as it considers appropriate. > > Visit our websites at: > http://www.rbs.co.uk/CBFM > http://www.rbsmarkets.com > > > ******************************************************************************** > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
