[
https://jira.jboss.org/jira/browse/JBESB-2301?page=com.atlassian.jira.plu...
]
Stefano Maestri commented on JBESB-2301:
----------------------------------------
Regarding last kevin's comment. I have recalled why method name is used instead of
soapAction: from JAXWS specification:
"Each wsdl:operation in a wsdl:portType is mapped to a Java method in the
corresponding Java service
endpoint interface.
(Method naming): In the absence of customizations, the name of a mapped Java method
MUST be the value of the name attribute of the wsdl:operation element mapped according to
the rules
described in section 2.8.
An application MAY customize this mapping using the jaxws:method binding declaration
defined in
section 8.7.3.
October 20, 2006 JAX-WS 2.0 11
Chapter 2. WSDL 1.1 to Java Mapping
(javax.jws.WebMethod required): A mapped Java method MUST be annotated with a
javax.jws.WebMethod annotation. The annotation MAY be omitted if all its properties would
have the
default values.
The WS-I Basic Profile[18] R2304 requires that operations within a wsdl:portType have
unique values
for their name attribute so mapping of WS-I compliant WSDL descriptions will not generate
Java interfaces
with overloaded methods"
This part assure that * method name is unique (no overloading method) * in generated
classes. Moreover since operation name (that is also the mathod name) is the only thing we
have in generated classes because soap action is not mandatory and is legal to haven't
it specified.
So the key of the map is correctly the method name, the *BAD THING* is the name of the
attribute I have used in config files.
It take sometime to recall the reasons of this choice, but this part of wise has been
coded years ago and no more changed (at least since donation).
The only case where JAX-WS permit method name overload is using binding files, but they
aren't supported by wise included in ESB 4.4 (they are supported by Wise-1.0 and we
are investigating about in linked issue
Handle wise threading/pooling
-----------------------------
Key: JBESB-2301
URL:
https://jira.jboss.org/jira/browse/JBESB-2301
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Web Services
Affects Versions: 4.4 CP1
Reporter: Kevin Conner
Assignee: Daniel Bevenius
Fix For: 4.4 CP2
The current wise codebase (in ESB4.4 and SOA 4.3) is not thread safe and needs some
changes made. There are also issues with classloading and clearing of clients.
The current WSDynamicClientFactory singleton contains a Map which references the
WSDynamicClient instances using a name. This map is current implemented as a HashMap but
is accessed concurrently.
In addition, the name used as the key is specified within the configuration so there is a
possibility of clashes with other deployments, especially as this is used to create
temporary files on the filesystem.
Instantiation
-------------
The factory checks this map to see whether a specified client exists and, if not present,
creates one but it does this without synchronizing and can lead to multiple threads
clashing during the construction of the same client. In addition the context classloader
of the first deployment to create the client will be used to create the classes and this
can leak into other deployments.
Invocation
----------
The invocation of the service is handled through the jax-ws Port api and this is not
thread-safe. The wise codebase shares the same client instance with multiple threads and,
therefore, can suffer from concurrency problems.
Cleanup
-------
The clearCache method on the factory singleton removes *all* clients from the map and is
not thread-safe.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira