|
From: Hoffman, J. <Jon...@ac...> - 2006-11-21 21:16:28
|
I believe you are right about it being a problem with a dependent class of
the main class. When I run it as a service on the server it runs fine, it
is when I run it on my desktop machine in console mode that I have problems.
I missed the extra dot "." in the log4J classpath through. I most of looked
at that a couple hundred times today and never once say that dot :O(. Maybe
my wife is correct, I do need to start wearing my glasses (I will never
admit that to her through :O).
Thanks for the respone.
Jon
-----Original Message-----
From: wra...@li...
[mailto:wra...@li...]On Behalf Of Leif
Mortenson
Sent: Tuesday, November 21, 2006 3:53 PM
To: wra...@li...
Subject: Re: [Wrapper-user] classpath problems
Jon,
You mentioned that you were setting the system classpath. I assume
that you mean
the CLASSPATH environment variable. When using the wrapper, this will
be ignored
because the -classpath parameter is always being provided when launching
the JVM.
Java falls back to looking for the CLASSPATH environment variable when a
specific
classpath is not specified on the command line. In general it is a good
idea to avoid the
use of the system wide CLASSPATH as it will cause unpredictable results
when using
multiple java applications.
Also noticed that your main class is specified a little strangely.
This may work on
Windows, but you would have problems on UNIX platforms. It should look like
this:
wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp
wrapper.app.parameter.1=com.acs.wrapper.outbound.OutboundProcessor
wrapper.app.parameter.2=C:\editest\Test
wrapper.app.parameter.3=C:\editest\Prod
wrapper.app.parameter.4=C:\edidirect\home\meddata\Test\outbound
wrapper.app.parameter.5=C:\edidirect\home\meddata\Prod\outbound
wrapper.app.parameter.6=C:\edidirect\home\responses\Prod
wrapper.app.parameter.7=C:\edidirect\home\responses\Test
Your library path only needs to contain the location of the
wrapper.dll or any other
jni libraries. You should remove the wrapper.exe and wrapper.dll
entries from the
path.
On to your class loading problem. You mentioned at the bottom of
your mail that
things work if your move all of the jars into the JVMs ext directory.
Doing so makes
the classes into system classes so they no longer need to be located on
the classpath.
Does your com.acs.wrapper.outbound.OutboundProcessor
class exist within the c:\Wrapper\dist\lib\WrapperProcessor.jar jar? I
assume that
will be yes. When java attempts to load a class, it must also be able
to load all of the
classes and interfaces required by that class. It would make sense for
Java to always
show the specific class which could not be found, but I have seen cases
where the
failure to load a dependent class will result in a message stating that
the requested
class could not be loaded. Could you check your OutboundProcessor
class and
make sure that it does not require any other classes to be present?
Your log4j classpath definition has an extra "." in it, but it looks
like the wrapper
is resolving that correctly by the time it creates the java command so I
don't think
that is your cause.
Another possibility is a a file permissions problem. Are you
running the wrapper
as a service or in console mode.
Cheers,
Leif
Hoffman, Jon wrote:
> Hello,
> I recently started working on a project that was started by a former
> employee of the company I work for. They were using the Java Service
> Wrapper to create a windows service, but I have never used it before and I
> am having a lot of problems with the classpath.
> When I try to run the application through the console I get the following
> error:
>
> jvm 1 | WrapperSimpleApp: Unable to locate the class
> com.acs.wrapper.outbound.OutboundProcessor:
>
java.lang.ClassNotFoundException:com.acs.wrapper.outbound.OutboundProcessor
>
> I have both the system classpath and the wrapper classpath set up to point
> to the jar file that contains the OutboundProcessor class
> (c:\Wrapper\dist\lib\WrapperProcessor.jar). When I turn on debug mode and
> it prints out the java command, the classpath is being set properly
> (c:\Wrapper\dist\lib\WrapperProcessor.jar is in the classpath):
>
> C:\bea\jdk142_05\bin\java.exe
> -Djava.library.path="wrapper.dll;wrapper.exe;c:\program files\sqllib\bin"
> -classpath
>
"c:\Wrapper\lib\wrappertest.jar;c:\Wrapper\lib\wrapper.jar;c:\Wrapper\dist\l
>
ib\WrapperProcessor.jar;c:\Wrapper\lib\commons-logging.jar;c:\Wrapper\lib\lo
> g4j-1.2.8.jar;." -Dwrapper.key="h_MrwxLwWo3O6XhN" -Dwrapper.port=32000
> -Dwrapper.jvm.port.min=31000 -Dwrapper.jvm.port.max=31999
> -Dwrapper.debug="TRUE" -Dwrapper.pid=3440 -Dwrapper.version="3.2.0"
> -Dwrapper.native_library="wrapper" -Dwrapper.cpu.timeout="10"
> -Dwrapper.jvmid=1 org.tanukisoftware.wrapper.WrapperSimpleApp
> com.acs.wrapper.outbound.OutboundProcessor C:\editest\Test C:\editest\Prod
> C:\edidirect\home\meddata\Test\outbound
> C:\edidirect\home\meddata\Prod\outbound C:\edidirect\home\responses\Prod
> C:\edidirect\home\responses\Test
>
> I tried putting the jar file in my jdk/jre/lib/ext directory and
everything
> worked perfectly (the wrapper process found my jar and ran the
application).
> Below is my configuration file:
>
> #********************************************************************
> # TestWrapper Properties
> #
> # NOTE - Please use src/conf/wrapper.conf.in as a template for your
> # own application rather than the values used for the
> # TestWrapper sample.
> #********************************************************************
> # Java Application
> wrapper.java.command=java
>
> # set Wrapper native lib
> wrapper.native_library=wrapper
>
> # Java Main class. This class must implement the WrapperListener
interface
> # or guarantee that the WrapperManager class is initialized. Helper
> # classes are provided to do this for you. See the Integration section
> # of the documentation for details.
>
> wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp
> com.acs.wrapper.outbound.OutboundProcessor C:\editest\Test C:\editest\Prod
> C:\edidirect\home\meddata\Test\outbound
> C:\edidirect\home\meddata\Prod\outbound C:\edidirect\home\responses\Prod
> C:\edidirect\home\responses\Test
>
> # Java Classpath (include wrapper.jar) Add class path elements as
> # needed starting from 1
> wrapper.java.classpath.1=c:\Wrapper\lib\wrappertest.jar
> wrapper.java.classpath.2=c:\Wrapper\lib\wrapper.jar
> wrapper.java.classpath.3=c:\Wrapper\dist\lib\WrapperProcessor.jar
> wrapper.java.classpath.4=c:\Wrapper\lib\commons-logging.jar
> wrapper.java.classpath.5=c:\Wrapper\.lib\log4j-1.2.8.jar
> wrapper.java.classpath.6=c:\Wrapper\lib\commons.jar
> #wrapper.java.classpath.7=C:\Program Files\SQLLIB\java\db2java.zip
> #wrapper.java.classpath.8=C:\Program Files\SQLLIB\java\runtime.zip
> #wrapper.java.classpath.1=C:\Wrapper\dist\lib\WrapperProcessor.jar
> #wrapper.java.classpath.2=C:\Wrapper\lib
>
> # Java Library Path (location of Wrapper.DLL or libwrapper.so)
> wrapper.java.library.path.1=wrapper.dll
> wrapper.java.library.path.2=wrapper.exe
> wrapper.java.library.path.3=c:\program files\sqllib\bin
>
> # Java Additional Parameters
> #wrapper.java.additional.1=
>
> # Initial Java Heap Size (in MB)
> #wrapper.java.initmemory=3
>
> # Maximum Java Heap Size (in MB)
> #wrapper.java.maxmemory=64
>
> # Application parameters. Add parameters as needed starting from 1
> #wrapper.app.parameter.1=
>
> #********************************************************************
> # Wrapper Logging Properties
> #********************************************************************
> # Format of output for the console. (See docs for formats)
> wrapper.console.format=PM
>
> # Log Level for console output. (See docs for log levels)
> wrapper.console.loglevel=INFO
>
> # Log file to use for wrapper output logging.
> wrapper.logfile=../logs/OutboundWrapper.log
>
>
> # Format of output for the log file. (See docs for formats)
> wrapper.logfile.format=LPTM
>
> # Log Level for log file output. (See docs for log levels)
> wrapper.logfile.loglevel=INFO
>
> # Maximum size that the log file will be allowed to grow to before
> # the log is rolled. Size is specified in bytes. The default value
> # of 0, disables log rolling. May abbreviate with the 'k' (kb) or
> # 'm' (mb) suffix. For example: 10m = 10 megabytes.
> wrapper.logfile.maxsize=0
>
> # Maximum number of rolled log files which will be allowed before old
> # files are deleted. The default value of 0 implies no limit.
> wrapper.logfile.maxfiles=0
>
> # Log Level for sys/event log output. (See docs for log levels)
> wrapper.syslog.loglevel=NONE
>
>
> ############## My property ########################
> #wrapper.daemonize=TRUE
> #wrapper.monitor_thread_count=true
> #wrapper.startup.delay=30
> #wrapper.startup.delay.console=0
> #wrapper.startup.delay.service=30
> # work
> #wrapper.max_failed_invocations=100
> # Seconds to restart jvm, by default # 30 seconds
> wrapper.ping.timeout=2400
>
>
> #********************************************************************
> # Wrapper Windows Properties
> #********************************************************************
> # Title to use when running as a console
> wrapper.console.title=Outbound Processor
>
> #********************************************************************
> # Wrapper Windows NT/2000/XP Service Properties
> #********************************************************************
> # WARNING - Do not modify any of these properties when an application
> # using this configuration file has been installed as a service.
> # Please uninstall the service before modifying this section. The
> # service can then be reinstalled.
>
> # Name of the service
> #wrapper.ntservice.name=testwrapper
> wrapper.ntservice.name=outboundwrapper
>
> # Display name of the service
> wrapper.ntservice.displayname=Wrapper Outbound Processor
>
> # Description of the service
> wrapper.ntservice.description=ACS Wrapper Outbound Processor 1.0
>
> # Service dependencies. Add dependencies as needed starting from 1
> wrapper.ntservice.dependency.1=
>
> # Mode in which the service is installed. AUTO_START or DEMAND_START
> wrapper.ntservice.starttype=AUTO_START
>
> # Allow the service to interact with the desktop.
> wrapper.ntservice.interactive=false
> #wrapper.single_invocation=TRUE
> wrapper.debug=true
>
>
>
> I have tried using ../dist/lib/WrapperProcessor.jar in the classpath
> (actually that is how the last developer had it set) but that did not work
> either. I also had to move the other jars listed in the classpath section
> to the jdk/jre/lib/ext directory to get Java to find them.
> What is wrong with the classpath and why is it not finding my jar file?
> Any help would be greatly appreciated.
> Thanks
>
> Jon Hoffman
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wrapper-user mailing list
Wra...@li...
https://lists.sourceforge.net/lists/listinfo/wrapper-user
|