Cape Clear Server 7.5.1 Release Notes

Specify the path to a file-checker Java class that scans files in the input directory. Alternatively, add a custom transport that references a Java class that scans the files (see "custom-in").

However, this property should not specify a path. The correct description should be:

Specify the fully qualified name of a Java class that scans files in the input directory. This class must implement the capeclear interface com.capeclear.capeconnect.transport.file.server.NewFileChecker.

The description for the file-in transport should be:

A required attribute of type String, which indicates the input
directory for files picked up by the transport. The value of this
attribute should be the path to a directory on the file system, for
example: "C:\tmp\myapp_in" (on Windows) or "/tmp/my_app_in" (on Linux or Solaris).

For the file-out transport, the endpoint property should be:

Specify the directory to write files to, using three forward slashes to support UNIX systems. For example, file:///c:/tmp would specify the tmp directory on the C:/ drive. For Windows only, file:/C:/tmp is an acceptable format.

* JMS JBossJMS@localhost JMS provider JBoss 4.0 JBoss 4.0 channel configuration

* JMS WebLogicJMS@localhost WebLogic JMS Provider 9.1 WebLogic JMS example configuration for localhost

* JMS WebSphereMQ@localhost

* wsrm.WSRMSequenceProcessor.proxy.pool.size

* msgstore.transport.ThreadCount

If the value set for msgstore.transport.ThreadCount is less than that set for wsrm.WSRMSequenceProcessor.proxy.pool.size, under heavy load conditions, it is possible that sequences will not be marked as terminated at the WS-RM destination, and so will not be cleaned-up until they expire. This can happen when a thread, attempting to send a terminate sequence message to the WS-RM destination, is unable to obtain a proxy from the pool to handle the request.

The most common cause for this error is that you do not have enough space to load all your classes. Use the parameter '-XX:MaxPermSize=128m' to increase the memory available.

[18-Dec-2006 10:51:22.995 GMT] ERROR <RequestReceiverTask> Error in listening to

inbound JMS messages: Cannot instantiate class: com.sun.jndi.fscontext.RefFSContextFactory

javax.naming.NoInitialContextException: Cannot instantiate class:
com.sun.jndi.fscontext.RefFSContextFactory [Root exception is
java.lang.ClassNotFoundException:
com.sun.jndi.fscontext.RefFSContextFactory]

at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:652)

at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:243)

at javax.naming.InitialContext.init(InitialContext.java:219)

at javax.naming.InitialContext.<init>(InitialContext.java:195)

at com.capeclear.capeconnect.transport.jms.common.JmsConnectionPool.createJndiContext(JmsConnectionPool.java:178)

at com.capeclear.capeconnect.transport.jms.common.JmsConnectionPool.reserveJndiContext(JmsConnectionPool.java:122)

at com.capeclear.capeconnect.transport.jms.common.JmsSessionPool.lookupDestination(JmsSessionPool.java:183)

at com.capeclear.capeconnect.transport.jms.server.RequestReceiverTask.runInLoop(RequestReceiverTask.java:115)

at com.capeclear.utils.thread.KeepGoingRunnable.run(KeepGoingRunnable.java:46)

at java.lang.Thread.run(Thread.java:534)

Caused by: java.lang.ClassNotFoundException: com.sun.jndi.fscontext.RefFSContextFactory

at java.net.URLClassLoader$1.run(URLClassLoader.java:199)

at java.security.AccessController.doPrivileged(Native Method)

at java.net.URLClassLoader.findClass(URLClassLoader.java:187)

at java.lang.ClassLoader.loadClass(ClassLoader.java:289)

at java.lang.ClassLoader.loadClass(ClassLoader.java:235)

at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)

at java.lang.Class.forName0(Native Method)

at java.lang.Class.forName(Class.java:219)

at com.sun.naming.internal.VersionHelper12.loadClass(VersionHelper12.java:42)

at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:649)

... 9 more

[18-Dec-2006 10:51:22.995 GMT] INFO <RequestReceiverTask> Will retry receiving without logging further errors.

<param name="ConversionPattern" value="[%d{dd-MMM-yyyy HH:mm:ss.SSS z}] %p &lt;%c{1}&gt; %m%n"/>

