[JBoss JIRA] (JBWS-3848) Optimize HandlerChainSortInterceptor
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/JBWS-3848?page=com.atlassian.jira.plugin.... ]
Alessio Soldano updated JBWS-3848:
----------------------------------
Fix Version/s: jbossws-cxf-4.3.2
> Optimize HandlerChainSortInterceptor
> ------------------------------------
>
> Key: JBWS-3848
> URL: https://issues.jboss.org/browse/JBWS-3848
> Project: JBoss Web Services
> Issue Type: Enhancement
> Components: jbossws-cxf
> Reporter: Alessio Soldano
> Assignee: Alessio Soldano
> Fix For: jbossws-cxf-4.3.2, jbossws-cxf-5.0
>
>
> HandlerChainSortInterceptor needs to be optimized to avoid setting the handler chain after having sorted it if the sort operation actually did nothing relevant.
> We should detect if we really need to sort (because of PRE/POST handlers) and relax the sorting requirement (we only care about the PRE/POST thing, not about the internal order of user handlers).
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (JBWS-3847) Memory leak in JBoss WS CXF Client's HandlerChainSortInterceptor
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBWS-3847?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated JBWS-3847:
------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1155490, https://bugzilla.redhat.com/show_bug.cgi?id=1158330 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1155490)
> Memory leak in JBoss WS CXF Client's HandlerChainSortInterceptor
> ----------------------------------------------------------------
>
> Key: JBWS-3847
> URL: https://issues.jboss.org/browse/JBWS-3847
> Project: JBoss Web Services
> Issue Type: Bug
> Components: jbossws-cxf
> Affects Versions: jbossws-cxf-4.3
> Reporter: Tadayoshi Sato
> Fix For: jbossws-cxf-5.0
>
>
> {{HandlerChainSortInterceptor.handleMessage(Message)}} sorts and sets JAX-WS handlers every time it handles a SOAP message:
> {code:java}
> public void handleMessage(Message message) throws Fault
> {
> if (binding != null) {
> @SuppressWarnings("rawtypes")
> List<Handler> list = binding.getHandlerChain();
> if (list != null && !list.isEmpty()) {
> Collections.sort(list, comparator);
> binding.setHandlerChain(list);
> }
> }
> }
> {code}
> However, inside the {{org.apache.cxf.jaxws.binding.AbstractBindingImpl}} and {{org.apache.cxf.jaxws.support.JaxWsEndpointImpl}} implementations the handler chain is not reset every time but piled up with interceptors, which leads to subtle but indefinite memory leak in JBoss WS CXF client.
> Furthermore, {{org.apache.cxf.jaxws.support.JaxWsEndpointImpl}} holds the interceptors as a kind of {{java.util.concurrent.CopyOnWriteArrayList}}. So modifying the growing list of interceptors per each message should cause a growing performance drawback, which is also not a good implementation.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (JBWS-3851) WSDL publisher incorrectly attempt to publish external HTTPS schema import
by R Searls (JIRA)
[ https://issues.jboss.org/browse/JBWS-3851?page=com.atlassian.jira.plugin.... ]
R Searls commented on JBWS-3851:
--------------------------------
Code change checked in.
https://svn.jboss.org/repos/jbossws/common/trunk (version 3.0.0-SNAPSHOT)
Committed revision 19034.
--- diff
--- src/main/java/org/jboss/ws/common/utils/AbstractWSDLFilePublisher.java (revision 19033)
+++ src/main/java/org/jboss/ws/common/utils/AbstractWSDLFilePublisher.java (working copy)
@@ -207,7 +207,7 @@
final String ln = childElement.getLocalName();
if ("import".equals(ln) || "include".equals(ln)) {
String schemaLocation = childElement.getAttribute("schemaLocation");
- if (schemaLocation.length() > 0 && schemaLocation.startsWith("http://") == false)
+ if (schemaLocation.length() > 0 && schemaLocation.startsWith("http://") == false && schemaLocat
ion.startsWith("https://") == false)
{
// infinity loops prevention
if (!published.contains(schemaLocation))
> WSDL publisher incorrectly attempt to publish external HTTPS schema import
> --------------------------------------------------------------------------
>
> Key: JBWS-3851
> URL: https://issues.jboss.org/browse/JBWS-3851
> Project: JBoss Web Services
> Issue Type: Bug
> Components: jbossws-cxf
> Affects Versions: jbossws-cxf-4.3
> Reporter: R Searls
> Assignee: R Searls
> Fix For: jbossws-cxf-5.0
>
>
> WSDL publisher incorrectly attempt to publish external HTTPS schema import
> See lone 210 in src/main/java/org/jboss/ws/common/utils/AbstractWSDLFilePublisher.java
> repo https://svn.jboss.org/repos/jbossws/common/trunk
> 210 if (schemaLocation.length() > 0 && schemaLocation.startsWith("http://")
> This should be
> 210 if (schemaLocation.length() > 0 && schemaLocation.startsWith("http://") == false && schemaLocation.startsWith("https://") == false)
> This is related to https://issues.jboss.org/browse/JBWS-3827
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (JBWS-3827) WSDL publisher incorrectly attempt to publish external HTTPS import
by R Searls (JIRA)
[ https://issues.jboss.org/browse/JBWS-3827?page=com.atlassian.jira.plugin.... ]
R Searls commented on JBWS-3827:
--------------------------------
Marc found a like issue with schema import. Created a new jira, https://issues.jboss.org/browse/JBWS-3851 to check-in this fix
> WSDL publisher incorrectly attempt to publish external HTTPS import
> -------------------------------------------------------------------
>
> Key: JBWS-3827
> URL: https://issues.jboss.org/browse/JBWS-3827
> Project: JBoss Web Services
> Issue Type: Bug
> Components: jbossws-cxf
> Affects Versions: jbossws-cxf-4.3
> Reporter: Marc H.
> Assignee: R Searls
> Fix For: jbossws-cxf-5.0
>
>
> In org.jboss.ws.common.utils.AbstractWSDLFilePublisher, the condition used to detect external import looks like this:
> // its an external import, don't publish locally
> if (locationURI.startsWith("http://") == false) { ... }
> This does not take in account import done over other protocols such as HTTPS. Deploying such WSDL will fail since jboss will try to resolve an absolute URL against the current deployment unit.
> Simply adapting the test to include "https://" seems effective (not sure if it truly satisfies all use cases however).
> This was only tested in version 2.2.3 Final of jboss-ws-common but those lines are still in trunk...
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month