This content has been marked as final. Show 2 replies
As stated in the forum thread at [http://forums.sun.com/thread.jspa?threadID=5320141|http://forums.sun.com/thread.jspa?threadID=5320141], it is easiest for us to help you (and for you to help yourself) if you provide the stack trace on the server side. The [HTTP status code|http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html] of [500|http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.5.1] indicates, as your message also shows, that this is an "internal server error." We really need to see that server log with the stack trace and that should make the problem much easier to diagnose. While it is theoretically possible (depending on the problem) that someone could read your code and see why a NullPointerException or other exception is occurring, it is MUCH easier and faster to look at the stack trace on the server.
The location of the log file with your server's exception stack trace depends on the server you are using. For example, if you are using Tomcat 6, it is likely in a location like <<TOMCAT_HOME>>/logs/localhost* where <<TOMCAT_HOME>> is your installation of Tomcat and localhost* is the latest file starting with the name localhost and ending with the date of the day Tomcat was run. Your server's documentation should indicate where your log files are written or you can grep/search your server's directories for log files. I don't know where WebLogic 8.1 places its log files, but I'm sure that is documented somewhere.
To help us help you, I recommend that you access your server's log files and provide the stack trace the server reports.
I searched for log file using two methods.
1. I search for log file using. c:\bea\logs\log.txt.
Jun 10, 2008 3:06:03 PM -- install "WebLogic Platform" 18.104.22.168 at C:\bea\weblogic81
release 22.214.171.124 [Added]
|_____WebLogic Server [Added]
| |_____Server [Added]
| |_____Server Examples [Added]
|_____WebLogic Workshop [Added]
|_____Workshop Runtime Framework [Added]
|_____WebLogic Workshop Application Developer Edition [Added]
|_____Workshop Samples [Added]
2.I also search using C:\bea\weblogic81\workshop\help\doc\en\workshop\reference\configfiles\con_knexLogCfg_xml_ConfigurationFile.html
This file shows:
workshopLogCfg.xml Configuration File
The workshopLogCfg.xml file specifies the WebLogic Workshop logging configuration and logging levels for WebLogic Server. You may use the logging facility in your applications. You may also be directed by BEA Technical Support personnel to modify WebLogic Workshop's logging behavior in order to diagnose problems you experience. This topic describes the basic features of WebLogic Workshop's logging apparatus.
WebLogic Workshop uses the log4j Java logging facility developed by the Jakarta Project of the Apache Foundation. You can learn more about log4j at The Log4j Project. A brief introduction to log4j is included below.
Log4j defines the Logger class. An application may create multiple loggers, each with a unique name. In a typical usage of log4j, an application creates a Logger instance for each application class that will emit log messages. The name of the logger is typically the same as the partially qualified name of the application class. For example, the application class com.mycompany.MyClass might create a Logger with the name "mycompany.MyClass". Loggers exist in a namespace hierarchy and inherit behavior from their ancestors in the hierarchy.
The Logger class defines four methods for emitting log messages: debug, info, warn and error. The application class invokes the appropriate method (on its local Logger) for the situation being reported.
Log4j defines Appenders to represent destinations for logging output. Multiple Appenders may be defined. For example, an application may define an Appender that sends log messages to the console, and another Appender that writes log messages to a file. Individual Loggers may be configured to write to zero or more Appenders. One example usage would be to send all logging messages (all levels) to a log file, but only error level messages to the console.
Log4J defines Layouts to control the format of log messages. Each Layout specifies a particular message format in which may be substituted the data such as the current time and date, the log level, the Logger name, the log message and other information. A specific Layout is associated with each Appender. This allows you to specify a different log message format for console output than for file output, for example.
All aspects of log4j configuration at runtime. This is typically accomplished with an XML configuration file whose format is defines by the log4j library. The configuration file may be specified at runtime using the log4j.configuration Java property.
The configuration file may declare Loggers, Appenders and Layouts and configure combinations of them to provide the logging style desired by the application.
WebLogic Workshop Logging
By default, WebLogic Workshop's logging configuration is defined in the file workshopLogCfg.xml, which is in BEA_HOME/weblogic81b/common/lib. You may override this default by specifying the location of an alternative log4j configuration file with the log4j.configuration Java property. For example, on the command line used to start WebLogic Server, you could specify -Dlog4j.configuration=<path to config file>.
By default, WebLogic Workshop uses two log files: workshop.log and jws.log.
workshop.log Log File
The file workshop.log is configured to receive all internal logging messages emitted by the WebLogic Workshop runtime.
jws.log Log File
The file jws.log is configured to receive all logging messages emitted by user code associated with a WebLogic Workshop application, including JSX and JAVA files that are used by the application.
To cause your source file to emit messages to the jws.log file, create a Logger for your file. You may create a Logger by calling the JwsContext.getLogger method, typically with the qualified name of your class as the Logger name (e.g. "async.HelloWorldAsync" for the sample web service async/HelloWorldAsync.jws). Then simply call the Logger's debug, info, warn or error methods as appropriate.
The example code below illustrates use of logging in a JWS file. Portions of the source file have been omitted for brevity.
public class HelloWorldAsync
/** @common:context */
* @jws:conversation phase="start"
public void HelloAsync()
Logger logger = context.getLogger("async.HelloWorldAsync");
logger.debug("about to start timer");
// all we do here is start the timer.
private void helloDelay_onTimeout(long time)
Logger logger = context.getLogger("async.HelloWorldAsync");
// send the client a hello message.
logger.debug("in timer handler: calling client");
callback.onHelloResult("Hello, asynchronous world");
// we don't want any more timer events for this conversation.
logger.debug("in timer handler: stopping timer");
The code above results in the following content in jws.log when the HelloAsync method of HelloWorldAsync.jws is invoked.
20 May 2002 13:54:13,466 DEBUG HelloWorldAsync: about to start timer
20 May 2002 13:54:13,559 DEBUG HelloWorldAsync: timer started
20 May 2002 13:54:18,934 DEBUG HelloWorldAsync: in timer handler: calling client
20 May 2002 13:54:18,981 DEBUG HelloWorldAsync: in timer handler: stopping timer
Configuration File Reference