Re: RHAPS tomcat experiences, questions

Hi Tim.  Sorry for the delayed response, especially considering the
amount of effort you've put in.  Unfortunatly I've been ill this past
week.

Tim Strike wrote:
> 2) Unable to load/recognize additional resources (../media-optional/*)
> 
> The application is unable to process files from ../media-optional
> (i.e.  webapps/media-optional directory) while running in RHAPS
> tomcat.  The webapp uses a custom class to load the optional
> properties from this directory.  Permissions are set correctly.
> There are no logged exceptions.  Is there a different security
> context associated with RHAPS tomcat (aside from user tomcat),
> i.e. a compiled-in Java sandbox of some type?  Any other ideas?  I
> haven't logged this as a bug yet, since it could still be
> user_error<tm>.

This sounds like a bug, though I'm not sure that webapps loading stuff
from outside their own directory is particularly supported.  I'd need
more information on what the app was doing in order to debug this,
however.

> 3) Unable to connect to MS-SQL database using Microsoft type 4 JDBC driver
> 
> The application connects to a SQL database using type 4 JDBC
> drivers.  The Microsoft drivers (msbase.jar, msutil.jar,
> mssqlserver.jar) are put into common/lib and work with the
> standalone tomcat.  When run using the RHAPS tomcat, they throw an
> exception (AbstractMethodError) when the database connection is
> established.  Replacing the Microsoft drivers with Inetsoft
> Sprinta2000 drivers (Sprinta2000.jar) allows the RHAPS tomcat server
> to connect to the SQL server.  The only difference is the driver
> manufacturer and the packaging (multiple .jar vs single .jar).
> Does the RHAPS tomcat class loader not handle this properly?  I
> haven't logged this as a bug yet, since it could still be
> user_error<tm>.

I'm not sure what you mean by "the only difference is the driver
manufacturer and the packaging" -- presumably the code is different!
The classfiles aren't byte-for-byte identical, are they?  From the
exception report you attached it looks like the driver is for the
wrong version of JDBC.

> 1) The vendor requests some environment settings be set before
> launching the server; we've normally put these into
> jakarta-tomcat/bin/setenv.sh -- given that these scripts are not
> supplied for RHAPS tomcat, what is the intended replacement?  I see
> two options: /etc/sysconfig/tomcat (sourced during the run), or
> /etc/rc.d/init.d/tomcat (to start the server).  Is there another
> option?  If we make changes to sysconfig/tomcat or /init.d/tomcat,
> will those scripts be overwritten in subsequent upgrades? (setenv.sh
> doesn't exist, so this isn't a problem with our current set-up)

Add your changes to /etc/sysconfig/tomcat -- it won't be overwritten
if you've modified it.  You'll probably have to export the variables
to make them visible to the tomcat process.

> 2) We have one instance of this application that requires additional
> .jar files to be loaded via the CLASSPATH (for some reason, they
> can't be put into common/lib, shared/lib or server/lib).  Similar
> question to #1; normally we'd modify setclasspath.sh to add this
> .jar to the CLASSPATH.  What is the replacement under RHAPS tomcat?

This sounds seriously broken.  Why does it fail?

> 3) The vendor occasionally requires java heap dumps to diagnose
> problems; if their application is run within RHAPS tomcat, my
> understanding is there is no longer a JVM loaded, and so sending
> kill -3 <pid> to get a heap dump will no longer work (RHAPS tomcat
> exits: I tried just-in-case).

I'm not sure that the term heap dump is meaningful in the context of
running native-compiled gcj stuff.  You might be able to get something
equivalent using gdb, but I expect you'd get some blank looks from
your vendor if you tried that :-/

> In general I like the fact that RH is looking to integrate tomcat,
> but deploying vendor applications with RHAPS tomcat has proven to be
> difficult with a steep learning curve compared to standard
> deployment.

I'm sorry that you've found this.  Is there anything obvious that we
could have done to have eased your transition?

> The native language implementation also seems to reduce the
> available functionality of the JVM (java debugging & profiling,
> heapdumps, etc.), and the extensibility of Tomcat.

It's not so much that you can't debug or profile the native-code: you
just use a different toolset.  With a Sun/IBM JVM you would use
Sun/IBM's debugger and profiler; with the GNU JVM (which is what
libgcj effectively is) you use the GNU debugger gdb and the GNU
profiler gprof.  They have the disadvantage in that they don't work in
the same way as Sun/IBM's tools, but they have the advantage that they
do work with other languages.

I'm not sure what you mean by reducing "the extensibility of Tomcat".

> What is the critical point someone would choose RHAPS tomcat over
> standard tomcat, and under what circumstances is that not
> appropriate?

I can't really answer that; sorry.

Gary
--
rhaps-beta-list mailing list
[email protected]
http://www.redhat.com/mailman/listinfo/rhaps-beta-list