Home
 

User login

 
 

Navigation

 
 

Events

« May 2008
SunMonTueWedThuFriSat
123
45678910
11121314151617
18192021222324
25262728293031
 

Cape Clear Server 7.5 Release Notes

The latest Cape Clear  Server 7.5.1 Release Notes , are available here.

This page lists the known issues in Cape Clear 7.5.0 and the issues fixed since 7.0.3.

Known Issues in Cape Clear Server 7.5

The following table lists the issues known issues in Cape Clear Server 7.5:


Issue Summary:

Project name incorrect in the 'WS-Security within an Assembly' sample help page text
ID: SVR-3039
Status: Unresolved
Component: Documentation - Other
Description: Step 2 of the 'WS-Security within an Assembly' sample help page states that you should run the AssemblyWithSOAPBindingTest.java from the BPELHelloWorldSecurityAssemblies project. This is incorrect. The project in which to find this file is called BPELHelloWorldSecurityAssembliesClient. Note that both projects exist in the sample.


Issue Summary:

The Service Request Size information is not available in the JMX statistics pages
ID: SVR-2995
Status: Unresolved
Component: Documentation - Release Notes - Issues Outstanding
Description: The serviceMinRequestSize, serviceMaxRequestSize and serviceAverageRequestSize always equal 0 in the JMX console and on the Cape Clear Manager statistics Web page. This happens because the Service Request Size information is not available in Cape Clear 7.5.0.


Issue Summary:

The Adapters Template page in Cape Clear Manager displays JMS adapter templates, which are Retired Features
ID: SVR-2239
Status: Unresolved
Component: Administration - Manager
Description: The Adapters Template page in Cape Clear Manager displays JMS adapter templates, which are Retired Features. The following items should be removed from the Cape Clear Manager JSPs:

* 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


Issue Summary:

Configuring WS-RM
ID: SVR-2213
Status: Unresolved
Component: Transports - WS-RM
Description: When configuring the WS-RM Source transport in Server, ensure that the values selected for the following configuration properties are the same:

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


Issue Summary:

"java.lang.OutOfMemoryError: PermGen space failure" when editing Orchestration manager web.xml
ID: SVR-2171
Status: Unresolved
Component: Administration - Orchestration Manager
Description: Editing the Orchestration Manager web.xml file for a running server will lead to a redeployment of the Orchestration manager web application. That redeployment may lead to a "java.lang.OutOfMemoryError: PermGen space failure"

The most common cause for that error is that you simply don't have enough space to load up all your classes. Use the param '-XX:MaxPermSize=128m' to increase the memory available.


Issue Summary:

Cluster members must not be started together
ID: SVR-1917
Status: Unresolved
Component: Runtime -BPEL Runtime
Description: To ensure that a cluster starts up successfully, servers should be brought up one by one, and not all at once. This is to allow the application servers and Cape Clear to manage the initial cluster co-ordination in a controlled way and also to ensure that each server in the cluster has started up successully before other members join.


Issue Summary:

Authentication Trusted Endpoint Interceptor Issue
ID: SVR-1902
Status: Unresolved
Component: Interceptors
Description: If an Authentication Trusted Endpoint Interceptor is attached to a Web service using Cape Clear Manager, it is configured with the location of the file containing the list of trusted endpoints and associated caller principals. The default value for this configuration property (endpoint.file.name) is the relative path conf/trustedendpoints.xml. The documentation correctly indicates that the interceptor should be looking for this file relative to the WEB-INF directory of the deployed Server WAR file.

However, the interceptor incorrectly attempts to locate this file relative to the directory $CAPE_HOME/Server. To avoid this problem, the value of the property endpoint.file.name should be the absolute file path to the trustedendpoints.xml file. In the case where Server is deployed in JBoss, this would be $CAPE_HOME/Server/jboss-4.0.2/server/default_or_all/deploy/ccx.war/WEB-INF/conf/trustedendpoints.xml.


Issue Summary:

JMS transports defined in Cape Clear Manager cannot handle spaces in filenames (classpath issue)
ID: SVR-1885
Status: Unresolved
Component: Transports - JMS
Description: If you configure a JAR for a JMS transport with paths that contain spaces, an error will be raised. An example error is shown below. The underlying cause is a ClassNotFoundException due to an error in processing the classpath.

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


Issue Summary:

Changing log settings using Cape Clear Manager causes parsing error at Server startup
ID: SVR-1873
Status: Unresolved
Component: Administration - Manager
Description: In the Cape Clear Manager Log Settings page for Server, when you click Save, changes are saved but if special characters are present in the log4j.xml file, these characters are not escaped. For example, the character &lt; that is in the original log4j.xml file is saved as "<" and "&gt;" is saved as ">". Therefore, the next line if in the original log4j.xml file:

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


Issue Summary:

Topic Transports fail to read all messages when there is high load
ID: SVR-1144
Status: Unresolved
Component: Runtime -BPEL Runtime
Description: We do not recommended the use of the JMS server transport to subscribe to JMS topics. The existing support is not production strength. JMS server transports that read from JMS queues are safe.


Issue Summary:

Keystore password is "capeconnect" instead of the password set in the installer
ID: SVR-381
Status: Unresolved
Component: Command Utilities
Description: When the gen-key tool is run, you are prompted for a keystore password. The password is "capeconnect" regardless of what was specified during installation.

 

Issues Fixed Since Cape Clear Server 7.0.3

The following table lists the issues fixed in Cape Clear Server 7.5:
Issue Summary: BPEL timer events should deal in UTC (Zulu time) to avoid daylight savings switch over issues
ID: SVR-2269
Component: Documentation - Release Notes - Issues Outstanding
Description: There is a bug in the
way we handle duration based alarms and waits that start before the
switch over time for daylight savings and that expire afterwards.
Currently these calculations are done using local time and disregard
the time changeover.
Deadline based alarms and waits are not affected by this issue.

Example:
Imagine that clocks go forward 1 hour at 1:00am.
If we start a wait of duration 1 hour at 0:30am, we will calculate that
the wait should expire at 1:30am. At 01:00, the system clock goes
forward 1 hour and the wait is now treated as expired. That is, the
wait only actually lasts 30 minutes.

When clocks go forward 1 hour, we will expire alarms and waits up
to 1 hour too early. When clocks go back 1 hour, we will expire them up
to 1 hour too late.

Issue Summary: Faults returned to JMS transport are discarded if jms.drop.noreplyto is set to true
ID: SVR-2005
Component: Transports - JMS
Description: If an exception occurs
during the processing of a request message, the JMS transport will
silently drop the returned Fault if JMSReplyTo is not set and if the
jms.drop.noreplyto configuration property is set to true in the app
descriptor.