February 2015 - jbossws-issues - Jboss List Archives

[JBoss JIRA] (JBWS-3873) Web Services can't inherit a JDK8 default method

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBWS-3873?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated JBWS-3873: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1196686 > Web Services can't inherit a JDK8 default method > ------------------------------------------------ > > Key: JBWS-3873 > URL: https://issues.jboss.org/browse/JBWS-3873 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf, jbossws-integration > Affects Versions: jbossws-cxf-4.3.2, jbossws-cxf-5.0.0.Beta3 > Environment: JDK8 > Reporter: Jan Blizňák > Attachments: jdk8-ws-defaultmethod.zip > > > Having simple SEI and POJO webservice with JDK8 feature - default method for interface: > {code} > @WebService > public interface GreeterSEI { > default public String sayHello() { > return "Hello, Default"; > } > } > > //---------------------------------------------------------- > > @WebService > public class GreeterImpl implements GreeterSEI {} > {code} > When you try to execute sayHello method: > {code} > Service greeterService = Service.create(...); > GreeterSEI g = greeterService.getPort(GreeterSEI.class); > > Assert.assertEquals("JBoss", greeter.sayHello()); > {code} > You will get a message-less IllegalStateException on server. > Expected results: > no exception, default implementation of method is invoked. > Or if this is considered unsupported usage, the exception should be more descriptive (ie.: "Method xx not found on implementation class") -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3873) Web Services can't inherit a JDK8 default method

by Jan Blizňák (JIRA)

