Deploying JSP 2

Question

Dear friends,
I still have troubles with deploying jsp application to remote computer with UNIX platform. JSP application uses BI BEANS and on computer with NT platform is everything OK. I have copied all libraries from my computer to remote one. The only difference is platform of the computer. The error message follows.
Thank you for helping me
Martin Cizek
500 Internal Server Error
java.lang.NoClassDefFoundError     at oracle.dss.thin.beans.dataView.BaseTitle.<init>(BaseTitle.java:50)     at oracle.dss.thin.beans.dataView.Title.<init>(Title.java:31)     at oracle.dss.thin.beans.dataView.Title.<init>(Title.java:42)     at oracle.dss.thin.beans.dataView.ThinDataview.<init>(ThinDataview.java:140)     at oracle.dss.thin.beans.gridView.ThinGridView.<init>(ThinGridView.java:122)     at oracle.dss.thin.beans.crosstab.ThinCrosstab.<init>(ThinCrosstab.java:216)     at java.lang.Class.newInstance0(Native Method)     at java.lang.Class.newInstance(Class.java:232)     at oracle.dss.persistence.persistencemanager.client.DefaultObjectFactory.getObjectInstance(DefaultObjectFactory.java:194)     at oracle.dss.persistence.persistencemanager.client.DefaultStateHandler.recreatePersistableFromStateAgent(DefaultStateHandler.java:353)     at oracle.dss.metadataManager.client.handlers.persistence.PersistenceMetadataHandler.getObjectInstance(PersistenceMetadataHandler.java:242)     at oracle.dss.metadataManager.client.MetadataManager.getUserObject(MetadataManager.java:3116)     at oracle.dss.metadataManager.common.MDFolder.lookup(MDFolder.java:350)     at oracle.dss.metadataManager.common.MDFolder.lookup(MDFolder.java:528)     at oracle.dss.addins.jspTags.BIThinSession.loadView(BIThinSession.java:129)     at oracle.dss.addins.jspTags.PresentationTag.createThinObject(PresentationTag.java:142)     at oracle.dss.addins.jspTags.BIBaseTag.getThinObject(BIBaseTag.java:76)     at oracle.dss.addins.jspTags.PresentationTag.doStartTag(PresentationTag.java:225)     at U.jspService(_U.java:72)     [SRC:/U.jsp:6]     at com.orionserver[Oracle9iAS (9.0.2.0.0) Containers for J2EE].http.OrionHttpJspPage.service(OrionHttpJspPage.java:56)     at oracle.jsp.runtimev2.JspPageTable.service(JspPageTable.java:302)     at oracle.jsp.runtimev2.JspServlet.internalService(JspServlet.java:407)     at oracle.jsp.runtimev2.JspServlet.service(JspServlet.java:330)     at javax.servlet.http.HttpServlet.service(HttpServlet.java:336)     at com.evermind[Oracle9iAS (9.0.2.0.0) Containers for J2EE].server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:684)     at com.evermind[Oracle9iAS (9.0.2.0.0) Containers for J2EE].server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:269)     at com.evermind[Oracle9iAS (9.0.2.0.0) Containers for J2EE].server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:735)     at com.evermind[Oracle9iAS (9.0.2.0.0) Containers for J2EE].server.http.HttpRequestHandler.run(HttpRequestHandler.java:243)     at com.evermind[Oracle9iAS (9.0.2.0.0) Containers for J2EE].util.ThreadPoolThread.run(ThreadPoolThread.java:64)

Answer 1

