2 Replies Latest reply on Aug 5, 2008 5:10 PM by 843785

    HTTP 500 Internel server error in Custom tag program on Weblogic 8.1

      Dear sir,
      Please attend my problem...

      I face the Error 500 Internel server error when I run the custom tag program on weblogic 8.1.

      My program Structure is:
      JSPProgram>WEB-INF>classes>mypack(package name)>MyTag(TagHandlerclass).
      WEB-INF>tlds>taglib(TLD file)

      <%@ taglib uri="/WEB-INF/tlds/taglib" prefix="Kumar" %>
      <Kumar:hello name="Vijay">
      It is a Tag Body<br>


      package mypack;
      import javax.servlet.jsp.*;
      import javax.servlet.jsp.tagext.*;
      public class MyTag extends TagSupport
      String name;
      public void setName(String c)
      public int doStartTag()
      return EVAL_BODY_INCLUDE;
      public int doEndTag()
      JspWriter out=pageContext.getOut();
      out.print("Good Night "+name);
      catch(Exception e)
      return EVAL_PAGE;


      Allthough this program are run on NetBean6.1.In NetBean6.1, i am not specify the web.xml file.
      Please Help me..
        • 1. Re: HTTP 500 Internel server error in Custom tag program on Weblogic 8.1
          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.
          • 2. Re: HTTP 500 Internel server error in Custom tag program on Weblogic 8.1
            Dear Sir,
            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" at C:\bea\weblogic81
            release [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.

            Log4j Library
            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
            Configuration File
            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.

            package async;
            import weblogic.jws.control.JwsContext;
            import weblogic.jws.control.TimerControl;
            import weblogic.jws.util.Logger;

            public class HelloWorldAsync
            /** @common:context */
            JwsContext context;
            * @common:operation
            * @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.
            logger.debug("timer started");
            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

            Related Topics

            Configuration File Reference