Sun Java System Application Server Platform Edition 8.1 2005Q2 Update 2 Troubleshooting Guide

- Previous: Chapter 3 Security Problems

# Chapter 4 Frequently Asked Questions

This section covers some common questions asked about the Application Server:

- What Happens When No Server Side Realm is Configured?

- Can I Use a PKCS12 Certificate for My Client Certificate?

- Can I See the TLS/SSL Handshake Information for an SSL Client?

- Can I Change the Keystore Password?

- How Do I Maintain a Session in JAX-RPC?

- How Do I Access the Naming Service From a Standalone Java Client?

- Are RMI-IIOP Stubs Needed to Access Remote EJBs?

- How Do I Change the Log Level for an Application Logger?

# What Happens When No Server Side Realm is Configured?

When the application is configured (within XML files), but no server side realm is configured, the application is authenticated in the default realm. No error is thrown that indicates “No such realm.”

# Can I Use a PKCS12 Certificate for My Client Certificate?

Is there a way to use my PKCS12 certificate for an SSL the application client or standalone client during mutual authentication?

No. You cannot use a PKCS12 certificate directly, but you can write your own client using the JSSE, which supports `storetype=PKCS12` (read only, no write to keystore).

# Can I See the TLS/SSL Handshake Information for an SSL Client?

Yes. Set the Java debugging property on the JVM. To see the handshake information from the application client, append the following:

    -Djavax.net.debug=ssl,handshake to the VMARGS variable.

# Can I Change the Keystore Password?

Yes. Use the following J2SE properties to change the keystore password:

    -Djavax.net.ssl.keyStorePassword=password
    -Djavax.net.ssl.trustStorePassword=password

Note that the keystore password must match the individual key passwords to perform operations on the keys, so you will need to change the keystore password with the property mentioned above and then change the password to each key to match that password.

# How Do I Maintain a Session in JAX-RPC?

Clients cannot maintain sessions with JAX-RPC endpoints. There is a client and server aspect to sessions, and it is not obvious how to set this up.

The situation is that a client makes a call to the service, and the server responds and sets a cookie on the connection. From then on, the client sends back that same cookie with each call and the server can check it.

A JAX-RPC stub normally ignores the cookie that comes back. When the `SESSION_MAINTAIN_PROPERTY` is set to `true`, it sends back whatever cookie the server set on it.

On the server side, you need to add one field to your class and a method that sets it. The endpoint must implement `javax.xml.rpc.server.ServiceLifecycle`., and two methods must be added: `destroy()` (which can be empty) and `init(Object context)`.

Add a `ServletEndpointContext` object to the endpoint; for example `myServletEndpointContext`. The `init(Object context)` method can be set as follows:

    myServletEndpointContext = (ServletEndpointContext) context;

From then on, the business methods can access to the `HttpSession` with `myServletEndpointContext.getHttpSession()`. The first call to `getHttpSession` creates the session, if one does not already exist.

With this model, any method the client calls can get the session, set session attributes, get values from it, and so on. From then on, the client will send back the same cookie information.

For more information on the `HttpSession` object, see `http://java.sun.com/j2ee/1.4/docs/api/javax/servlet/http/HttpSession.html`

# How Do I Access the Naming Service From a Standalone Java Client?

## To access the naming service from an application client

##### Steps

1. Include `appserv-rt.jar` in the `CLASSPATH` when starting the client Java VM.

   The JNDI bootstrapping machinery looks for a file called `jndi.properties,` which is located in `appserv-rt.jar`. This file contains all the bootstrapping properties for the Application Server’s naming service. It is better to have these properties read from `appserv-rt.jar` than to hard-code them in either the client startup script or in the application code.

2. When accessing remote EJBs from a standalone client, it is not necessary to retrieve the client JAR from the deployment or to put it in the client JVM’s `CLASSPATH`, because static RMI-IIOP stubs are not needed when using the Application Server naming service. This removes a step that was required in previous releases. (See Are RMI-IIOP Stubs Needed to Access Remote EJBs? for more details).

