RE: [Wrapper-user] Tomcat console logging: Win XP vs. Win 2K

[Scott W. R. <sr...@in...>]

It's a permissions problem.  The difference is that I'm
logged on as Administrator on the Win2K system.  The=20
default user that the service runs under ("LocalSystem")=20
cannot write to the directories that I created for the
application as Administrator.

Problem solved - thanks for helping me think it through.

> -----Original Message-----
> From: wra...@li...=20
> [mailto:wra...@li...] On Behalf=20
> Of Leif Mortenson
> Sent: Monday, January 05, 2004 12:53 AM
> To: wra...@li...
> Subject: Re: [Wrapper-user] Tomcat console logging: Win XP=20
> vs. Win 2K [faked-from][mx]
>=20
>=20
> Scott,
>     Looking over your wrapper.conf file, I do not see any=20
> problems.  I=20
> actually
> have a Dual CPU W2k system at home and it has been working=20
> perfectly.  So
> I don't think it is an issue with the OS.   I will retest it
again=20
> tonight though just
> to make sure.   I use it for services rather than for day to=20
> day use so=20
> I may have
> overlooked something.
>=20
>     When the Wrapper starts up it will attempt to write to=20
> the log file=20
> specified
> in the wrapper.conf file.  In your case this resolves to=20
> C:/Inventa/ESMIntegrator3.0/portal/var/wrapper.log
>=20
>     If the Wrapper is unable to write to configured file it
will fall=20
> back to writing
> to a log file called wrapper.log which is located in the same=20
> directory=20
> as the
> Wrapper.exe file.   When running as an NT service, there are=20
> some failure
> modes where it is also possible that the wrapper.log file could
be=20
> created in
> the C:\Windows\system32 directory.  Or wherever your Windows
directory
> is located.   Can you please verify that the file does not
exist in=20
> those locations?
>=20
>     The next thing I would have you try is set the following:=20
> wrapper.syslog.loglevel=3DSTATUS
>     This will log all of the info level output to your system
event=20
> log.  It may give
> you some useful information.   If not, try a level of INFO. =20
> That will=20
> fill your log
> up fairly quickly as each individual line of output results=20
> in a log entry.
>=20
> >I get no output to the wrapper.log file regardless of
> >whether I enable debugging or not.
> >
> This is strange.  If you are not even getting any output=20
> before the JVM=20
> is launched
> then the Wrapper must be having some problems writing to the=20
> log file.=20
>=20
> >If I run the app
> >via the wrapper console mode (wrapper.exe -c),
> >I see the console output (of course) - and it gets logged
> >to the wrapper.log file (attached).
> >
> Ok, that file looked normal.
>=20
> >  If I run "wrapper -t"
> >to start the app, I get no output beyond the standard 3 log
> >statements from Wrapper itself.
> >
> You should get more than 3 lines if the debug output is
enabled?  Can=20
> you show me
> what 3 lines you are talking about?
>=20
> >  If I start it from the
> >Windows Management Console, *no* wrapper.log file gets
> >created at all.  I searched the filesystems to see if it's
> >getting created somewhere else, but it's not...
> > =20
> >
> Hmm.   Please recheck the locations I mentioned above.
>=20
> >Any thoughts?
> > =20
> >
> "Mondays!" :-)   There must be a logical reason for this.  Post
back=20
> with info I asked for
> above and I'll try to think of what could be going wrong for
you.
>=20
> Are you sure that the Wrapper and its JVM are actually=20
> running after you=20
> start it?  There
> was a bug fixed for the next release that involved the setting
of=20
> environment variables
> when running as an NT service.  It is possible that your use of

> environment variables
> with the set.xxx properties could be running into this=20
> problem.   This=20
> but would cause
> one or more environment variables to not actually be set.  If
your=20
> application happened to
> be using that particular environment variable, it would fail.
>=20
> Try hardcoding the paths into your wrapper.conf file without=20
> using the=20
> environment
> variable replacements.  If that makes the problem go away=20
> then you most=20
> likely running
> into this bug.