Category: Websphere

Websphere Shared Library

Shared libraries are files used by multiple applications. Examples of shared libraries are commonly used frameworks like Apache Struts or log4j. You use shared libraries typically to point to a set of JARs and associate those JARs to an application, a Web module, or the class loader of an application server.

Shared libraries are especially useful when you have different versions of the same framework you want to associate to different applications.

Shared libraries are defined using the administration tools. They consist of a symbolic name, a Java class path, and a native path for loading JNI libraries.

1

However, simply defining a library does not cause the library to be loaded. You must associate the library to an application, a Web module, or the class loader of an application server for the classes represented by the shared library to be loaded. Associating the library to the class loader of an application server makes the library available to all applications on the server.

Note: If you associate a shared library to an application, do not associate the same library to the class loader of an application server.

You can associate the shared library to an application in one of two ways:

  • You can use the administration tools. The library is added using the Shared libraries references link under the References section for the enterprise application.

4

5

  • You can use the manifest file of the application and the shared library. The shared library contains a manifest file that identifies it as an extension. The dependency to the library is declared in the application’s manifest file by listing the library extension name in an extension list.

3

Configuring websphere for external third party non-JCA JMS provider

WAS v6.1 supports the use of third-party JMS providers within its runtime environment through the use of a generic JMS provider. A generic JMS provider must be defined to WAS before any JMS resources can be configured for that provider.

Defining a generic JMS provider to WAS ensures that the JMS provider classes are available on the application server classpath at runtime.

WAS interaction with a generic JMS provider –

The JMS administered objects for a generic JMS provider are bound into the local JNDI name space within WebSphere Application Server. These JNDI entries act as aliases to the real JMS administered objects that have been configured in the external JNDI name space of the messaging provider.

1

This indirection is achieved by providing additional JNDI information when configuring the JMS administered objects for the generic JMS provider. JMS client application code is not affected in any way. It is the responsibility of the WebSphere runtime to resolve accesses to the real JNDI entries in the external name space.

WebSphere is not responsible for binding the JMS administered objects into the external name space. This administrative task, along with creating the underlying messaging objects, queues, and topics, must be performed using the tools provided by the generic JMS provider.

Configuring a JMS provider for a third party non-JCA messaging provider:

  1. Start the administrative console.
  2. In the navigation pane, click Resources > JMS->JMS providers. The existing messaging providers are displayed, including the default messaging provider and the WebSphere MQ messaging provider.
  3. To define a new third-party non-JCA messaging provider, click New in the content pane. Otherwise, to change the definition of an existing messaging provider, click the name of the provider.
  4. Specify the following required properties. You can specify other properties, as described in a later step.

         Name: The name by which this messaging provider is known for administrative purposes within WebSphere Application Server.

         External initial context factory: The Java classname of the initial context factory for the JMS provider.

        External provider URL: The JMS provider URL for external JNDI lookups.

5. Optional: Click Apply. This enables you to specify additional properties.

6. Click OK

7. Save the changes to the master configuration.

2

Configuring a JMS connection factory for a third party non-JCA messaging provider:

  1. Display the third-party non-JCA messaging provider. In the navigation pane, click Resources > JMS->JMS providers.
  2. Select the third-party non-JCA messaging provider for which you want to configure a connection factory.
  3. Optional: Select the Scope setting corresponding to the scope of the connection factories that you want to view or change.
  4. In the content pane, under Additional Properties, click Connection factories This displays a table listing any existing JMS connection factories, with a summary of their properties.
  5. To browse or change an existing JMS connection factory, click its name in the list. Otherwise, to create a new connection factory, complete the following steps:
    1. Click New in the content pane.
    2. Specify the following required properties. You can specify other properties, as described in a later step.

                  Name: The name by which this JMS connection factory is known for administrative purposes within IBM® WebSphere® Application Server.

                 Type: Select whether the connection factory is for JMS queues (QUEUE) or JMS topics (TOPIC).

                 JNDI Name: The JNDI name that is used to bind the JMS connection factory into the WebSphere Application Server namespace.

                 External JNDI Name: The JNDI name that is used to bind the JMS connection factory into the namespace of the messaging provider.