[ https://issues.jboss.org/browse/JBWS-3873?page=com.atlassian.jira.plugin.... ] Jan Blizňák updated JBWS-3873: ------------------------------ Attachment: jdk8-ws-defaultmethod.zip test project showing failures > Web Services can't inherit a JDK8 default method > ------------------------------------------------ > > Key: JBWS-3873 > URL: https://issues.jboss.org/browse/JBWS-3873 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf, jbossws-integration > Affects Versions: jbossws-cxf-4.3.2, jbossws-cxf-5.0.0.Beta3 > Environment: JDK8 > Reporter: Jan Blizňák > Attachments: jdk8-ws-defaultmethod.zip > > > Having simple SEI and POJO webservice with JDK8 feature - default method for interface: > {code} > @WebService > public interface GreeterSEI { > default public String sayHello() { > return "Hello, Default"; > } > } > > //---------------------------------------------------------- > > @WebService > public class GreeterImpl implements GreeterSEI {} > {code} > When you try to execute sayHello method: > {code} > Service greeterService = Service.create(...); > GreeterSEI g = greeterService.getPort(GreeterSEI.class); > > Assert.assertEquals("JBoss", greeter.sayHello()); > {code} > You will get a message-less IllegalStateException on server. > Expected results: > no exception, default implementation of method is invoked. > Or if this is considered unsupported usage, the exception should be more descriptive (ie.: "Method xx not found on implementation class") -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3873) Web Services can't inherit a JDK8 default method

by Jan Blizňák (JIRA)

Jan Blizňák created JBWS-3873: --------------------------------- Summary: Web Services can't inherit a JDK8 default method Key: JBWS-3873 URL: https://issues.jboss.org/browse/JBWS-3873 Project: JBoss Web Services Issue Type: Bug Components: jbossws-cxf, jbossws-integration Affects Versions: jbossws-cxf-5.0.0.Beta3, jbossws-cxf-4.3.2 Environment: JDK8 Reporter: Jan Blizňák Having simple SEI and POJO webservice with JDK8 feature - default method for interface: {code} @WebService public interface GreeterSEI { default public String sayHello() { return "Hello, Default"; } } //---------------------------------------------------------- @WebService public class GreeterImpl implements GreeterSEI {} {code} When you try to execute sayHello method: {code} Service greeterService = Service.create(...); GreeterSEI g = greeterService.getPort(GreeterSEI.class); Assert.assertEquals("JBoss", greeter.sayHello()); {code} You will get a message-less IllegalStateException on server. Expected results: no exception, default implementation of method is invoked. Or if this is considered unsupported usage, the exception should be more descriptive (ie.: "Method xx not found on implementation class") -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3846) Refactor creation process of jaxws handlers from predefined configurations

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3846?page=com.atlassian.jira.plugin.... ] Alessio Soldano commented on JBWS-3846: --------------------------------------- TestCase: https://source.jboss.org/changelog/JBossWS?cs=19503 (erroneously committed with wrong jira reference) > Refactor creation process of jaxws handlers from predefined configurations > -------------------------------------------------------------------------- > > Key: JBWS-3846 > URL: https://issues.jboss.org/browse/JBWS-3846 > Project: JBoss Web Services > Issue Type: Task > Components: jbossws-cxf, jbossws-integration > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-5.0 > > > We currently have no special integration with the container for jaxws handlers created from a predefined client/endpoint configuration. We need to support @PostConstruct, @PreDestroy methods, as well as @EJB, @Resource and CDI injection. > Most likely this basically boils down to having AS components created for these handlers too, the same we have for jaxws handlers created after having parsed the @HandlerChain annotation. See org.jboss.as.webservices.deployers.WSIntegrationProcessorJAXWS_HANDLER and org.jboss.as.webservices.injection.WSHandlerChainAnnotationProcessor as starting point. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3845) Injection not working in JAX-WS handlers from predefined configurations

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3845?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3845: ---------------------------------- Assignee: Alessio Soldano > Injection not working in JAX-WS handlers from predefined configurations > ----------------------------------------------------------------------- > > Key: JBWS-3845 > URL: https://issues.jboss.org/browse/JBWS-3845 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf > Environment: JBoss EAP 6.3 > Reporter: Roberto Polli > Assignee: Alessio Soldano > Labels: cdi, handler, jax-ws > Fix For: jbossws-cxf-5.0 > > > Reproduce: > 1- deliver [the linked jaxws webapp|https://github.com/ioggstream/jboss-eap-quickstarts/tree/jaxws-han...] on EAP6.3 > 2- add the CDIHandler using the the CLI (eg.) or running the given [standalone.xml|https://github.com/ioggstream/jboss-eap-quickstarts/blob/j...] > $ cd /subsystem=webservices/endpoint-config=Standard-Endpoint-Config/ > $ /pre-handler-chain=C1:add > $ /pre-handler-chain=C1/handler=H1:add(class="org.jboss.as.quickstarts.wshelloworld.CDIHandler") > $ :reload > 3- Invoke > * HelloWorldService.sayHello() > I expect: > A- the CDIBean to be injected > B- the server replying correctly > Instead > B- the injection doesn't happen and the handler raises an exception > Running the Handler via the @HandlerChain annotation (using the provided HandlerServiceImpl) and removing the handlerchain from jboss everything works fine. > Debugging I found that those handlers are created via ConfigHelper.setupConfigHandlers which does a clazz.newInstance(). Probably this doesn't go through the CDI chain... -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3846) Refactor creation process of jaxws handlers from predefined configurations

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3846?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3846: ---------------------------------- Assignee: Alessio Soldano > Refactor creation process of jaxws handlers from predefined configurations > -------------------------------------------------------------------------- > > Key: JBWS-3846 > URL: https://issues.jboss.org/browse/JBWS-3846 > Project: JBoss Web Services > Issue Type: Task > Components: jbossws-cxf, jbossws-integration > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-5.0 > > > We currently have no special integration with the container for jaxws handlers created from a predefined client/endpoint configuration. We need to support @PostConstruct, @PreDestroy methods, as well as @EJB, @Resource and CDI injection. > Most likely this basically boils down to having AS components created for these handlers too, the same we have for jaxws handlers created after having parsed the @HandlerChain annotation. See org.jboss.as.webservices.deployers.WSIntegrationProcessorJAXWS_HANDLER and org.jboss.as.webservices.injection.WSHandlerChainAnnotationProcessor as starting point. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3872) Drop JBossEntityResolver usage

by Alessio Soldano (JIRA)

Alessio Soldano created JBWS-3872: ------------------------------------- Summary: Drop JBossEntityResolver usage Key: JBWS-3872 URL: https://issues.jboss.org/browse/JBWS-3872 Project: JBoss Web Services Issue Type: Task Components: jbossws-cxf, jbossws-integration Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: jbossws-cxf-5.0 With the native stack having been completely removed, it looks like we don't need the JBossEntityResolver / JBossWSEntityResolver anymore. So we can drop it. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3871) Remove dependency on org.jboss:jboss-common-core

by Alessio Soldano (JIRA)

Alessio Soldano created JBWS-3871: ------------------------------------- Summary: Remove dependency on org.jboss:jboss-common-core Key: JBWS-3871 URL: https://issues.jboss.org/browse/JBWS-3871 Project: JBoss Web Services Issue Type: Task Components: jbossws-cxf, jbossws-integration Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: jbossws-cxf-5.0 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3870) Imported schemas in weird places in deployments causes issues

