[JBoss JIRA] (JBWS-3833) @UseAsyncMethod doesn't seem to work on JBoss
by Tadayoshi Sato (JIRA)
[ https://issues.jboss.org/browse/JBWS-3833?page=com.atlassian.jira.plugin.... ]
Tadayoshi Sato updated JBWS-3833:
---------------------------------
Description:
I developed the following WS endpoint that uses {{@UseAsyncMethod}}:
{code:java}
@WebService(...)
public class GreetingServiceImpl implements GreetingService {
...
@WebMethod
@UseAsyncMethod
public String hello(String name) { ... }
public Future<HelloResponse> helloAsync(final String name, final AsyncHandler<HelloResponse> asyncHandler) { ... }
{code}
My expectation with {{@UseAsyncMethod}} is that whenever the {{hello()}} operation is invoked {{helloAsync()}} is eventually executed on JBoss (WildFly 8 or EAP 6). However, it really is not.
I tested the same endpoint by launching it using {{Endpoint.publish(...)}} as well and it works as expected, so I don't think it is not an issue with CXF itself but with JBoss WS integration.
Attached please see the complete reproducer project ({{async.zip}} for detail.
was:
I developed the following WS endpoint that uses {{@UseAsyncMethod}}:
{code:java}
@WebService(...)
public class GreetingServiceImpl implements GreetingService {
...
@WebMethod
@UseAsyncMethod
public String hello(String name) { ... }
public Future<HelloResponse> helloAsync(final String name, final AsyncHandler<HelloResponse> asyncHandler) { ... }
{code}
My expectation with {{@UseAsyncMethod}} is that whenever the {{hello()}} operation is invoked {{helloAsync()}} is eventually executed on JBoss (WildFly 8 or EAP 6). However, it really is not.
I tested the same endpoint by launching it using {{Endpoint.publish(...)}} as well and it works as expected, so I don't think it is not an issue with CXF itself but with JBoss WS integration.
Attached please see the complete reproducer project for detail.
> @UseAsyncMethod doesn't seem to work on JBoss
> ---------------------------------------------
>
> Key: JBWS-3833
> URL: https://issues.jboss.org/browse/JBWS-3833
> Project: JBoss Web Services
> Issue Type: Bug
> Components: jbossws-cxf
> Affects Versions: jbossws-cxf-4.3, jbossws-cxf-4.3.1
> Reporter: Tadayoshi Sato
> Attachments: async.zip
>
>
> I developed the following WS endpoint that uses {{@UseAsyncMethod}}:
> {code:java}
> @WebService(...)
> public class GreetingServiceImpl implements GreetingService {
> ...
> @WebMethod
> @UseAsyncMethod
> public String hello(String name) { ... }
> public Future<HelloResponse> helloAsync(final String name, final AsyncHandler<HelloResponse> asyncHandler) { ... }
> {code}
> My expectation with {{@UseAsyncMethod}} is that whenever the {{hello()}} operation is invoked {{helloAsync()}} is eventually executed on JBoss (WildFly 8 or EAP 6). However, it really is not.
> I tested the same endpoint by launching it using {{Endpoint.publish(...)}} as well and it works as expected, so I don't think it is not an issue with CXF itself but with JBoss WS integration.
> Attached please see the complete reproducer project ({{async.zip}} for detail.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[JBoss JIRA] (JBWS-3833) @UseAsyncMethod doesn't seem to work on JBoss
by Tadayoshi Sato (JIRA)
[ https://issues.jboss.org/browse/JBWS-3833?page=com.atlassian.jira.plugin.... ]
Tadayoshi Sato updated JBWS-3833:
---------------------------------
Description:
I developed the following WS endpoint that uses {{@UseAsyncMethod}}:
{code:java}
@WebService(...)
public class GreetingServiceImpl implements GreetingService {
...
@WebMethod
@UseAsyncMethod
public String hello(String name) { ... }
public Future<HelloResponse> helloAsync(final String name, final AsyncHandler<HelloResponse> asyncHandler) { ... }
{code}
My expectation with {{@UseAsyncMethod}} is that whenever the {{hello()}} operation is invoked {{helloAsync()}} is eventually executed on JBoss (WildFly 8 or EAP 6). However, it really is not.
I tested the same endpoint by launching it using {{Endpoint.publish(...)}} as well and it works as expected, so I don't think it is not an issue with CXF itself but with JBoss WS integration.
Attached please see the complete reproducer project {{async.zip}} for detail.
was:
I developed the following WS endpoint that uses {{@UseAsyncMethod}}:
{code:java}
@WebService(...)
public class GreetingServiceImpl implements GreetingService {
...
@WebMethod
@UseAsyncMethod
public String hello(String name) { ... }
public Future<HelloResponse> helloAsync(final String name, final AsyncHandler<HelloResponse> asyncHandler) { ... }
{code}
My expectation with {{@UseAsyncMethod}} is that whenever the {{hello()}} operation is invoked {{helloAsync()}} is eventually executed on JBoss (WildFly 8 or EAP 6). However, it really is not.
I tested the same endpoint by launching it using {{Endpoint.publish(...)}} as well and it works as expected, so I don't think it is not an issue with CXF itself but with JBoss WS integration.
Attached please see the complete reproducer project ({{async.zip}} for detail.
> @UseAsyncMethod doesn't seem to work on JBoss
> ---------------------------------------------
>
> Key: JBWS-3833
> URL: https://issues.jboss.org/browse/JBWS-3833
> Project: JBoss Web Services
> Issue Type: Bug
> Components: jbossws-cxf
> Affects Versions: jbossws-cxf-4.3, jbossws-cxf-4.3.1
> Reporter: Tadayoshi Sato
> Attachments: async.zip
>
>
> I developed the following WS endpoint that uses {{@UseAsyncMethod}}:
> {code:java}
> @WebService(...)
> public class GreetingServiceImpl implements GreetingService {
> ...
> @WebMethod
> @UseAsyncMethod
> public String hello(String name) { ... }
> public Future<HelloResponse> helloAsync(final String name, final AsyncHandler<HelloResponse> asyncHandler) { ... }
> {code}
> My expectation with {{@UseAsyncMethod}} is that whenever the {{hello()}} operation is invoked {{helloAsync()}} is eventually executed on JBoss (WildFly 8 or EAP 6). However, it really is not.
> I tested the same endpoint by launching it using {{Endpoint.publish(...)}} as well and it works as expected, so I don't think it is not an issue with CXF itself but with JBoss WS integration.
> Attached please see the complete reproducer project {{async.zip}} for detail.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[JBoss JIRA] (JBWS-3833) @UseAsyncMethod doesn't seem to work on JBoss
by Tadayoshi Sato (JIRA)
[ https://issues.jboss.org/browse/JBWS-3833?page=com.atlassian.jira.plugin.... ]
Tadayoshi Sato updated JBWS-3833:
---------------------------------
Attachment: async.zip
> @UseAsyncMethod doesn't seem to work on JBoss
> ---------------------------------------------
>
> Key: JBWS-3833
> URL: https://issues.jboss.org/browse/JBWS-3833
> Project: JBoss Web Services
> Issue Type: Bug
> Components: jbossws-cxf
> Affects Versions: jbossws-cxf-4.3, jbossws-cxf-4.3.1
> Reporter: Tadayoshi Sato
> Attachments: async.zip
>
>
> I developed the following WS endpoint that uses {{@UseAsyncMethod}}:
> {code:java}
> @WebService(...)
> public class GreetingServiceImpl implements GreetingService {
> ...
> @WebMethod
> @UseAsyncMethod
> public String hello(String name) { ... }
> public Future<HelloResponse> helloAsync(final String name, final AsyncHandler<HelloResponse> asyncHandler) { ... }
> {code}
> My expectation with {{@UseAsyncMethod}} is that whenever the {{hello()}} operation is invoked {{helloAsync()}} is eventually executed on JBoss (WildFly 8 or EAP 6). However, it really is not.
> I tested the same endpoint by launching it using {{Endpoint.publish(...)}} as well and it works as expected, so I don't think it is not an issue with CXF itself but with JBoss WS integration.
> Attached please see the complete reproducer project for detail.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[JBoss JIRA] (JBWS-3833) @UseAsyncMethod doesn't seem to work on JBoss
by Tadayoshi Sato (JIRA)
Tadayoshi Sato created JBWS-3833:
------------------------------------
Summary: @UseAsyncMethod doesn't seem to work on JBoss
Key: JBWS-3833
URL: https://issues.jboss.org/browse/JBWS-3833
Project: JBoss Web Services
Issue Type: Bug
Components: jbossws-cxf
Affects Versions: jbossws-cxf-4.3.1, jbossws-cxf-4.3
Reporter: Tadayoshi Sato
Attachments: async.zip
I developed the following WS endpoint that uses {{@UseAsyncMethod}}:
{code:java}
@WebService(...)
public class GreetingServiceImpl implements GreetingService {
...
@WebMethod
@UseAsyncMethod
public String hello(String name) { ... }
public Future<HelloResponse> helloAsync(final String name, final AsyncHandler<HelloResponse> asyncHandler) { ... }
{code}
My expectation with {{@UseAsyncMethod}} is that whenever the {{hello()}} operation is invoked {{helloAsync()}} is eventually executed on JBoss (WildFly 8 or EAP 6). However, it really is not.
I tested the same endpoint by launching it using {{Endpoint.publish(...)}} as well and it works as expected, so I don't think it is not an issue with CXF itself but with JBoss WS integration.
Attached please see the complete reproducer project for detail.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[JBoss JIRA] (JBWS-3792) JBossWS: wsdl:import always handled as relative location
by R Searls (JIRA)
[ https://issues.jboss.org/browse/JBWS-3792?page=com.atlassian.jira.plugin.... ]
R Searls commented on JBWS-3792:
--------------------------------
The proposed solution does not fully address the issue. When an app is
deployed the class that resolves a wsdl's 'wsdl:import' stmts is
org.apache.cxf.transport.TransportURIResolver.resolve which does not process
URLs but URIs.
> JBossWS: wsdl:import always handled as relative location
> --------------------------------------------------------
>
> Key: JBWS-3792
> URL: https://issues.jboss.org/browse/JBWS-3792
> 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
>
> Attachments: JBWS-3792_java.net.URL_proposal.patch
>
>
> As described in this thread: https://community.jboss.org/thread/240821
> wsdl:import directive seems to be always resolved as a relative location.
> For example, this statement:
> <wsdl:import namespace="http://foo.bar.com/foo.bar.Service" location="http://foo.bar.com/Service.svc?wsdl=wsdl0"/>
> May result in this URL being resolved:
> http://foo.bar.com/http://foo.bar.com/Service.svc?wsdl=wsdl0
> This prevents the WSDL file from being parsed.
> This behavior seems to originate from: org.jboss.ws.common.deployment.SOAPAddressWSDLParser, line 211 in v2.3.0.Final and current trunk:
> } else if (match(reader, WSDL_NS, IMPORT)) {
> final String location = reader.getAttributeValue(null, LOCATION);
> final String url = wsdlUrl.toString();
> final String newUrl = url.substring(0, url.lastIndexOf("/") + (location.startsWith("/") ? 0 : 1)) + location;
> if (!metadata.getImports().containsKey(newUrl)) {
> metadata.getImports().put(newUrl, false);
> }
> }
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[JBoss JIRA] (JBWS-3812) Incorrect value for ws-security.ut.validator
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/JBWS-3812?page=com.atlassian.jira.plugin.... ]
Alessio Soldano commented on JBWS-3812:
---------------------------------------
ok, can you paste a stacktrace please?
> Incorrect value for ws-security.ut.validator
> --------------------------------------------
>
> Key: JBWS-3812
> URL: https://issues.jboss.org/browse/JBWS-3812
> Project: JBoss Web Services
> Issue Type: Bug
> Components: jbossws-cxf
> Affects Versions: jbossws-cxf-4.2.4
> Reporter: John Ament
> Assignee: Alessio Soldano
> Fix For: jbossws-cxf-5.0
>
>
> I found a forum post indicating that this value should work, in my hunt to make security work in WildFly. https://community.jboss.org/thread/229071
> When you set the parameter ws-security.ut.validator in jaxws-endpoint-config.xml, the value that gets set is in fact the string value, e.g. com.mycompany.cxf.validators.MySpecialValidator
> CXF is expecting that this is an instantiated instance of the class, not a classname. It results in a ClassCastException. You can see here for reference: http://cxf.apache.org/docs/ws-securitypolicy.html look under Validator implementations.
> To work around this, you can register a custom InInterceptor and set the value in the message context. It's not ideal, but you could read the value from jaxws-endpoint-config.xml and instantiate that class, passing it back to the message context.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[JBoss JIRA] (JBWS-3812) Incorrect value for ws-security.ut.validator
by John Ament (JIRA)
[ https://issues.jboss.org/browse/JBWS-3812?page=com.atlassian.jira.plugin.... ]
John Ament commented on JBWS-3812:
----------------------------------
You set this value in jaxws-endpoint-config.xml
> Incorrect value for ws-security.ut.validator
> --------------------------------------------
>
> Key: JBWS-3812
> URL: https://issues.jboss.org/browse/JBWS-3812
> Project: JBoss Web Services
> Issue Type: Bug
> Components: jbossws-cxf
> Affects Versions: jbossws-cxf-4.2.4
> Reporter: John Ament
> Assignee: Alessio Soldano
> Fix For: jbossws-cxf-5.0
>
>
> I found a forum post indicating that this value should work, in my hunt to make security work in WildFly. https://community.jboss.org/thread/229071
> When you set the parameter ws-security.ut.validator in jaxws-endpoint-config.xml, the value that gets set is in fact the string value, e.g. com.mycompany.cxf.validators.MySpecialValidator
> CXF is expecting that this is an instantiated instance of the class, not a classname. It results in a ClassCastException. You can see here for reference: http://cxf.apache.org/docs/ws-securitypolicy.html look under Validator implementations.
> To work around this, you can register a custom InInterceptor and set the value in the message context. It's not ideal, but you could read the value from jaxws-endpoint-config.xml and instantiate that class, passing it back to the message context.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[JBoss JIRA] (JBWS-3812) Incorrect value for ws-security.ut.validator
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/JBWS-3812?page=com.atlassian.jira.plugin.... ]
Alessio Soldano edited comment on JBWS-3812 at 9/24/14 11:08 AM:
-----------------------------------------------------------------
John,
I'd need a reproducer for this, or at least some additional information and/or a stacktrace from where the string property value for the ut validator causes issue.
While the CXF documentation indeed says "Validator *instance*", most of the code dealing with those props is able to get the String value and use it to create an instance of the specified class name. When it comes to the ut.validator, in current CXF master that's processed in 3 points, in UsernameTokenInterceptor, WSS4JInInterceptor.CXFRequestData and WSS4JStaxInInterceptor. The first of the three is the only one that does not seem to be able to deal with a String value. I could simply fix that, but I'd need a testcase stressing this issue. I've tried modifying some of the systests in CXF sources to use a String value for custom ut validators, but could not reproduce the issue.
was (Author: asoldano):
John,
I'd need a reproducer for this, or at least some additional information and/or a stacktrace from where the string property value for the ut validator causes issue.
While the CXF documentation indeed says "Validator *instance*", the most of the code dealing with those props is able to get the String value and use it to create an instance of the specified class name. When it comes to the ut.validator, in current CXF master that's processed in 3 points, in UsernameTokenInterceptor, WSS4JInInterceptor.CXFRequestData and WSS4JStaxInInterceptor. The first of the three is the only one that does not seem to be able to deal with a String value. I could simply fix that, but I'd need a testcase stressing this issue. I've tried modifying some of the systests in CXF sources to use a String value for custom ut validators, but could not reproduce the issue.
> Incorrect value for ws-security.ut.validator
> --------------------------------------------
>
> Key: JBWS-3812
> URL: https://issues.jboss.org/browse/JBWS-3812
> Project: JBoss Web Services
> Issue Type: Bug
> Components: jbossws-cxf
> Affects Versions: jbossws-cxf-4.2.4
> Reporter: John Ament
> Assignee: Alessio Soldano
> Fix For: jbossws-cxf-5.0
>
>
> I found a forum post indicating that this value should work, in my hunt to make security work in WildFly. https://community.jboss.org/thread/229071
> When you set the parameter ws-security.ut.validator in jaxws-endpoint-config.xml, the value that gets set is in fact the string value, e.g. com.mycompany.cxf.validators.MySpecialValidator
> CXF is expecting that this is an instantiated instance of the class, not a classname. It results in a ClassCastException. You can see here for reference: http://cxf.apache.org/docs/ws-securitypolicy.html look under Validator implementations.
> To work around this, you can register a custom InInterceptor and set the value in the message context. It's not ideal, but you could read the value from jaxws-endpoint-config.xml and instantiate that class, passing it back to the message context.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[JBoss JIRA] (JBWS-3812) Incorrect value for ws-security.ut.validator
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/JBWS-3812?page=com.atlassian.jira.plugin.... ]
Alessio Soldano commented on JBWS-3812:
---------------------------------------
John,
I'd need a reproducer for this, or at least some additional information and/or a stacktrace from where the string property value for the ut validator causes issue.
While the CXF documentation indeed says "Validator *instance*", the most of the code dealing with those props is able to get the String value and use it to create an instance of the specified class name. When it comes to the ut.validator, in current CXF master that's processed in 3 points, in UsernameTokenInterceptor, WSS4JInInterceptor.CXFRequestData and WSS4JStaxInInterceptor. The first of the three is the only one that does not seem to be able to deal with a String value. I could simply fix that, but I'd need a testcase stressing this issue. I've tried modifying some of the systests in CXF sources to use a String value for custom ut validators, but could not reproduce the issue.
> Incorrect value for ws-security.ut.validator
> --------------------------------------------
>
> Key: JBWS-3812
> URL: https://issues.jboss.org/browse/JBWS-3812
> Project: JBoss Web Services
> Issue Type: Bug
> Components: jbossws-cxf
> Affects Versions: jbossws-cxf-4.2.4
> Reporter: John Ament
> Assignee: Alessio Soldano
> Fix For: jbossws-cxf-5.0
>
>
> I found a forum post indicating that this value should work, in my hunt to make security work in WildFly. https://community.jboss.org/thread/229071
> When you set the parameter ws-security.ut.validator in jaxws-endpoint-config.xml, the value that gets set is in fact the string value, e.g. com.mycompany.cxf.validators.MySpecialValidator
> CXF is expecting that this is an instantiated instance of the class, not a classname. It results in a ClassCastException. You can see here for reference: http://cxf.apache.org/docs/ws-securitypolicy.html look under Validator implementations.
> To work around this, you can register a custom InInterceptor and set the value in the message context. It's not ideal, but you could read the value from jaxws-endpoint-config.xml and instantiate that class, passing it back to the message context.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[JBoss JIRA] (JBWS-3832) Different default Spring descriptor name for creating client and server Bus instances
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/JBWS-3832?page=com.atlassian.jira.plugin.... ]
Alessio Soldano updated JBWS-3832:
----------------------------------
Attachment: JBWS-3832.diff
Preliminary patch idea
> Different default Spring descriptor name for creating client and server Bus instances
> -------------------------------------------------------------------------------------
>
> Key: JBWS-3832
> URL: https://issues.jboss.org/browse/JBWS-3832
> Project: JBoss Web Services
> Issue Type: Feature Request
> Components: jbossws-cxf
> Reporter: Alessio Soldano
> Fix For: jbossws-cxf-5.0
>
> Attachments: JBWS-3832.diff
>
>
> When Spring integration is enabled, the CXF Bus factory uses the same name to lookup descriptor defining the bus to be used for clients or endpoints (usually cxf.xml). Generally speaking, we might want to have the JAX-WS clients end up always using different Spring descriptors then any other consumer of the CXF Spring Bus factory.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months