October 2014 - jbossws-issues - Jboss List Archives

[JBoss JIRA] (JBWS-3837) Apache CXF interceptors setup through properties

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3837?page=com.atlassian.jira.plugin.... ] Alessio Soldano commented on JBWS-3837: --------------------------------------- https://docs.jboss.org/author/display/JBWS/Apache+CXF+integration#ApacheC... > Apache CXF interceptors setup through properties > ------------------------------------------------ > > Key: JBWS-3837 > URL: https://issues.jboss.org/browse/JBWS-3837 > Project: JBoss Web Services > Issue Type: Feature Request > Components: jbossws-cxf > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-5.0 > > > "Speaking of properties, currently specified in jboss-webservices.xml and > possibly in jboss-webservices-client.xml, we could start supporting two > additional props: > * org.apache.cxf.interceptor.InInterceptors, with the value string to be > parsed for getting a list of in-interceptor classnames; basically to > achieve the same we get with @InInterceptor > * org.apache.cxf.interceptor.OutInterceptors, with the value string to > be parsed for getting a list of out-interceptor classnames; basically to > achieve the same we get with @OutInterceptor > The interceptors would be attached either to the bus or to the > client/endpoint depending on where the property is declared." > http://lists.jboss.org/pipermail/jbossws-dev/2014-September/002209.html -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBWS-3840) jboss-webservices.xml support for Apache CXF interceptor properties

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3840?page=com.atlassian.jira.plugin.... ] Alessio Soldano commented on JBWS-3840: --------------------------------------- https://docs.jboss.org/author/display/JBWS/Apache+CXF+integration#ApacheC... > jboss-webservices.xml support for Apache CXF interceptor properties > ------------------------------------------------------------------- > > Key: JBWS-3840 > URL: https://issues.jboss.org/browse/JBWS-3840 > Project: JBoss Web Services > Issue Type: Feature Request > Components: jbossws-cxf > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: jbossws-cxf-5.0 > > > This basically implies extending the support for Apache CXF interceptor setup through properties to the jboss-webservices.xml descriptor. This would allow declaring interceptors to be added to the deployment bus and hence processing messages sent to and going out of any endpoint included in the deployment. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBWS-3839) excessive ERROR logging on webservices invocation if SoapFault

by Jim Ma (JIRA)

