Main Previous

Frequently Asked Questions

This chapter covers some common questions asked about the Application Server.

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."

^{Top of Page}

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).

^{Top of Page}

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.

^{Top of Page}

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.

^{Top of Page}

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.

^{Top of Page}

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

• • To access the naming service from an application client*
    \

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:\\\\\~UWC_TOKEN_START~1278150637773~UWC_TOKEN_END
   \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:\\\\\~UWC_TOKEN_START~1278150637774~UWC_TOKEN_END
   \This value defaults to localhost so it is only needed if the client and server instance are not colocated. For example:\\\\\~UWC_TOKEN_START~1278150637775~UWC_TOKEN_END
   \
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

^{Top of Page}

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.

^{Top of Page}

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\>

Main Previous