[JBoss JIRA] Created: (JBWS-3264) Don't use log4j configuration classes in our CXF tools - identify possible workarounds
by Richard Opalka (JIRA)
Don't use log4j configuration classes in our CXF tools - identify possible workarounds
--------------------------------------------------------------------------------------
Key: JBWS-3264
URL: https://issues.jboss.org/browse/JBWS-3264
Project: JBoss Web Services
Issue Type: Task
Security Level: Public (Everyone can see)
Reporter: Richard Opalka
Fix For: jbossws-cxf-4.0
<opalka> dmlloyd, I found ugly dependency - http://fpaste.org/9UXj/
<stuartdouglas> opalka: I actually hacked up something last night to try and find those problems
<opalka> dmlloyd, stuartdouglas this is the call resulting to this dependency - we're using log4j configurators - http://fpaste.org/aKXp/
<dmlloyd> why?
<dmlloyd> (a) you shouldn't do that, (b) to fix the problem add "javax.api" to log4j's module dep
<opalka> dmlloyd, this is question for alessio. I have no idea? Probably Alessio want's to use log4j config facility
<dmlloyd> ok well if we're doing that it's pretty lame because we go through many hoops to avoid using the log4j config facility
<opalka> dmlloyd, method javadoc isn't more descriptive as well - http://fpaste.org/DyVx/ I'll need to ask Alessio
<opalka> dmlloyd, but just to confirm, we don't want org.apache.logging -> org.w3c.dom dependency in AS7, right ?
* opalka don't like this dependency
<dmlloyd> no, org.apache.logging is something completely different
<dmlloyd> it should be org.apache.log4j -> javax.api
<opalka> dmlloyd, and do we want this dependency ?
<dmlloyd> yeah, it's fine to add
<dmlloyd> but we don't want this manual log4j configuration
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] Created: (JBWS-3105) Review and fix AS IL maven dependencies
by Richard Opalka (JIRA)
Review and fix AS IL maven dependencies
---------------------------------------
Key: JBWS-3105
URL: https://jira.jboss.org/browse/JBWS-3105
Project: JBoss Web Services
Issue Type: Task
Security Level: Public (Everyone can see)
Components: jbossws-integration
Reporter: Richard Opalka
Assignee: Richard Opalka
Fix For: jbossws-cxf-3.4.1, jbossws-native-3.4.1, jbossws-metro-3.4.1
I found some weirdness related to VirtualFile in AS IL.
This blocked me to clean AS IL maven dependencies.
We need to review AS IL dependencies and make them
explicit i.e. to know which libraries we're exactly depending on.
The result of this process should be VirtualFile weirdness fix.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] Created: (JBWS-3199) AbstractServerConfig.toIPv6URLFormat throws java.net.UnknownHostException
by Alessio Soldano (JIRA)
AbstractServerConfig.toIPv6URLFormat throws java.net.UnknownHostException
-------------------------------------------------------------------------
Key: JBWS-3199
URL: https://issues.jboss.org/browse/JBWS-3199
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: jbossws-cxf, jbossws-native
Affects Versions: jbossws-native-3.4.1, jbossws-cxf-3.4.1
Reporter: Alessio Soldano
Fix For: jbossws-native-4.0, jbossws-cxf-4.0
After applying the changes for IPv6 support, the AbstractServerConfig::toIPv6URLFormat method does a InetAddress.getByName(host) call that can throws UnknownHostException if the webserviceHost in the configuration can't be lookup.
This needs to be changed or at least surrounded by a try-catch block as it's not robust (to be honest nothing even prevents the user from wanting a fancy hostname in there).
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] Created: (JBWS-3230) Could not find any reference to namespace 'http://schemas.xmlsoap.org/ws/2005/02/rm'
by Richard Opalka (JIRA)
Could not find any reference to namespace 'http://schemas.xmlsoap.org/ws/2005/02/rm'
------------------------------------------------------------------------------------
Key: JBWS-3230
URL: https://issues.jboss.org/browse/JBWS-3230
Project: JBoss Web Services
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Reporter: Richard Opalka
Fix For: jbossws-cxf-4.0
13:07:03,626 WARNING [org.apache.cxf.phase.PhaseInterceptorChain] (http-8080-1) Interceptor for {http://www.jboss.org/jbossws/ws-extensions/wsrm}SimpleService has thrown exception, unwinding now: org.apache.cxf.interceptor.Fault: Could not find any reference to namespace 'http://schemas.xmlsoap.org/ws/2005/02/rm' in handled message.
at org.jboss.test.ws.jaxws.samples.wsrm.service.RMCheckInterceptor.handleMessage(RMCheckInterceptor.java:73) [classe:]
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255) [cxf-api.jar:2.3.2]
at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113) [cxf-rt-core.jar:2.3.2]
at org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:97) [cxf-rt-transports-http.jar:2.3.2]
at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:461) [cxf-rt-transports-http.jar:2.3.2]
at org.jboss.wsf.stack.cxf.ServletControllerExt.invoke(ServletControllerExt.java:172) [jbossws-cxf-server.jar:4.0.0-SNAPSHOT]
at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:57) [jbossws-cxf-server.jar:4.0.0-SNAPSHOT]
at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:156) [jbossws-cxf-server.jar:4.0.0-SNAPSHOT]
at org.jboss.wsf.stack.cxf.CXFNonSpringServletExt.invoke(CXFNonSpringServletExt.java:90) [jbossws-cxf-server.jar:4.0.0-SNAPSHOT]
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179) [cxf-rt-transports-http.jar:2.3.2]
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103) [cxf-rt-transports-http.jar:2.3.2]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:754) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159) [cxf-rt-transports-http.jar:2.3.2]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:324) [jbossweb-7.0.0.Beta1.jar:7.0.0.Alpha2-SNAPSHOT]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) [jbossweb-7.0.0.Beta1.jar:7.0.0.Alpha2-SNAPSHOT]
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.0.Beta1.jar:7.0.0.Alpha2-SNAPSHOT]
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.0.Beta1.jar:7.0.0.Alpha2-SNAPSHOT]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.0.Beta1.jar:7.0.0.Alpha2-SNAPSHOT]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.0.Beta1.jar:7.0.0.Alpha2-SNAPSHOT]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.0.Beta1.jar:7.0.0.Alpha2-SNAPSHOT]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.0.Beta1.jar:7.0.0.Alpha2-SNAPSHOT]
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.0.Beta1.jar:7.0.0.Alpha2-SNAPSHOT]
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:654) [jbossweb-7.0.0.Beta1.jar:7.0.0.Alpha2-SNAPSHOT]
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951) [jbossweb-7.0.0.Beta1.jar:7.0.0.Alpha2-SNAPSHOT]
at java.lang.Thread.run(Thread.java:636) [:1.6.0_20]
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] Created: (JBWS-3201) WSConsume does not generate operation fault in WSDL when the WS method throws java.lang.Exception.
by Marek Baluch (JIRA)
WSConsume does not generate operation fault in WSDL when the WS method throws java.lang.Exception.
--------------------------------------------------------------------------------------------------
Key: JBWS-3201
URL: https://issues.jboss.org/browse/JBWS-3201
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: jbossws-cxf
Affects Versions: jbossws-cxf-3.1.2
Reporter: Marek Baluch
When we have the following WS:
@WebService(name="BiddingService", targetNamespace="http://jboss.org/bidding")
public class BiddingBackend {
// ...
@WebMethod(operationName = "makeBid")
public Boolean makeBid(@WebParam(name = "itemName") String itemName,
@WebParam(name = "offer") Integer offer) throws java.lang.Exception
{
// ...
}
}
then the generated WSDL does not contain a fault in it's binding. It's as the method would not throw an Exception.
If the method throws a descendant of java.lang.Exception then the resulting WSDL contains everything.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months