Does this post apply to iAS902 on Linux?
PLEASE HELP!!!!
Specifically: I log in as the oracle user and run the commands to start iAS per the manual.
with DISPLAY set properly and I added xhost +mysvr.
oracle user runs emctl start which start the em website on port 1810.
While the oracle user is logged in the website is fine on all screens.
If I log the oracle user out at the console and access the website I get the error on the server page:
Servlet error: Renderer failed: java.lang.InternalError: Can't connect to X11 window server using 'mysvr.mydomain.edu:0.0' as the value of the DISPLAY variable.
Log back in and it still does not work?
The system was running with the Redhat default /etc/host file that had:
127.0.0.1 mysvr.mydomain.edu mysvr localhost.localdomain localhost
But this was changed to:
127.0.0.1 localhost.localdomain localhost
128.223.28.40 mysvr.mydomain.edu mysvr
because this default host file caused problems with oem and the Inetlligent Agent:
First of all, the error you are getting is related to missing classes/libraries. Please make sure the required libraries are in the classpath of the running application.
Second, you will need to configure the X server on UNIX for JSP applications developed using the BI beans JSP tags to work.
If you are getting an error like this "Can't connect to X11 window server using ':0.0'
as the value of the DISPLAY variable."
Hardware Requirements for X server configuation
The standard X server software which ships with most UNIX platforms imposes some hardware requirements on the hosting machine. The X server requires access to a hardware frame buffer. Also, a keyboard is required by default (although there may be some way to work around this requirement). In general, if the UNIX box includes a monitor and a keyboard, the X server should run with no problems. However, a frame buffer and keyboard may not be installed in some machines in middle-tier, data-center environments. In this case, the X server can not be started.
Starting the X Server
The most common way to start the X server process is to log in to the console of the UNIX machine. Most UNIX platforms boot into the X Display Manager, a small authentication application which displays a login screen. Once the user logs in, the X server is started as a process that is owned by the console user. In the typical default configuration, the console user "owns" the X server - no other users are allowed to access the X server. As discussed later, these default settings can be overridden to allow wider access to the X server.
In cases where system administration is performed remotely (for example, by using telnet from a remote machine), the owner of the console may be required to start the X server on behalf of the remote administrator. To determine whether the X server is already running, look for a process name which starts with X. For example, on Solaris, the X server process is called Xsun.
Once the X server is running, it is extremely important to avoid stopping the X server while any client applications are connected. If the X server is stopped, a signal is sent to any connected clients. In response to this notification, AWT causes the virtual machine (VM) to abort.
This problem is exacerbated by the fact that once AWT connects to the X server, the connection is maintained by AWT for the life time of the VM. So, once any image is generated, an X server connection is established and kept alive until the servlet engine is stopped. Since the X Display Manager shuts down the X server when the console user logs out, this means that the administrator must remain logged in to the X server host machine for as long as the application is running. The console can be locked for security reasons (for example, using a tool such as xlock), but the console user must not end the X server session by logging out.
Setting the DISPLAY Environment Variable
Once the X server is started, the next step in the configuration process is to specify the location of the X server via the DISPLAY environment variable. All X client applications use the information specified by the DISPLAY environment variable to determine how to locate and connect to the X server. The DISPLAY environment variable specifies three pieces of information:
The machine name. This is the name (or IP address) of the machine on which the X server is running. If the machine name is not specified, the local machine is used as the default.
The server number. This number specifies the X server instance to use. In some environments, multiple X servers may be running on a single machine. In most environments, however, only a single X server can be supported. In this case, the server number should be set to 0 (zero).
The screen number. Each X server instance is capable of supporting multiple logical screens. By default, screen 0 (zero) is used.
These three pieces of information are combined into a single value of the following form:
<machine name>:<server number>.<screen number>
When the X server is running on the same machine as the X client, the simplest way to set DISPLAY is to let both the machine name and the screen number default. In this case, the DISPLAY must minimally be set to :0, to indicate that screen zero on server zero on the local machine should be used for all X connections. This is sometimes specified as :0.0, although explicitly specifying the screen number is unnecessary.
Normally, the DISPLAY environment variable can be specified in a login script or shell script. However, in some servlet environments, the DISPLAY environment variable must be specified within servlet engine-specific configuration files. For example, when running a Tecate-based application inside of Apache Jserv in automatic mode, the DISPLAY environment variable must be specified in the jserv.properties file using the following syntax:
wrapper.env=DISPLAY=<machine name>:<server number>.<screen number>
If the DISPLAY environment variable is not explicitly set in the proper servlet engine configuration file, it is likely that attempts to connect to the X server will fail and image generation will be disabled.
Since the X Window System is designed for network-based operation, the X server can be run on a different machine from the X client. This ability can be useful for "headless" middle-tier environments, where some middle-tier machines do not have the necessary hardware to run an X server locally. In this case, the X server can be run on some other machine which can support an X server. The remote X server can be accessed by an X client simply by specifying the machine name via the DISPLAY environment variable.
Note, however, that using a single remote X server as the DISPLAY for many machines within a headless middle-tier environment can be somewhat risky. As mentioned above, if the X server is stopped for any reason, any connected processes are aborted. To avoid this single point of failure, a better solution is to use a remote Tecate servlet instance, which can protect the Tecate-based applications from X server outages.
Testing the Connection
After the DISPLAY is set, the next step in the configuration process is to verify that the X server can be accessed by an X client. The easiest way to verify X server access is to run one of the many X client applications, such as xterm or xclock, that are shipped with the X Window System. (On Solaris, these tools are located in the /usr/openwin/bin directory.)
If the DISPLAY environment variable is set correctly, an application like xterm or xclock should run with no error messages. If the DISPLAY is set to the local machine, the application should become visible on the console. If the DISPLAY is not set, or is set incorrectly, an error message such as "Can't open display: ..." should be printed. If the DISPLAY is set correctly but the client does not have permission to access the X server, a more explicit error message is displayed, for example:
Xlib: connection to "..." refused by server
Xlib: Client is not authorized to connect to Server
Xt error: Can't open display: ...
Access control problems can be resolved using one of two X Window System security mechanisms xhost or xauth.
Since X server access can be controlled on a per-user basis, when testing X server access from the command line it is important to test using the same user ID that is used to run the servlet engine. Web server and servlet engine processes are often run under a special user ID, such as apache or oracle. Before testing X server access from a servlet engine environment, it is important to verify that the appropriate user does indeed have access to the X server. The easiest way to test this is to log in using the user ID that is used to run the servlet engine and to test X server access from the command line by running one of the standard X client applications. Typically, if the console owner is a different user than the servlet engine process owner, some access control configuration (via xhost or xauth) is necessary, since by default only the console owner has access to the X server.