[ https://issues.jboss.org/browse/JBWS-3839?page=com.atlassian.jira.plugin.... ] Jim Ma commented on JBWS-3839: ------------------------------ Hi Thomas, To fix this issue I think we can introduce another annotation to mark some exception doesn't need to be logged, and this kind of exception is expected to happen. For example when it sees the exception with Annotation @NonLoggingException , it will skip to log this kind of error. @NonLonggingException public ExampleException extends Exception { } Will this work for your case ? > excessive ERROR logging on webservices invocation if SoapFault > -------------------------------------------------------------- > > Key: JBWS-3839 > URL: https://issues.jboss.org/browse/JBWS-3839 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf, jbossws-integration > Reporter: Thomas Frühbeck > Assignee: Jim Ma > Priority: Minor > Fix For: jbossws-cxf-5.0 > > > AbstractInvocationHandler logs ERROR even if invocation fails with SOAPFault, which is IMHO wrong. > It is to be handled like @ApplicationException, the service implementation too care to raise a SOAPFault. > catch (Throwable t) { > WSLogger.ROOT_LOGGER.methodInvocationFailed(t, t.getLocalizedMessage()); > handleInvocationException(t); > The current implementation leads to excessive false ERROR logs, which is unpleasant in production environments. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBWS-3840) jboss-webservices.xml support for Apache CXF interceptor properties

by Alessio Soldano (JIRA)

Alessio Soldano created JBWS-3840: ------------------------------------- Summary: jboss-webservices.xml support for Apache CXF interceptor properties Key: JBWS-3840 URL: https://issues.jboss.org/browse/JBWS-3840 Project: JBoss Web Services Issue Type: Feature Request Components: jbossws-cxf Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: jbossws-cxf-5.0 This basically implies extending the support for Apache CXF interceptor setup through properties to the jboss-webservices.xml descriptor. This would allow declaring interceptors to be added to the deployment bus and hence processing messages sent to and going out of any endpoint included in the deployment. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBWS-3792) JBossWS: wsdl:import always handled as relative location

by Marc H. (JIRA)

[ https://issues.jboss.org/browse/JBWS-3792?page=com.atlassian.jira.plugin.... ] Marc H. updated JBWS-3792: -------------------------- Attachment: jbws3792-external-wsdl.war jbws3792-ws-impl.war jbws3792_example_src.tar.gz If it is not a bug, then it would be a really useful feature :-) Here are two war archives: - jbws3792-external-wsdl.war publishes two WSDL files (without providing any implementation): jbws3792.wsdl and import.wsdl. The former doing a import of the latter (import.wsdl) using an absolute location (wsdl definitions were generated with CXF java2ws). - jbws3792-ws-impl.war, provides a web-service implementation (automatically generated with CXF tools) targetting the WSDL file jbws3792.wsdl published in jbws3792-external-wsdl. When deploying both archives on glassfish-4.1 (EE profile) using Metro RI, the service will deploy and works just fine. When deploying both archives on Wildfly 9.0.0-Alpha1, deployment will fail as depicted in SOAPAddressWSDLParser ( JBWS022087: Failed to read http://localhost:8080/jbws3792-external-wsdl/http://localhost:8080/jbws37...: http://localhost:8080/jbws3792-external-wsdl/http://localhost:8080/jbws37... ) I also add the source for both archives. I perfectly understand that, according to the specs, WSDL files must be packaged with the module. I even think that JAX-WS mandates the wsdlLocation of being a relative URL for endpoint implementation. Nevertheless, relying on an externally published wsdl is extremelly usefull when you need to provide a mocked implementation of some services without suffering the burden to dump/rewrite the WSDL files at each build. Would it be relevant to open a new feature request to address this? > 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, jbws3792-external-wsdl.war, jbws3792-ws-impl.war, jbws3792_example_src.tar.gz > > > 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, 1 month

1
0
0 / 0

[JBoss JIRA] (JBWS-3839) excessive ERROR logging on webservices invocation if SoapFault

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3839?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3839: ---------------------------------- Assignee: (was: Alessio Soldano) > excessive ERROR logging on webservices invocation if SoapFault > -------------------------------------------------------------- > > Key: JBWS-3839 > URL: https://issues.jboss.org/browse/JBWS-3839 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf, jbossws-integration > Reporter: Thomas Frühbeck > Priority: Minor > Fix For: jbossws-cxf-5.0 > > > AbstractInvocationHandler logs ERROR even if invocation fails with SOAPFault, which is IMHO wrong. > It is to be handled like @ApplicationException, the service implementation too care to raise a SOAPFault. > catch (Throwable t) { > WSLogger.ROOT_LOGGER.methodInvocationFailed(t, t.getLocalizedMessage()); > handleInvocationException(t); > The current implementation leads to excessive false ERROR logs, which is unpleasant in production environments. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBWS-3839) excessive ERROR logging on webservices invocation if SoapFault

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-3839?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-3839: ---------------------------------- Fix Version/s: jbossws-cxf-5.0 > excessive ERROR logging on webservices invocation if SoapFault > -------------------------------------------------------------- > > Key: JBWS-3839 > URL: https://issues.jboss.org/browse/JBWS-3839 > Project: JBoss Web Services > Issue Type: Bug > Components: jbossws-cxf, jbossws-integration > Reporter: Thomas Frühbeck > Assignee: Alessio Soldano > Priority: Minor > Fix For: jbossws-cxf-5.0 > > > AbstractInvocationHandler logs ERROR even if invocation fails with SOAPFault, which is IMHO wrong. > It is to be handled like @ApplicationException, the service implementation too care to raise a SOAPFault. > catch (Throwable t) { > WSLogger.ROOT_LOGGER.methodInvocationFailed(t, t.getLocalizedMessage()); > handleInvocationException(t); > The current implementation leads to excessive false ERROR logs, which is unpleasant in production environments. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBWS-2680) Authentication realm name hard-coded as "EJBServiceEndpointServlet Realm"

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-2680?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-2680: ---------------------------------- Component/s: jbossws-cxf (was: jbossws-native) > Authentication realm name hard-coded as "EJBServiceEndpointServlet Realm" > ------------------------------------------------------------------------- > > Key: JBWS-2680 > URL: https://issues.jboss.org/browse/JBWS-2680 > Project: JBoss Web Services > Issue Type: Feature Request > Components: jbossws-cxf > Affects Versions: jbossws-native-3.0.5 > Environment: JBossAS 4.2.3 with JBossWS 3.0.5 > Reporter: Gerald Turner > Priority: Optional > > An EJB3 endpoint defined with annotation @WebContext(authMethod="BASIC") results in JBossWS generating web.xml metadata equivalent to: > <login-config> > <auth-method>BASIC</auth-method> > <realm-name>EJBServiceEndpointServlet Realm</realm-name> > </login-config> > On one hand this is perfectly acceptable as the realm-name is just a vanity configuration parameter. However there are scenarios where it would be desirable to allow the application to override the default value: we migrated from another web services stack to JBossWS (was JAXWS-RI), some clients of our web services had explicitly configured their HTTP authentication on their end to match on realm name (one instance was Perl SOAP::Lite), quite the same way a web browser stores HTTP authentication along with the realm name such if the realm name changes, the authentication is invalidated - but since these are machines talking to each other rather than a web browser, it becomes a nightmare to debug why a client began receiving 401 errors after our upgrade. > It would be nice if the org.jboss.wsf.spi.annotation.WebContext annotation had a realmName parameter. > I attempted to work on a patch, however I'm confused by how many copies of WebAppGeneratorDeploymentAspect.java there seem to be under the jbossws/container and jbossws/framework subversion trees. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBWS-2680) Authentication realm name hard-coded as "EJBServiceEndpointServlet Realm"

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-2680?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-2680: ---------------------------------- Fix Version/s: (was: community contributions) > Authentication realm name hard-coded as "EJBServiceEndpointServlet Realm" > ------------------------------------------------------------------------- > > Key: JBWS-2680 > URL: https://issues.jboss.org/browse/JBWS-2680 > Project: JBoss Web Services > Issue Type: Feature Request > Components: jbossws-native > Affects Versions: jbossws-native-3.0.5 > Environment: JBossAS 4.2.3 with JBossWS 3.0.5 > Reporter: Gerald Turner > Priority: Optional > > An EJB3 endpoint defined with annotation @WebContext(authMethod="BASIC") results in JBossWS generating web.xml metadata equivalent to: > <login-config> > <auth-method>BASIC</auth-method> > <realm-name>EJBServiceEndpointServlet Realm</realm-name> > </login-config> > On one hand this is perfectly acceptable as the realm-name is just a vanity configuration parameter. However there are scenarios where it would be desirable to allow the application to override the default value: we migrated from another web services stack to JBossWS (was JAXWS-RI), some clients of our web services had explicitly configured their HTTP authentication on their end to match on realm name (one instance was Perl SOAP::Lite), quite the same way a web browser stores HTTP authentication along with the realm name such if the realm name changes, the authentication is invalidated - but since these are machines talking to each other rather than a web browser, it becomes a nightmare to debug why a client began receiving 401 errors after our upgrade. > It would be nice if the org.jboss.wsf.spi.annotation.WebContext annotation had a realmName parameter. > I attempted to work on a patch, however I'm confused by how many copies of WebAppGeneratorDeploymentAspect.java there seem to be under the jbossws/container and jbossws/framework subversion trees. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBWS-2680) Authentication realm name hard-coded as "EJBServiceEndpointServlet Realm"

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/JBWS-2680?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated JBWS-2680: ---------------------------------- Fix Version/s: jbossws-cxf-5.0 > Authentication realm name hard-coded as "EJBServiceEndpointServlet Realm" > ------------------------------------------------------------------------- > > Key: JBWS-2680 > URL: https://issues.jboss.org/browse/JBWS-2680 > Project: JBoss Web Services > Issue Type: Feature Request > Components: jbossws-cxf > Affects Versions: jbossws-native-3.0.5 > Environment: JBossAS 4.2.3 with JBossWS 3.0.5 > Reporter: Gerald Turner > Priority: Optional > Fix For: jbossws-cxf-5.0 > > > An EJB3 endpoint defined with annotation @WebContext(authMethod="BASIC") results in JBossWS generating web.xml metadata equivalent to: > <login-config> > <auth-method>BASIC</auth-method> > <realm-name>EJBServiceEndpointServlet Realm</realm-name> > </login-config> > On one hand this is perfectly acceptable as the realm-name is just a vanity configuration parameter. However there are scenarios where it would be desirable to allow the application to override the default value: we migrated from another web services stack to JBossWS (was JAXWS-RI), some clients of our web services had explicitly configured their HTTP authentication on their end to match on realm name (one instance was Perl SOAP::Lite), quite the same way a web browser stores HTTP authentication along with the realm name such if the realm name changes, the authentication is invalidated - but since these are machines talking to each other rather than a web browser, it becomes a nightmare to debug why a client began receiving 401 errors after our upgrade. > It would be nice if the org.jboss.wsf.spi.annotation.WebContext annotation had a realmName parameter. > I attempted to work on a patch, however I'm confused by how many copies of WebAppGeneratorDeploymentAspect.java there seem to be under the jbossws/container and jbossws/framework subversion trees. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

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 October 2014