Hi Chuck, I apologize for the weekend caused delay with my reply.
> -----Original Message----- > From: Caldarale, Charles R [mailto:[EMAIL PROTECTED] > Sent: Friday, April 04, 2008 6:27 PM > To: Tomcat Users List > Subject: RE: SEVERE: Error listenerStart > > > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] > > Subject: RE: SEVERE: Error listenerStart > > > > Come on, I have no inclination to become a J2EE hacker. > > No one's asking you to be a J2EE "hacker", but some > familiarity with the > problem domain is expected. GIYF. > In general you are right. If I had tried to run my own servlet webapp I of course would have done my chores first and would have acquainted myself to servlet writing and Tomcat deployment of them. I even must admid that I am kind of intrigued by this technique (after having written a few CGIs in the past and knowing of their performance penalty) and would very much like to delve into servlet programming if I only had more time and at least some basic Java experience. Btw, I discovered a copy of "Inside Servlets, 2nd Ed." by Dustin R. Callaway which appeared in 2001 and seems to cover the 2.2 or 2.3 Servlet Specs. I think to have read somewhere that current Tomcat releases however implement the 2.5 Specs. Would you know if such an old publication still could serve as a usable introduction or have the specs changed too much in the meantime? > > > Yet, I still maintain that the term "listener" is very > > misleading. > > The term "listener" in a data processing context predates J2EE, perl, > and even sockets by decades. For example, it was used at least as far > back as the 1950s to describe the action taken to wait for events or > input on an I/O channel. Computer science co-opted the term in the > early 1960s to refer to any mechanism waiting for some event. I am not that long around in the IT and I haven't got a Computer Sciences background to know this but instead got my theoretical education in Naval Architecture, wherefrom the path over Fortran programming in CASD, CFD, FEM etc. somehow led me to Unix system administration. > > > Btw, would a -Djava.library.path provided argument take > > precedence over LD_LIBRARY_PATH settings > > Yes, the system property overrides the environment variable (Java > launchers on Windows use PATH, not LD_LIBRARY_PATH, by the way, if you > ever use that platform). > Thanks God, I am relieved from any sysadmin responsibility for this platform. > > But interestingly, they both are 32bit builds while my kernel is > > a 64Bit one. > > That is likely the root of the problem. Sounds like you need > to contact > your .war vendor and have them supply 64-bit .so files; alternatively, > you could install and run a 32-bit JVM, but that would seem to be a > serious step backwards. Yes, it indeed was. For a lark, I downloaded and unpacked a JRE for i386, removed the comment again from the listener tag in web.xml, and set JRE_HOME to point to the extract root of the i386 JRE. Then I restarted Tomcat, and the webapp started without any exception stack trace dumps to the logs. A GET to the URI Path of the webapp also works without any signs of errors. # file $(ps -o args= -p $(pgrep -u tomcat java )|cut -d\ -f1) /opt/java/i386/jre1.5.0_12/bin/java: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), for GNU/Linux 2.2.5, stripped # lwp-request -m GET http://localhost:8081/aDISWeb/app|wc -c 1513 This means that the WAR distributor either needs to supply us with correctly built 64bit libs, or that we will have to run a 32bit JVM. Many thanks for your valuable help! Ralph --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
