tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <Ralph.Gro...@itdz-berlin.de>
Subject RE: SEVERE: Error listenerStart
Date Mon, 07 Apr 2008 08:15:18 GMT
Hi Chuck,

I apologize for the weekend caused delay with my reply.

> -----Original Message-----
> From: Caldarale, Charles R [mailto:Chuck.Caldarale@unisys.com]
> Sent: Friday, April 04, 2008 6:27 PM
> To: Tomcat Users List
> Subject: RE: SEVERE: Error listenerStart
> 
> 
> > From: Ralph.Grothe@itdz-berlin.de 
> > [mailto:Ralph.Grothe@itdz-berlin.de] 
> > 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message