C. Click Apply. This defines the JMS connection factory to WebSphere Application Server, and enables you to browse or change additional properties.

6. Click OK.

7. Save any changes to the master configuration.

3

Configuring a JMS destination for a third party non-JCA messaging provider:

  1. Start the administrative console.
  2. In the navigation pane, click Resources > JMS->JMS providers.
  3. Click the name of the third-party non-JCA messaging provider.
  4. In the content pane, under Additional Properties, click Queues for point-to-point messaging or Topics for publish/subscribe messaging.This displays a table listing any existing JMS destinations, with a summary of their properties.
  5. To browse or change an existing JMS destination, click its name in the list. Otherwise, to create a new destination, complete the following steps:
    1. Click New in the content pane.
    2. Specify the following required properties. You can specify other properties, as described in a later step.

                 Name: The name by which this JMS destination is known for administrative purposes within WebSphere Application Server.

                 Type: Select whether the destination is for JMS queues (QUEUE) or JMS topics (TOPIC).

                 JNDI Name: The JNDI name that is used to bind the JMS destination into the WebSphere Application Server namespace.

                 External JNDI Name: The JNDI name that is used to bind the JMS destination into the namespace of the messaging provider.

    1. Click Apply. This defines the JMS destination to WebSphere Application Server, and enables you to browse or change additional properties.

6. Click OK.

7. Save any changes to the master configuration.

4

Set custom property for the JMS destination:

Set custom properties of the provider to map external JNDI names. Below is just for illustration & ease of reference purpose:

– java.naming.connectionFactoryNames = ConnectionFactory
– java.naming.queue.MyQueue = MyQueue
– java.naming.topic.MyTopic = MyTopic

5

Managing message listener resources for message-driven beans:

  1. Start the administrative console.
  2. In the navigation pane, click Servers > Server Types > WebSphere application servers->server_name > [Communications] Messaging > Message listener service > [Additional Properties] Listener Ports > listener_port
  3. Select the name of the listener port that you want to work with. This displays the properties of the listener port in the content pane.
  4. Click OK.
  5. Save your changes to the master configuration.
  6. To have a changed configuration take effect, stop then restart the application server.

Create a Message Listener Port for message-driven beans. Below is just for illustration & ease of reference purpose:
– Set the connection factory JNDI, e.g. “ConnectionFactory”
– Set the destination JNDI, e.g. “MyTopic”

6

7

In the MDB project’s “ibm-ejb-jar-bnd.xmi” file, refer to the above message listener as –


<?xml version="1.0" encoding="UTF-8"?>

<ejbbnd:EJBJarBinding xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:ejb="ejb.xmi" xmlns:ejbbnd="ejbbnd.xmi" xmi:id="EJBJarBinding_1416464607405">

<ejbJar href="META-INF/ejb-jar.xml#ejb-jar_ID"/>

<ejbBindings xmi:type="ejbbnd:MessageDrivenBeanBinding" xmi:id="MessageDrivenBeanBinding_1416464607406" listenerInputPortName="AMQ_JMS_TopicPort">

<enterpriseBean xmi:type="ejb:MessageDriven" href="META-INF/ejb-jar.xml#SampleMDB"/>

</ejbBindings>

</ejbbnd:EJBJarBinding>

WebSphere AppServer 6.1 MQ JMS log enabling

Static trace enabling:

1. Log on to the Administrative Console.
2. In the left panel, expand Troubleshooting. Click on “Logs and Trace”.
3. Select the application server that is to be traced. Then on the next page click on the “Diagnostic Trace” link.
4. Select the Configuration tab.
5. Select the “Enable Log” property, if already not selected.
6. Under the “Trace Output”, select the File radio button, if already not selected. Set the Maximum file size to 100 MB and Increase the Maximum number of historical files to 10.
7. To ensure you capture full data flows, select Advanced for the Trace Output Format.
8. Click on the “Change Log Detail Levels” under Additional Properties on the right side panel.
9. Under the Configuration tab, enter the following string :