3. Code the client to use the default constructor `InitialContext` that does not require an argument. For example:

       InitialContext ic = new InitialContext();

   It is a common misconception that the client should be coded to explicitly reference the `CosNaming` service. `CosNaming` is only used for some kinds of Application Server objects, so doing this will not provide access to many of the kinds of resources you might need in the client such as JMS queues, connection factories, and so on. Furthermore, explicit use of `CosNaming` bypasses the Application Server’s naming service code. This often means that the client cannot take advantage of desirable value-added behavior built in to the Application Server’s naming service.

4. Use the global JNDI name of the target resource when doing the lookup. `java:comp/env` cannot be used from standalone Java clients, because by definition such clients run outside of a J2EE container. The only client component in which `java:comp/env` can be used is in a J2EE Application Client.

5. If the client is running on a different host machine than the server instance, set the following system property when starting the Java VM:

       -Dorg.omg.CORBA.ORBInitialHost=hostname_of_target_server

   This value defaults to `localhost` so it is only needed if the client and server instance are not colocated. For example:

       java -Dorg.omg.CORBA.ORBInitialHost=server1 ... com.foo.MyMainClass

6. By default, the client attempts to contact port `3700` to access the naming service in the server. Since `3700` is the default naming service port used by the Application Server, there is no additional port configuration needed in the client. In some cases, due to port conflicts, the server instance uses a different naming service port. The naming service port used by the server instance is listed in the `<iiop-listener id="orb-listener-1" port="3700"\>` element in `domain.xml`.

   To change the naming service port used by the client, set the following system property when starting the client Java VM:

       -Dorg.omg.CORBA.ORBInitialPort=naming_port_of_target_server

# Are RMI-IIOP Stubs Needed to Access Remote EJBs?

No. Unlike previous releases of the Application Server, the current version does not require static RMI-IIOP stubs at runtime.

Removing this requirement provides the following benefits:

- Faster deployment and redeployment time for applications containing remote EJBs or clients of remote EJBs

- Fewer runtime errors caused by stub `CLASSPATH` configuration problems

  In addition, the Application Server achieves these benefits without significant impact on runtime performance, while maintaining full RMI-IIOP interoperability.

  The only scenario where RMI-IIOP stubs are still required is for standalone clients that explicitly instantiate an `InitialContext` for the `CosNaming` naming service. This is not the recommended approach for using the naming service in the Application Server. However, to maintain compatibility for these kinds of standalone clients, there is a deployment-time option that forces the generation of RMI-IIOP stubs in a way that matches previous releases. To use it, set

      --generatermistubs=true

  when deploying with `asadmin` or the Administration Console. The RMI-IIOP stubs are placed in the `client.jar` file, just as they were in previous releases.

# How Do I Change the Log Level for an Application Logger?

Each application uses its own application logger to log messages. To configure the log level for a particular application, use one of two options:

- In the Admin GUI Log Level configuration page add a property with a property `name` representing the logger name, and the `value` representing one of seven log levels (`FINEST`, `FINER`, `FINE`, `CONFIG`, `INFO`, `WARNING`, `SEVERE`) or `OFF`.

  For example, to change the log level of application logger named `com.X.Y` to `FINEST`, the property `name` would be `com.X.Y` and the property `value` would be `FINEST`. The change is reflected in the `domain.xml` file, and takes effect immediately. No Server restart is required.

- Directly add the property to the `<module-log-levels\>` element in `domain.xml`, as shown below.

      <module-log-levels admin="INFO" classloader="INFO" cmp="INFO"
      cmp-container="INFO" configuration="INFO" connector="INFO"
      corba="INFO" deployment="INFO" ejb-container="INFO" javamail="INFO"
      jaxr="INFO" jaxrpc="INFO" jdo="INFO" jms="INFO" jta="INFO"
      jts="INFO" mdb-container="INFO" naming="INFO" node-agent="INFO"
      resource-adapter="INFO" root="INFO" saaj="INFO" security="INFO"
      server="INFO" synchronization="INFO" util="INFO" verifier="INFO"
      web-container="INFO"\>
          <property name="com.X.Y" value="FINEST" /\>
      </module-log-levels\>

- Previous: Chapter 3 Security Problems

- © 2010, Oracle Corporation and/or its affiliates