JAXM Reference Implementation Release Notes.

JAXM Reference Implementation Release Notes

This release is based on the JAXM 1.0 API. The following list contains some information about the implementation, known issues and bugs in this release.

This release depends on the following components:

DOM4J (1.1 and upwards are known to work)
Log4J (1.1.3)
JAXP (1.2-ea1)
JavaMail^TM API (1.1.3 and 1.2) and JavaBeans^TM Activation Framework (JAF)

The messaging provider supports the mandatory parts of the EBXML specification as a profile. The local provider generates and consumes plain SOAP messages.
The release implements the HTTP/SOAP binding.
To get access to the JAXM provider web application or service, the following line needs to be added to the tomcat-users.xml file:

<user name="jaxm-provideradmin" password="changeme" roles="provider"/>

Creating a ProviderConnection object from the ProviderConnectionFactory object does not initialize the per-client state on the provider. The current behavior is that the per-client state is initialized on the first client-initiated interaction, that is, when the methods send or getMetaData are called, as opposed to when a ProviderConnection object is created. This delayed initialization is a bug that affects pure receiver servlets. The workaround is to invoke the ProviderConnection.getMetaData method in the Servlet's init method.
[Does NOT apply to users of the Java Web Services Developer Pack]. If you are configuring JAXM manually to run on Tomcat 3.x as opposed to using JAXM from the Java Web Service Developer Pack, the provider needs to be up and running (in a separate instance of a servlet container) before clients can initiate connections to it from the init method of the client servlet. This is needed because as part of the initialization of a connection, an HTTP post is done to the provider with the client state. If the provider is running in the same instance of the servlet container, the servlet container does not start listening on a port until all of the servlets have been initialized.
[For Java Web Services Developer Pack Users]. The JAXM provider and the provider admin webapps run as "services" under the JWSDP. All services listen to requests on port 8081 by default.
When delivery of a message fails, the provider tries to resend it. The number of retries is determinted by the retry limit configured for the provider, with the default maximum being 100. When Tomcat is restarted, the provider will first try to deliver the persistent messages used in the previous Tomcat run. This may cause a message or exception similar to "Provider.MessageProcessor Retrying because .... " to appear until the maximum number of retries has been reached. If this problem persists, try deleting the directory where persistent messages are stored ("ebxml" for the remote sample). You may also want to reconfigure the provider so that it has a lower retry limit.