*=info:JMSServer=all:Messaging=all:JMS_WASTraceAdapter=all:com.ibm.mq.*=all:jmsApi=all

10. To gather transaction and connection API trace, append the following string :

For Connection: ConnLeakLogic=all:WAS.j2c=all
For Transaction: Transaction=all

11. Click OK and Save. your configuration.  Select Synchronize changes with Nodes option.Then restart the Application server.

Dynamic trace enabling:

1. Log on to the administrative console.
2. In the left panel, expand Troubleshooting and click on Logs and Trace.
3. Select the application server to be traced, and than on the next page click the Diagnostic Trace link.
4. Select the Runtime tab (Server should be up and running for this tab to show up).
5. Under Trace Output, select File and type a File name (if you do not specify path, but just the file name, then the default location of the file is under the application server profile directory). Set the Maximum File size to 100Mb and Maximum Number of historical files to 10.
Important: Do not select Save Runtime Changes to Configuration as well if you do not want this setting to become permanent.
6. On same panel click on Change Log Detail Levels under Additional Properties on right side panel.
7. Select the Runtime tab.
8. Enter the following trace string :

*=info:JMSApi=all:JMSServer=all:Messaging=all:JMS_WASTraceAdapter=all:com.ibm.mq.*=all:jmsApi=all

9. To gather transaction and connection API trace, append the following string:

For Connection: ConnLeakLogic=all:WAS.j2c=all
For Transaction: Transaction=all

10. Click Apply and OK. Then Save your configuration.  Select Synchronize changes with Nodes option.

Enabling traces for debugging class loader issues in Websphere Application Server 6.1

Enabling Class loader traces:

 Use the following steps to collect a class loader trace for WebSphere Application server Version 6.1:-

1. Log on to the administrative console.

2. In the left navigational panel, expand Troubleshooting. Click Logs and Trace.

3. Select the application server to be traced, and then on the next page click the Diagnostic Trace link.

4. Select the Configuration tab.

5. Select the Enable Log property.

6. Under Trace Output, select the File radio button, and specify the file name. Also Increase the Maximum file size to 100 MB, and increase the Maximum number of historical files to 10.

7. Select Basic (Compatible) Trace Output Format.

8. Navigate to Logging and Tracing > application_server > Change Log Detail Levels.

9. Under the Configuration tab, specify the trace string suggested.

10.Click Apply and OK. Save your configuration. Select the Synchronize changes with Nodes option if you are using a distributed environment.

 

 

Enabling JVM class loader and bootstrap traces:

To enable the Java Virtual Machine (JVM) class loader and bootstrap traces for Version 6.1, do the following:

1. From the administrative console, select Servers > Application servers, and select the problem server.

2. On the right side, under Server Infrastructure, expand Java and Process Management.

3. Click Process Definition.

4. Under Additional Properties, select Java Virtual Machine.

5. Enable the following Properties by selecting the check boxes located on the left of the property.

– Verbose class loading

– Verbose JNI

6. Click Apply.

7. On right side under Additional Properties, click Custom Properties.

8. Click New.

9. Enter the following custom properties:

– Name: ws.ext.debug

– Value: true

10.Click Apply and OK. Save your configuration. Select the Synchronize

changes with Nodes option if you are using a distributed environment.

 

 

Using the Class Loader Viewer:

 

The Class Loader Viewer in the administrative console can be used to determine how a class is loaded by the class loaders in the WebSphere Application Server.

Enable the Class Loader Viewer service:

If the Class Loader Viewer service is not enabled, the Class Loader Viewer only displays the hierarchy of class loaders and their classpaths, but not the classes actually loaded by each of the class loaders. This also means that the search capability of the Class Loader Viewer is lost.

 To enable the Class Loader Viewer Service, select Servers → Application Servers → server_name, and then click the Class Loader Viewer Service under the Additional Properties link.

Next, select Enable service at server startup.

Restart the application server for the setting to take effect.