[JBoss JIRA] (JBWS-3797) Let @WebContext(virtualHost...) affect endpoint address
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/JBWS-3797?page=com.atlassian.jira.plugin.... ]
Alessio Soldano updated JBWS-3797:
----------------------------------
Assignee: Jim Ma
> Let @WebContext(virtualHost...) affect endpoint address
> -------------------------------------------------------
>
> Key: JBWS-3797
> URL: https://issues.jboss.org/browse/JBWS-3797
> Project: JBoss Web Services
> Issue Type: Feature Request
> Components: jbossws-cxf, jbossws-integration
> Reporter: Alessio Soldano
> Assignee: Jim Ma
> Fix For: jbossws-cxf-5.0
>
>
> When @WebContext(virtualHost=...) is specified, the referenced virtualHost name should be usable to get the corresponding port (from the web layer, through the (JBoss)WebMetadata attached to deployment) and modify the endpoint address accordingly (in EndpointAddressDeploymentAspect).
> This likely require some additional functionalities from the container web layer to get the port for a given virtual host.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
10 years
[JBoss JIRA] (JBWS-3797) Let @WebContext(virtualHost...) affect endpoint address
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/JBWS-3797?page=com.atlassian.jira.plugin.... ]
Alessio Soldano commented on JBWS-3797:
---------------------------------------
Jim, can this be marked as solved?
> Let @WebContext(virtualHost...) affect endpoint address
> -------------------------------------------------------
>
> Key: JBWS-3797
> URL: https://issues.jboss.org/browse/JBWS-3797
> Project: JBoss Web Services
> Issue Type: Feature Request
> Components: jbossws-cxf, jbossws-integration
> Reporter: Alessio Soldano
> Fix For: jbossws-cxf-5.0
>
>
> When @WebContext(virtualHost=...) is specified, the referenced virtualHost name should be usable to get the corresponding port (from the web layer, through the (JBoss)WebMetadata attached to deployment) and modify the endpoint address accordingly (in EndpointAddressDeploymentAspect).
> This likely require some additional functionalities from the container web layer to get the port for a given virtual host.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
10 years
[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 commented on JBWS-3847:
-----------------------------------------------
baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1158330|https://bugzilla.redhat.com/show_bug.cgi?id=1158330] from ASSIGNED to MODIFIED
> 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
> Assignee: Alessio Soldano
> Fix For: jbossws-cxf-4.3.2, jbossws-cxf-5.0.0.Beta2
>
>
> {{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.8#6338)
10 years
[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 commented on JBWS-3847:
-----------------------------------------------
baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1158330|https://bugzilla.redhat.com/show_bug.cgi?id=1158330] from NEW to ASSIGNED
> 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
> Assignee: Alessio Soldano
> Fix For: jbossws-cxf-4.3.2, jbossws-cxf-5.0.0.Beta2
>
>
> {{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.8#6338)
10 years
[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 commented on JBWS-3847:
-----------------------------------------------
Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1155490|https://bugzilla.redhat.com/show_bug.cgi?id=1155490] from POST to MODIFIED
> 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
> Assignee: Alessio Soldano
> Fix For: jbossws-cxf-4.3.2, jbossws-cxf-5.0.0.Beta2
>
>
> {{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.8#6338)
10 years
[JBoss JIRA] (JBWS-3838) Predefined configuration handlers executing in different order when server is restarted
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBWS-3838?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JBWS-3838:
-----------------------------------------------
Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1153960|https://bugzilla.redhat.com/show_bug.cgi?id=1153960] from POST to MODIFIED
> Predefined configuration handlers executing in different order when server is restarted
> ---------------------------------------------------------------------------------------
>
> Key: JBWS-3838
> URL: https://issues.jboss.org/browse/JBWS-3838
> Project: JBoss Web Services
> Issue Type: Bug
> Components: jbossws-cxf
> Affects Versions: jbossws-cxf-4.3
> Reporter: david.boeren
> Assignee: Alessio Soldano
> Fix For: jbossws-cxf-4.3.2, jbossws-cxf-5.0.0.Beta2
>
>
> Handler order can change after a reboot, which causes problems when one handler depends on the action of another.
> * Description of the problem
> The flow is basically the following:
> 1) the container model is parsed; it can include jaxws configs, which are composed
> of jaxws handler chains, which in turn has one or multiple jaxws handlers
> 2) we have add operations for each jaxws handler and jaxws handler
> chain. Each of them starts a service, which builds up the corresponding
> metadata to be later used by jbossws; proper dependencies are set
> between those services, so that for instance the service for a handler
> chain waits for all its handlers' services.
> 3) when the service for the handler chain runs, it gets the info from
> the handler services and them in the chain metadata. This is where I get
> unpredictable ordering, as the handler services are run in parallel
> * Solution
> The idea is that we need to derive the handlers' order from the add operation steps, which are executed in the same order they're created in the parser.
> Brian also suggests to use the OperationContext.attach(...) API to pass data between handler invocations within an overall operation execution. All ws subsystem ops during boot are executed as steps within an overall operation. The API works like the attachment stuff that's used a lot in DeploymentUnitProcessors.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
10 years
[JBoss JIRA] (JBWS-3842) Cannot boot server with 2+ handlers in the same predefined configuration handler chain
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBWS-3842?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JBWS-3842:
-----------------------------------------------
Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1153954|https://bugzilla.redhat.com/show_bug.cgi?id=1153954] from POST to MODIFIED
> Cannot boot server with 2+ handlers in the same predefined configuration handler chain
> --------------------------------------------------------------------------------------
>
> Key: JBWS-3842
> URL: https://issues.jboss.org/browse/JBWS-3842
> Project: JBoss Web Services
> Issue Type: Bug
> Components: jbossws-cxf, jbossws-integration
> Affects Versions: jbossws-cxf-4.3
> Reporter: Alessio Soldano
> Assignee: Alessio Soldano
> Fix For: jbossws-cxf-4.3.2, jbossws-cxf-5.0.0.Beta2
>
>
> Commit https://github.com/wildfly/wildfly/commit/e32f27d433ad3da41ef042f1ad9b950... introduced a regressions when having multiple handlers in the same handler-chain within one of the pre-defined configuration in the webservices subsystem:
> {noformat}
> 5:49:24,653 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.ws.endpoint-config.Recording-Endpoint-Config.pre-handler-chain.recording-handlers: org.jboss.msc.service.StartException in service jboss.ws.endpoint-config.Recording-Endpoint-Config.pre-handler-chain.recording-handlers: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_60]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_60]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_60]
> Caused by: org.jboss.msc.inject.InjectionException: Value already set for this injector
> at org.jboss.msc.inject.RetainingInjector.inject(RetainingInjector.java:50) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.as.webservices.dmr.ListInjector.inject(ListInjector.java:23)
> at org.jboss.msc.inject.CastingInjector.inject(CastingInjector.java:55) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl.doInject(ServiceControllerImpl.java:1672) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl.access$2000(ServiceControllerImpl.java:51) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.performInjections(ServiceControllerImpl.java:1917) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1876) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> ... 3 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
10 years
[JBoss JIRA] (JBWS-3109) Global handler to intercept/observe inbound/outbound messages
by Vlastimil Eliáš (JIRA)
[ https://issues.jboss.org/browse/JBWS-3109?page=com.atlassian.jira.plugin.... ]
Vlastimil Eliáš updated JBWS-3109:
----------------------------------
Comment: was deleted
(was: The third way that you just can to enhance the speed of the computer will be by disabling any start up programs on windows. For have many of the automatic startup items then skin doctor slow down the good speed of pc. That means that by disabling unwanted programs you will end at the top of the faster boot up as very fewer programs are open.
ie repair http://unemploymentclaims.com/wp-content/Internet-Explorer-restore/)
> Global handler to intercept/observe inbound/outbound messages
> -------------------------------------------------------------
>
> Key: JBWS-3109
> URL: https://issues.jboss.org/browse/JBWS-3109
> Project: JBoss Web Services
> Issue Type: Feature Request
> Components: jbossws-integration
> Reporter: Gary Brown
> Assignee: Alessio Soldano
> Fix For: jbossws-cxf-4.1.0.Beta2
>
>
> Although individual web services can be configured to use JAX-WS handlers to intercept messages, it would be useful to be able to define a 'global' (server wide) handler that could intercept messages inbound and outbound from any deployed web services, regardless of the web service stack in use.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
10 years
[JBoss JIRA] (JBWS-3109) Global handler to intercept/observe inbound/outbound messages
by Anonymous (JIRA)
[ https://issues.jboss.org/browse/JBWS-3109?page=com.atlassian.jira.plugin.... ]
Anonymous commented on JBWS-3109:
---------------------------------
The third way that you just can to enhance the speed of the computer will be by disabling any start up programs on windows. For have many of the automatic startup items then skin doctor slow down the good speed of pc. That means that by disabling unwanted programs you will end at the top of the faster boot up as very fewer programs are open.
ie repair http://unemploymentclaims.com/wp-content/Internet-Explorer-restore/
> Global handler to intercept/observe inbound/outbound messages
> -------------------------------------------------------------
>
> Key: JBWS-3109
> URL: https://issues.jboss.org/browse/JBWS-3109
> Project: JBoss Web Services
> Issue Type: Feature Request
> Components: jbossws-integration
> Reporter: Gary Brown
> Assignee: Alessio Soldano
> Fix For: jbossws-cxf-4.1.0.Beta2
>
>
> Although individual web services can be configured to use JAX-WS handlers to intercept messages, it would be useful to be able to define a 'global' (server wide) handler that could intercept messages inbound and outbound from any deployed web services, regardless of the web service stack in use.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
10 years