[JBoss JIRA] Created: (JBWS-3138) Better support for local WSDL deployment configurations (e.g., wsimport -clientjar)
by Ray Cardillo (JIRA)
Better support for local WSDL deployment configurations (e.g., wsimport -clientjar)
-----------------------------------------------------------------------------------
Key: JBWS-3138
URL: https://jira.jboss.org/browse/JBWS-3138
Project: JBoss Web Services
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: jaxws-tools-maven-plugin, jbossws-cxf, jbossws-metro, jbossws-native, productivity, tools-jaxws
Affects Versions: jbossws-metro-3.3.1, jbossws-native-3.3.1, jbossws-cxf-3.3.1, jbossws-native-3.4.0
Reporter: Ray Cardillo
Developers who must deploy to disconnected or closed network environments often have challenges creating local WSDL deployment configurations. This is especially true when they want to create a shared library or use a shared configuration that several projects must all use. For example, if there are several J2EE web applications and web services that are all clients of a particular web service, most developers end up copying all of the required WSDL content to the WEB-INF/wsdl folder of each project and then using the wsdlLocation attribute to specify the local WSDL files. This type of strategy is difficult to maintain, and the only other option is to create a shared OASIS XML catalog library. However, using a shared OASIS XML catalog library can be very challenging because of the details involved... putting a properly compiled schema catalog JAR (with a properly configured jax-ws-catalog.xml file) in the WEB-INF/lib and having the container use that JAR to resolve references by configuring the service endpoint with a reference that will be resolved by the JAR. For more information about that, see the last reference provided below, but the details are tricky to say the least, and some containers actually have problems with this type of deployment configuration.
To help with this requirement, JAX-WS 2.2.2 RI has added a "-clientjar" option to the "wsimport" tool. This feature is extremely important to anyone facing these challenges, and offers a huge productivity boost, from several perspectives. For developers who know how to navigate the complexity of doing this, it helps by doing all of the labor intensive steps automatically (downloading the WSDL, creating correct resource references, compiling the JAR properly, annotating the binding properly, etc). For developers who do not know about these details, it is even more valuable because this option is not very well known, yet is something that should be a primary use case (supporting people on isolated networks). The requirement is often overlooked by the web services frameworks because they assume everyone will always have network access, but isolated networks are very common in certain communities.
See the following for more references:
http://www.java.net/print/476434
http://wikis.sun.com/display/GlassFish/3.1Metro#3.1Metro-wsimport%5Cclien...
http://forums.java.net/jive/message.jspa?messageID=480624#480624
--
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
12 years, 10 months
[JBoss JIRA] Created: (JBWS-3007) Re-define QA phase leveraging staging repositories
by Alessio Soldano (JIRA)
Re-define QA phase leveraging staging repositories
--------------------------------------------------
Key: JBWS-3007
URL: https://jira.jboss.org/jira/browse/JBWS-3007
Project: JBoss Web Services
Issue Type: Task
Security Level: Public (Everyone can see)
Components: jbossws-cxf, jbossws-metro, jbossws-native, productization
Reporter: Alessio Soldano
Fix For: jbossws-native-3.3.0, jbossws-cxf-3.3.0, jbossws-metro-3.3.0
Now that the new maven repository based on nexus is available, we can finally implement a better QA phase. I'm thinking about providing a proper maven profile for hudson to run against the staging repository. That would allow us to do what follows at code freeze:
- verify all green (blue) on hudson against trunk
- tag every changed components (spi, common, fw, ci, stacks) and mvn deploy them
- close the temporary staging repository/repositories making the artifacts move to the shared staging repo
- quickly re-start hudson against the staging repository
- get a full clear run on hudson (starting with a local repository cleanup)
- promote the artifacts to the release repository
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] Created: (JBWS-2880) WS-RM 1.1 does not work when invoked from a Metro Client
by Carl Roberts (JIRA)
WS-RM 1.1 does not work when invoked from a Metro Client
--------------------------------------------------------
Key: JBWS-2880
URL: https://jira.jboss.org/jira/browse/JBWS-2880
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: jbossws-native
Environment: Windows XP, JBOSS 5.1.0 GA, with default JAX-WS JBoss Native
Reporter: Carl Roberts
When I invoke a JBOSS service endpoint with WS-RM enabled, from a Metro client the service returns this exception (you can also see the message being sent by the client below via the output of the LoggingHandler):
11:37:53,953 INFO [STDOUT] 2009-12-21 11:37:53,953 DEBUG LoggingHandler :*****LoggingHandler Input Message:
11:37:53,984 INFO [STDOUT] 2009-12-21 11:37:53,984 DEBUG LoggingHandler :
<ns2:CreateSequence xmlns:ns2="http://docs.oasis-open.org/ws-rx/wsrm/200702" xmlns="http://www.w3.org/2005/08/addressing" xmlns:ns3="http://docs.oasis-open.org/ws-rx/wsmc
/200702" xmlns:ns4="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext..." xmlns:ns5="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
wssecurity-utility-1.0.xsd" xmlns:ns6="http://schemas.microsoft.com/ws/2006/05/rm">
<ns2:AcksTo>
<Address>http://www.w3.org/2005/08/addressing/anonymous</Address>
</ns2:AcksTo>
<ns2:Offer>
<ns2:Identifier>uuid:b2c69a6a-2287-4f6d-ab45-df92dd8672cf</ns2:Identifier>
<ns2:Endpoint>
<Address>http://www.w3.org/2005/08/addressing/anonymous</Address>
</ns2:Endpoint>
</ns2:Offer>
</ns2:CreateSequence>
11:37:54,000 ERROR [SOAPFaultHelperJAXWS] SOAP request exception
org.jboss.ws.extensions.wsrm.RMFault: The RM Destination requires the use of WSRM
at org.jboss.ws.extensions.wsrm.server.RMInvocationHandler.prepareResponseContext(RMInvocationHandler.java:134)
at org.jboss.ws.extensions.wsrm.server.RMInvocationHandler.invoke(RMInvocationHandler.java:306)
at org.jboss.ws.core.server.ServiceEndpointInvoker.invoke(ServiceEndpointInvoker.java:222)
at org.jboss.wsf.stack.jbws.RequestHandlerImpl.processRequest(RequestHandlerImpl.java:474)
at org.jboss.wsf.stack.jbws.RequestHandlerImpl.handleRequest(RequestHandlerImpl.java:295)
at org.jboss.wsf.stack.jbws.RequestHandlerImpl.doPost(RequestHandlerImpl.java:205)
at org.jboss.wsf.stack.jbws.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:131)
at org.jboss.wsf.common.servlet.AbstractEndpointServlet.service(AbstractEndpointServlet.java:85)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] Created: (JBWS-2697) Consistent Configuration for HTTP connections
by Darran Lofthouse (JIRA)
Consistent Configuration for HTTP connections
---------------------------------------------
Key: JBWS-2697
URL: https://jira.jboss.org/jira/browse/JBWS-2697
Project: JBoss Web Services
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: jbossws-native
Affects Versions: jbossws-native-3.1.2
Reporter: Darran Lofthouse
Assignee: Alessio Soldano
Fix For: jbossws-native-3.2.0
When calling a remote endpoint that is either secured using BASIC authentication or using HTTPS (or even both together) we use the java.net.URL.openConnection() method to obtain the WSDL and related XSDs but we then use JBoss Remoting for the WS call.
This means that both connection approaches need to be configured to call the same endpoint.
If would help if there was some way we could unify the configuration so when calling an endpoint this only needs to be configured once.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] Created: (JBWS-2803) Need mechanism for externalizing wsdl_url property
by Matt Davis (JIRA)
Need mechanism for externalizing wsdl_url property
--------------------------------------------------
Key: JBWS-2803
URL: https://jira.jboss.org/jira/browse/JBWS-2803
Project: JBoss Web Services
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Environment: JBoss [EAP] 4.3.0.GA_CP04
Java VM: Java HotSpot(TM) Server VM 14.0-b16,Sun Microsystems Inc.
OS-System: Windows XP 5.1,x86
Reporter: Matt Davis
Assignee: Darran Lofthouse
Priority: Minor
A customer is requesting a way to externalize the wsdl url (move it outside of the JBoss environment). They have attempted using <wsdl-override> and then passing a property inside of the tag - ${jboss.host.details}. This does not work and property replacement is not supported in this portion of the jboss-web.xml file. In the interim the customer has made changes to the DefaultServiceRefMetaDataParser class to allow them to pass the property into the wsdl-overide.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] Created: (JBWS-2459) Allow WebServiceFeature to disable wsdl extension requirements
by Alessio Soldano (JIRA)
Allow WebServiceFeature to disable wsdl extension requirements
--------------------------------------------------------------
Key: JBWS-2459
URL: https://jira.jboss.org/jira/browse/JBWS-2459
Project: JBoss Web Services
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: jbossws-native
Reporter: Alessio Soldano
Regarding the @RespectBinding/RespectBindingFeature, the JAXWS 2.1 spec says that all required wsdl:extensions MUST be supported and honored by the implementation unless a specific wsdl:extension has been explicitely disabled via a WebServiceFeature. This is currently not supported as there's no webservice feature implemented having a corresponding wsdl extension. Perhaps ws-addressing could be an example with UsingAddressing. We should nevertheless implement this mechanism.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] Created: (JBWS-2311) WSA does not work for provider based endpoint
by Jim Ma (JIRA)
WSA does not work for provider based endpoint
---------------------------------------------
Key: JBWS-2311
URL: https://jira.jboss.org/jira/browse/JBWS-2311
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: jbossws-native, ws-addressing
Affects Versions: jbossws-native-3.0.1
Reporter: Jim Ma
When add the WSAddressingServerHandler for provider based endpoint , it raises the following error :
ERROR [org.jboss.ws.core.jaxws.handler.HandlerChainExecutor] Exception during handler processing
javax.xml.ws.addressing.AddressingException: Required addressing property missing: {http://www.w3.org/2005/08/addressing}Action
at org.jboss.ws.extensions.addressing.soap.SOAPAddressingPropertiesImpl.appendRequiredHeader(SOAPAddressingPropertiesImpl.java:304)
at org.jboss.ws.extensions.addressing.soap.SOAPAddressingPropertiesImpl.writeHeaders(SOAPAddressingPropertiesImpl.java:257)
at org.jboss.ws.extensions.addressing.jaxws.WSAddressingServerHandler.handleResponseOrFault(WSAddressingServerHandler.java:156)
at org.jboss.ws.extensions.addressing.jaxws.WSAddressingServerHandler.handleOutbound(WSAddressingServerHandler.java:92)
at org.jboss.ws.core.jaxws.handler.GenericHandler.handleMessage(GenericHandler.java:55)
at org.jboss.ws.core.jaxws.handler.HandlerChainExecutor.handleMessage(HandlerChainExecutor.java:295)
at org.jboss.ws.core.jaxws.handler.HandlerChainExecutor.handleMessage(HandlerChainExecutor.java:140)
at org.jboss.ws.core.jaxws.handler.HandlerDelegateJAXWS.callResponseHandlerChain
JAXWSProviderMetaDataBuilder does not process the WSA information add generate AddressingOpMetaExt. This will cause the required outbound action in SoapAddressingProperties not set , see the following WSAddressingServerHandler code segment :
OperationMetaData opMetaData = ((SOAPMessageContextJAXRPC)msgContext).getOperationMetaData();
if (!isFault && !opMetaData.isOneWay())
{
AddressingOpMetaExt addrExt = (AddressingOpMetaExt)opMetaData.getExtension(ADDR_CONSTANTS.getNamespaceURI());
if (addrExt != null)
{
outProps.setAction(ADDR_BUILDER.newURI(addrExt.getOutboundAction()));
}
else
{
log.warn("Unable to resolve replyAction for " + opMetaData.getQName());
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months