JAXM Reference Implementation 1.1 Release Notes
This release is based on the JAXM 1.1 API. The following list contains some
information about the implementation, known issues and bugs in this release.
An updated, online version of this file can be seen
here
.
- This release depends on the following components:
- 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.
The SAAJ reference implementation is known to cause problems with XML
digital signatures. This will be fixed in subsequent releases.