Re: RHAPS tomcat experiences, questions

Gary,

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

No problems, I've been equally buried in our migration to RHEL3, let alone
with a new instance of our application server - so the delays weren't really
a problem.  Hope you're feeling better.

> > The application is unable to process files from ../media-optional
> > (i.e.  webapps/media-optional directory) while running in RHAPS
>
> 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,

The webapp has some optional branding components, which are stored in a
directory /media-optional, which is inside the webapps directory.  i.e.:

    /webapps/media.war
    /webapps/media-optional/images/
    /webapps/media-optional/media-optional.properties

Tomcat unpacks media.war (to get to all the .jsp files, etc.).  When that
webapps is creating the page headers/content, it looks for
../media-optional/media-optional.properties and loads values from there.  I
*believe* (since I can't speak for the vendor) this is done so the media.war
can be distributed as as one package, with optional files distributed and
updated separately (since not all there clients will utilize the branding).

The traditional tomcat (t-tomcat) correctly processes the branding, whereas
the RHAPS tomcat doesn't.  As mentioned, I don't know HOW this application
is doing this branding (i.e. what mechanism it's using to check the file
exists, read it, and process the contents) other than it's using a custom
servlet to do the work.  I also don't understand why it doesn't work in
RHAPS tomcat, but does in t-tomcat -- which is why I was asking about
security or ACL context, since that's the only thing I could think of.  The
vendor has indicated it "should" work on RHAPS tomcat, but they support
t-tomcat.

> 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.

Sorry, yes -- bytecode is different.  By packaging I meant MS SQL JDBC
drivers vs Inetsoft JDBC drivers .jar files (i.e. 3 files vs 1).  I wasn't
sure what the libgjc "classloader" might do in this instance (it should be
OK, but...).  What I meant was the JDBC interface for both drivers should be
identical (the "API")-- the MS drivers say they are JDBC 2.0 compliant, and
we didn't have to make any changes to our traditional tomcat setup when
switching between the drivers (other than changing our connect strings).
What version of JDBC does RHAPS tomcat support?

> 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.

Thanks.

> > 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?

Good question, which I'm afraid I don't have the full answer for -- it's
loading jpython.jar, a copy of python1 for java.  If I put it anywhere
inside the common/lib, shared/lib/ or server/lib the application is unable
to process the python scripts (inside the application context), but if I
append it to the class path it has no problem loading and parsing our python
scripts.

> > 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?

Sure, here are my general comments -- from the context that I'm neither a
developer of this application nor am I terribly familiar with Tomcat
internal workings, or with native-compiled java applications.  Given that, I
can deploy our vendors application to our servers, and can follow their
integration instructions for t-tomcat. ;)  This is where things failed for
me (and admitedly, there may be documentation in the works that covers this,
etc.):

                            --- ### ---

1) I didn't find any documentation as to what RHAPS tomcat changed (or how
to integrate a standard tomcat app), i.e.

i) CLASSPATH changes go here X (alt. to setclasspath.sh)

ii) additional environment changes go here Y (alt. to setenv.sh)

iii) replacment for JAVA_OPTS environment variable since there is no JVM: is
there a RHAPS alternative? If not, just stating that these parameters
(-Xmx, -Xms,
etc.) are not used or required is probably sufficient for most people (i.e.
that would be better than being silent)

iv) /etc/sysconfig/tomcat should be mentioned somewhere (and perhaps to
solve ii. above, a section indicating "additional environment variables
here, make sure to EXPORT them" included in this file...).

If RHAPS tomcat is intended to replace t-tomcat, then it'll be important to
document how t-tomcat apps can be deployed in a RHAPS environment.

                            --- ### ---

2) I've never used the "Manager" webapp to deploy any of our webapps (and
have usually removed both the admin and manager webapps to prevent their use
and any holes that might exist in them), so I ignored the comments in
/etc/sysconfig/tomcat related to the Manager webapp and directory
permissions.  YES! I'll admit that it was a Dumb-User-Move<tm> and hence
filed a bug report on the default perms of the webapps directory.  However,
perhaps that section should mention Manager webapp and/or custom deployed
.war files [language TBD, that's ugly].  At any rate, the current language
isn't obvious as it is currently stated in the description.  For
instance, tomcat docs provide multiple methods of deploying a webapp,
without necessarily using the Manager webapp, all of which work with
t-tomcat installation path permissions.  It's just context for those
unfamiliar with the RHAPS tomcat.

                            --- ### ---

Essentially what I think is missing is the most basic, straight forward
"migration" document.  The vendors know how to support traditional tomcat,
and will hopefully learn to support RHAPS tomcat, but given that RHAPS
tomcat attempts to fulfil the t-tomcat role, I think it needs clearer
integration documentation for those familar with t-tomcat moving the RHAPS
tomcat.

> 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".

Fair enough, and perhaps it's just because I'm familar with enough of the
debug tools for Java (IBM's heaproots, for instance) on our platform.
Essentially, I see it as follows: Tomcat is intended to be a Java App Server
running in a JVM (Sun, IBM, etc.).  RHAPS tomcat is an app server that is no
longer a JVM, and so the entire "context" of RHAPS tomcat has changed.  We
can no longer deploy java profiling tools, or dynamic byte-code tools (those
that dynamically tool the bytecode for purposes of tracking memory leaks in
java, etc.).  And I've lost the ability (seemingly) to deploy different JDBC
drivers (that did work with t-tomcat).  I suppose I expected the RHAPS
tomcat
to work like t-tomcat, since it's intended to be the RH deployment of
tomcat.  It's more like tomcat++ or tomcat+RH instead of a t-tomcat package.

I guess I'm just curious as to "why" the context needed to be changed (what
was the problem RH was trying to solve by changing from a JVM environment to
a non-JVM environment), and what are the advantages, and potentially
disadvantages?  My issue is that I need to support the vendor application in
our environment, but I'd like to reduce TCO from an administrative
perspective.  Other admins will take over this work after my research is
complete, and management needs assurance that nothing in our current setup
will be "broken" after a migration.  RHEL is a step in our migration plans,
and RHAPS tomcat will be a second if we can get it to work as well as
t-tomcat did, with minimal learning curve, etc.

Cheers, Tim

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