is changed to:

<param name="ConversionPattern" value="[%d{dd-MMM-yyyy HH:mm:ss.SSS z}] %p <%c{1}> %m%n"/>

If you want to save a new version of the file, you need to ensure that the file is valid XML, which includes escaping the necessary characters.

"Authentication failed for user 'admin' from host 'localhost'. Reason: Username and/or password is null."

You must provide a password at installation time and then specify this password later on when attempting to log in to the management consoles.

1. When setting up your user account repository, use a Standalone Custom Registry. For more details, see the FileRegistrySample.java file in the WebSphere Information Center.
2. In particular, ensure that the users and groups files are in the correct format.
   For more details, see users.props file and groups.props file in the WebSphere Information Center.
   For example, following are sample users and groups configuration files:
   
   Example 1: myWebSphereUsers.txt

   # 5639-D57, 5630-A36, 5630-A37, 5724-D18
   # (C) COPYRIGHT International Business Machines Corp. 1997, 2005
   # All Rights Reserved * Licensed Materials - Property of IBM
   #
   # Format:
   # name:passwd:uid:gids:display name
   # where name = userId/userName of the user
   # passwd = password of the user
   # uid = uniqueId of the user
   # gid = groupIds of the groups that the user belongs to
   admin:admin:111:123:Admin User

   Example 2: myWebsphereGroups.txt

   # 5639-D57, 5630-A36, 5630-A37, 5724-D18
   # (C) COPYRIGHT International Business Machines Corp. 1997, 2003
   # All Rights Reserved * Licensed Materials - Property of IBM
   #
   # Format:
   # name:gid:users:display name
   # where name = groupId of the group
   # gid = uniqueId of the group
   # users = list of all the userIds that the group contains
   # display name = a (optional) display name for the group.
   admins:123:admin:Administrators

3. Next, you need to configure the Websphere Administrative console with the values that you have just set up in your user repository. To
   do so, in the console, select Security>Secure administration, applications, and infrastructure, then from the drop-down list in the table at the bottom of the page select Standalone custom registry, then click Configure.
4. In the Standalone custom registry, specify the following settings:

• Primary administrative username: for example, admin.
• Server identity that is stored in the repository: true.
• Server user ID or administrative user on a Version 6.0.x node: for example, admin.
• Password: for example, admin.
• Custom registry class name: com.ibm.websphere.security.FileRegistrySample.

5. Click the Custom properties link, then add the following new properties, which point to your users and groups configuration files described earlier, for example:

• groupsFile: C:\CapeClearProfile_Auth_WS_Full\Authn\myWebsphereGroups.txt
• usersFile: C:\CapeClearProfile_Auth_WS_Full\Authn\myWebsphereUsers.txt

6. Click Save master configuration.

Other Issues with Running or Restarting WebSphere Administrative Security on the Default Installed Profile

The keystore and certificates in the default profile installed by Cape Clear appear to be unusable. When you start up the Cape Clear profile, an error similar to the following is displayed:

WSKeyStore E CWPKI0033E: The keystore located at "C:/CapeClearProfile_Auth_WS_Full/HOSTNAME/CapeClear/config/cells/CapeClearCell/nodes/CapeClear/ltpa.jceks"
failed to load due to the following error: Keystore was tampered with, or password was incorrect.

As a workaround, copy the keystore, truststore, and ltps.jceks file from the IBM/WebSphere/AppServer/profiles/AppSrv01/config/cells/myhostNode01Cell/nodes/myhostNode01
WebSphere installation directory and place them in the following directory:

<CAPE_CLEAR_PROFILE>/CapeClear/config/cells/<HOSTNAME>CapeClearCell/nodes/CapeClear

Note: The default keystore, truststore, and JCEKS files are provided for development purposes only and should not be used for a production environment. When generating shared keystore (JCEKS) files for WebSphere, ensure that you use the IBM JDK, see SVR-3306.

2. The Configuration page is displayed as shown below. On this page, for Class loader mode, select Parent Last.

The correct class loader mode is: Application First and not Parent Last.