by R Searls (JIRA)

[ https://issues.jboss.org/browse/JBWS-3870?page=com.atlassian.jira.plugin.... ] R Searls commented on JBWS-3870: -------------------------------- We have a concurrency test case but it will not be commonly shared here. Please contact me if you need it. > Imported schemas in weird places in deployments causes issues > ------------------------------------------------------------- > > Key: JBWS-3870 > URL: https://issues.jboss.org/browse/JBWS-3870 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf > Reporter: R Searls > Fix For: jbossws-cxf-5.0 > > Attachments: schemasInWeirdPlaceFromSrc.zip > > > There is a customer that has placed their WSDL files under > WEB-INF/classes/wsdl rather than just WEB-INF/wsdl. They then put > their WSDL under a subdirectory of that folder, say "thewsdl". Then > that WSDL references other schemas in other subdirectories at the same > level as the WSDL's subdirectory. Like this: > WEB-INF/ > classes/ > wsdl/ > thewsdl/ > the-actual-wsdl.wsdl > schemas/ > some-schema.xsd > When this gets deployed, all the imported schemas fall outside the > deployment's data/wsdl folder when they are written to the filesystem. > Like this: > standalone/ > data/ > wsdl/ > myDeployment.war/ > <wsdl would go here> > schemas/ > some-schema.xsd > This can cause weird concurrency issues if multiple deployment > processor threads happen to be processing separate webservices where > each have WSDLs that happen to import schemas with the same schemaLocation > attribute. In the above scenario, the schemaLocation would include a > ".." since the WSDL would be in its own subfolder. > The code that writes these files to disk is here > Line 224: > https://anonsvn.jboss.org/repos/jbossws/common/tags/jbossws-common-2.3.1.... > Line 190: > https://anonsvn.jboss.org/repos/jbossws/stack/cxf/tags/jbossws-cxf-4.3.3.... > The problem is that WSDLFilePublisher.getPublishLocation() cuts off > subfolders that the WSDL is under in this particular scenario, so when > the schemaLocation that has ".." in it is appended to the WSDL path, > it will write the schema outside the deployment's data/wsdl/ folder. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBWS-3870) Imported schemas in weird places in deployments causes issues

by R Searls (JIRA)

[ https://issues.jboss.org/browse/JBWS-3870?page=com.atlassian.jira.plugin.... ] R Searls updated JBWS-3870: --------------------------- Attachment: schemasInWeirdPlaceFromSrc.zip Simple (non-concurrency) test case. > Imported schemas in weird places in deployments causes issues > ------------------------------------------------------------- > > Key: JBWS-3870 > URL: https://issues.jboss.org/browse/JBWS-3870 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf > Reporter: R Searls > Fix For: jbossws-cxf-5.0 > > Attachments: schemasInWeirdPlaceFromSrc.zip > > > There is a customer that has placed their WSDL files under > WEB-INF/classes/wsdl rather than just WEB-INF/wsdl. They then put > their WSDL under a subdirectory of that folder, say "thewsdl". Then > that WSDL references other schemas in other subdirectories at the same > level as the WSDL's subdirectory. Like this: > WEB-INF/ > classes/ > wsdl/ > thewsdl/ > the-actual-wsdl.wsdl > schemas/ > some-schema.xsd > When this gets deployed, all the imported schemas fall outside the > deployment's data/wsdl folder when they are written to the filesystem. > Like this: > standalone/ > data/ > wsdl/ > myDeployment.war/ > <wsdl would go here> > schemas/ > some-schema.xsd > This can cause weird concurrency issues if multiple deployment > processor threads happen to be processing separate webservices where > each have WSDLs that happen to import schemas with the same schemaLocation > attribute. In the above scenario, the schemaLocation would include a > ".." since the WSDL would be in its own subfolder. > The code that writes these files to disk is here > Line 224: > https://anonsvn.jboss.org/repos/jbossws/common/tags/jbossws-common-2.3.1.... > Line 190: > https://anonsvn.jboss.org/repos/jbossws/stack/cxf/tags/jbossws-cxf-4.3.3.... > The problem is that WSDLFilePublisher.getPublishLocation() cuts off > subfolders that the WSDL is under in this particular scenario, so when > the schemaLocation that has ".." in it is appended to the WSDL path, > it will write the schema outside the deployment's data/wsdl/ folder. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbossws-issues February 2015