[JBoss JIRA] (JBWS-3832) Different default Spring descriptor name for creating client and server Bus instances
by Roberto Polli (JIRA)
[ https://issues.jboss.org/browse/JBWS-3832?page=com.atlassian.jira.plugin.... ]
Roberto Polli updated JBWS-3832:
--------------------------------
Attachment: JBWS-3832-TEST_DRAFT.patch
Although it succeeds, I see the followinf exception on screen.
{code}
Concurrency config is parallel='classes', perCoreThreadCount=true, threadCount=2, useUnlimitedThreads=false
org.jboss.test.ws.jaxws.cxf.in_container_client.CustomBusServletTestCase(org.jboss.test.ws.jaxws.cxf.in_container_client.CustomBusServletTestCase$3)java.lang.Exception: "JBAS014803: Duplicate resource [(\"system-property\" => \"org.jboss.ws.cxf.jaxws-client.bus.selector\")]"
at org.jboss.as.webservices.deployer.RemoteDeployer.checkResult(RemoteDeployer.java:470)
at org.jboss.as.webservices.deployer.RemoteDeployer.applyUpdate(RemoteDeployer.java:457)
at org.jboss.as.webservices.deployer.RemoteDeployer.setSystemProperty(RemoteDeployer.java:442)
at org.jboss.wsf.test.JBossWSTestHelper.setSystemProperty(JBossWSTestHelper.java:396)
at org.jboss.test.ws.jaxws.cxf.in_container_client.CustomBusServletTestCase$3.setUp(CustomBusServletTestCase.java:85)
at org.jboss.wsf.test.JBossWSTestSetup$1.protect(JBossWSTestSetup.java:140)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at org.jboss.wsf.test.JBossWSTestSetup.run(JBossWSTestSetup.java:148)
at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:24)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Running org.jboss.test.ws.jaxws.cxf.in_container_client.ServletTestCase
{code}
> 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-TEST_DRAFT.patch, 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, 3 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:
--------------------------------
This is not a bug. There are a couple of reasons why. One, SOAPAddressWSDLParser
is not called during the deployment process, the time when imported wsdl
and schema files are processed. A similar bug was filed, https://issues.jboss.org/browse/JBWS-3571 and closed as "WON'T FIX" for the same reason.
Two, the namespace attribute of the "wsdl:import" and schema import is not used
in locating the file. It is for "targetNamespace" identification only.[1]
The attribute location and schemaLocation respectively are
used for file location. It is standard practice that, "WSDL files are located
relative to the root of the module and are typically located in the wsdl directory
that is co-located with the module."[2] Directory META-INF/wsdl for EJB jar [3] and
directory WEB-INF/wsdl [4] for WAR archives. In addition imported and included
documents of wsdl and schema files are co-located relative to the wsdl directory.
JBossWs provides a custom resolver (org.jboss.wsf.stack.cxf.resolver.JBossWSResourceResolver)
to find such config files in a deployed EE archive. 6 tests have been added to test
representative wsdl:import scenarios.[5]
[1] http://www.w3.org/TR/wsdl#_Toc492291093 , 3.1.1.1 namespace attribute information item
[2] Web Services for Java EE, Version 1.4, section 5.4 Packaging
[3] Web Services for Java EE, Version 1.4, section 5.4.2 EJB Module Packaging
[4] Web Services for Java EE, Version 1.4, section 5.4.3 Web Module Packaging
[5] https://svn.jboss.org/repos/jbossws/stack/cxf/trunk
Subversion: Committed revision 18955
> 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, 3 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 commented on JBWS-3833:
--------------------------------------
Hi Jim,
Thank you for the input. In fact, I know that {{@UseAsyncMethod(always = true)}} forces the async method to be invoked. The problem with this is that as explained in its source code {{always = true}} option simply blocks threads to achieve pseudo-asynchronicity, so it's not the true solution.
As Alessio pointed out, it turned out that what we really need is adding {{<async-supported>true</async-supported>}} in {{web.xml}} so that continuation is enabled for the servlet in JBoss.
> @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
> Assignee: Alessio Soldano
> 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's 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, 3 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 commented on JBWS-3833:
--------------------------------------
Alessio,
Oops! You're completely right. Adding {{<async-supported>true</async-supported>}} in {{web.xml}} and the {{"org.apache.cxf.impl"}} depdency to {{jboss-deployment-structure.xml}}, now the reproducer works as expected. I preconceived that no extra config is needed for enabling continuation on JBoss.
Thanks anyway for your investigation.
> @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
> Assignee: Alessio Soldano
> 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's 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, 3 months
[JBoss JIRA] (JBWS-3833) @UseAsyncMethod doesn't seem to work on JBoss
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBWS-3833?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JBWS-3833:
-----------------------------------------------
Tadayoshi Sato <tasato(a)redhat.com> changed the Status of [bug 1146766|https://bugzilla.redhat.com/show_bug.cgi?id=1146766] from NEW to CLOSED
> @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
> Assignee: Alessio Soldano
> 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's 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, 3 months
[JBoss JIRA] (JBWS-3833) @UseAsyncMethod doesn't seem to work on JBoss
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBWS-3833?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JBWS-3833:
-----------------------------------------------
Tadayoshi Sato <tasato(a)redhat.com> changed the Status of [bug 1146764|https://bugzilla.redhat.com/show_bug.cgi?id=1146764] from NEW to CLOSED
> @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
> Assignee: Alessio Soldano
> 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's 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, 3 months
[JBoss JIRA] (JBWS-3833) @UseAsyncMethod doesn't seem to work on JBoss
by Jim Ma (JIRA)
[ https://issues.jboss.org/browse/JBWS-3833?page=com.atlassian.jira.plugin.... ]
Jim Ma commented on JBWS-3833:
------------------------------
You need to add "org.apache.cxf.impl" depdency to access org.apache.cxf.jaxws.ServerAsyncResponse in meta-info and set @UseAsyncMethod(always = true). After add these things, the invocation always goes into asyn method.
> @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
> Assignee: Alessio Soldano
> 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's 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, 3 months
[JBoss JIRA] (JBWS-3834) ant tasks should include a clear help target
by Roberto Polli (JIRA)
[ https://issues.jboss.org/browse/JBWS-3834?page=com.atlassian.jira.plugin.... ]
Roberto Polli updated JBWS-3834:
--------------------------------
Description:
I could have sense that:
1- default target is an help screen
running #ant
you'll see a brief description of how to run/deploy the tests.
A copy/paste example instructions are a plus ;)
2- ant provides an "help" task
running #ant help
you'll see the forementioned screen
A sample patch http://fpaste.org/136684/23459141/
was:
I could have sense that:
1- default target is an help screen
running #ant
you'll see a brief description of how to run/deploy the tests.
A copy/paste example instructions are a plus ;)
2- ant provides an "help" task
running #ant help
you'll see the forementioned screen
> ant tasks should include a clear help target
> --------------------------------------------
>
> Key: JBWS-3834
> URL: https://issues.jboss.org/browse/JBWS-3834
> Project: JBoss Web Services
> Issue Type: Enhancement
> Components: jbossws-cxf
> Environment: all
> Reporter: Roberto Polli
> Priority: Optional
> Labels: documentation
>
> I could have sense that:
> 1- default target is an help screen
> running #ant
> you'll see a brief description of how to run/deploy the tests.
> A copy/paste example instructions are a plus ;)
> 2- ant provides an "help" task
> running #ant help
> you'll see the forementioned screen
> A sample patch http://fpaste.org/136684/23459141/
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 3 months
[JBoss JIRA] (JBWS-3834) ant tasks should include a clear help target
by Roberto Polli (JIRA)
Roberto Polli created JBWS-3834:
-----------------------------------
Summary: ant tasks should include a clear help target
Key: JBWS-3834
URL: https://issues.jboss.org/browse/JBWS-3834
Project: JBoss Web Services
Issue Type: Enhancement
Components: jbossws-cxf
Environment: all
Reporter: Roberto Polli
Priority: Optional
I could have sense that:
1- default target is an help screen
running #ant
you'll see a brief description of how to run/deploy the tests.
A copy/paste example instructions are a plus ;)
2- ant provides an "help" task
running #ant help
you'll see the forementioned screen
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 3 months