[JBoss JIRA] Created: (JBWS-1423) Implement SAAJ 1.3 new functionality
by Thomas Diesler (JIRA)
Implement SAAJ 1.3 new functionality
------------------------------------
Key: JBWS-1423
URL: http://jira.jboss.com/jira/browse/JBWS-1423
Project: JBoss Web Services
Issue Type: Task
Security Level: Public (Everyone can see)
Reporter: Thomas Diesler
AttachmentPart
public InputStream getBase64Content() throws SOAPException
public InputStream getRawContent() throws SOAPException
public byte[] getRawContentBytes() throws SOAPException
public void setBase64Content(InputStream content, String contentType) throws SOAPException
public void setRawContent(InputStream content, String contentType) throws SOAPException
public void setRawContentBytes(byte[] content, int offset, int len, String contentType) throws SOAPException
MessageFactory
public static MessageFactory newInstance() throws SOAPException
public static MessageFactory newInstance(String protocol) throws SOAPException
SAAJMetaFactory
SAAJResult
SOAPBody
public Document extractContentAsDocument() throws SOAPException
SOAPConnection
public SOAPMessage get(Object to) throws SOAPException
SOAPElement
public SOAPElement setElementQName(QName qname) throws SOAPException
SOAPFactory
public static SOAPFactory newInstance() throws SOAPException
public static SOAPFactory newInstance(String protocol) throws SOAPException
public SOAPElement createElement(org.w3c.dom.Element domElement) throws SOAPException
public SOAPElement createElement(QName qname) throws SOAPException
public abstract SOAPFault createFault(String reasonText, QName faultCode) throws SOAPException;
public abstract SOAPFault createFault() throws SOAPException;
SOAPFault
public void addFaultReasonText(String text, Locale locale) throws SOAPException
public void appendFaultSubcode(QName subcode) throws SOAPException
public QName getFaultCodeAsQName()
public String getFaultNode()
public Iterator getFaultReasonLocales() throws SOAPException
public String getFaultReasonText(Locale locale) throws SOAPException
public Iterator getFaultReasonTexts() throws SOAPException
public String getFaultRole()
public Iterator getFaultSubcodes()
public boolean hasDetail()
public void removeAllFaultSubcodes()
public void setFaultNode(String uri) throws SOAPException
public void setFaultRole(String uri) throws SOAPException
SOAPHeader
public SOAPHeaderElement addHeaderElement(QName qname) throws SOAPException
public SOAPHeaderElement addNotUnderstoodHeaderElement(QName qname) throws SOAPException
public SOAPHeaderElement addUpgradeHeaderElement(Iterator soapURIs) throws SOAPException
public SOAPHeaderElement addUpgradeHeaderElement(String[] soapURIs) throws SOAPException
public SOAPHeaderElement addUpgradeHeaderElement(String soapURI) throws SOAPException
SOAPHeaderElement
public boolean getRelay()
public boolean getRole()
public void setRelay(boolean relay) throws SOAPException
SOAPMessage
public AttachmentPart getAttachment(SOAPElement element) throws SOAPException
public void removeAttachments(MimeHeaders headers)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 1 month
[JBoss JIRA] Created: (JBWS-1413) Wrong JAWS package mapping for nested classes
by Ortwin Glück (JIRA)
Wrong JAWS package mapping for nested classes
---------------------------------------------
Key: JBWS-1413
URL: http://jira.jboss.com/jira/browse/JBWS-1413
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: jaxws
Affects Versions: jbossws-1.0.4, jbossws-1.0.3.SP1, jbossws-1.0.3
Environment: JBoss AS 4.0.4 with WS 1.0.3, 1.0.3SP1,
JBoss AS 4.0.5 with WS 1.0.4
Reporter: Ortwin Glück
(Posting this here since forum doesn't escape XML correctly)
I have the data model classes in ch.logobject.test.model.ws.
=== WSDL ===
Initially generated by JBossWS from the model. Later modified manually, deployed in META-INF/wsdl and referenced in the @WebService annotation.
<definitions name='testService' targetNamespace='http://i.session.test.logobject.ch/jaws' xmlns='http://schemas.xmlsoap.org/wsdl/' xmlns:ns1='http://ws.model.test.logobject.ch/jaws' xmlns:soap='http://schemas.xmlsoap.org/wsdl/soap/' xmlns:tns='http://i.session.test.logobject.ch/jaws' xmlns:xsd='http://www.w3.org/2001/XMLSchema'>
<types>
<schema elementFormDefault='qualified' targetNamespace='http://ws.model.test.logobject.ch/jaws' xmlns='http://www.w3.org/2001/XMLSchema' xmlns:ns1='http://i.session.test.logobject.ch/jaws' xmlns:soap11-enc='http://schemas.xmlsoap.org/soap/encoding/' xmlns:tns='http://ws.model.test.logobject.ch/jaws' xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'>
<import namespace='http://i.session.test.logobject.ch/jaws'/>
<complexType name='Person'>
<sequence>
<element name='age' type='int'/>
<element name='name' nillable='true' type='string'/>
<element maxOccurs='unbounded' minOccurs='0' name='profession' nillable='true' type='tns:Profession'/>
</sequence>
</complexType>
<complexType name='Profession'>
<sequence>
<element name='experience' type='int'/>
<element name='name' nillable='true' type='string'/>
</sequence>
</complexType>
<complexType name='Response'>
<sequence>
<element name='errorCode' type='int'/>
</sequence>
</complexType>
</schema>
<schema elementFormDefault='qualified' targetNamespace='http://i.session.test.logobject.ch/jaws' xmlns='http://www.w3.org/2001/XMLSchema' xmlns:ns2='http://ws.model.test.logobject.ch/jaws' xmlns:soap11-enc='http://schemas.xmlsoap.org/soap/encoding/' xmlns:tns='http://i.session.test.logobject.ch/jaws' xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'>
<import namespace='http://ws.model.test.logobject.ch/jaws'/>
<complexType name='echo'>
<sequence>
<element name='String_1' nillable='true' type='string'/>
</sequence>
</complexType>
<complexType name='echoResponse'>
<sequence>
<element name='result' nillable='true' type='string'/>
</sequence>
</complexType>
<complexType name='f'>
<sequence>
<element name='a' nillable='true' type='string'/>
<element name='b' type='int'/>
<element name='d' nillable='true' type='dateTime'/>
<element name='e' type='boolean'/>
<element name='p' nillable='true' type='ns2:Person'/>
</sequence>
</complexType>
<complexType name='fResponse'>
<sequence>
<element name='result' nillable='true' type='ns2:Response'/>
</sequence>
</complexType>
<element name='echo' type='tns:echo'/>
<element name='echoResponse' type='tns:echoResponse'/>
<element name='f' type='tns:f'/>
<element name='fResponse' type='tns:fResponse'/>
</schema>
</types>
<message name='test_echoResponse'>
<part element='tns:echoResponse' name='result'/>
</message>
<message name='test_echo'>
<part element='tns:echo' name='parameters'/>
</message>
<message name='test_f'>
<part element='tns:f' name='parameters'/>
</message>
<message name='test_fResponse'>
<part element='tns:fResponse' name='result'/>
</message>
<portType name='test'>
<operation name='echo'>
<input message='tns:test_echo'/>
<output message='tns:test_echoResponse'/>
</operation>
<operation name='f'>
<input message='tns:test_f'/>
<output message='tns:test_fResponse'/>
</operation>
</portType>
<binding name='testBinding' type='tns:test'>
<soap:binding style='document' transport='http://schemas.xmlsoap.org/soap/http'/>
<operation name='echo'>
<soap:operation soapAction=''/>
<input>
<soap:body use='literal'/>
</input>
<output>
<soap:body use='literal'/>
</output>
</operation>
<operation name='f'>
<soap:operation soapAction=''/>
<input>
<soap:body use='literal'/>
</input>
<output>
<soap:body use='literal'/>
</output>
</operation>
</binding>
<service name='testService'>
<port binding='tns:testBinding' name='testPort'>
<soap:address location='http://127.0.0.1:8080/playground-sb/Websvc'/>
</port>
</service>
</definitions>
== WS interface ==
@WebService(
name="test",
wsdlLocation="META-INF/wsdl/playground.wsdl"
)
@SOAPBinding(style=Style.DOCUMENT, use=Use.LITERAL, parameterStyle=ParameterStyle.WRAPPED)
@Remote
public interface IWebsvc {
@WebMethod
String echo(String s);
@WebMethod
Response f(
@WebParam(name="a") String a,
@WebParam(name="b") int b,
@WebParam(name="d") Calendar d,
@WebParam(name="e") boolean e,
@WebParam(name="p") Person p);
}
== SOAP message (from Eclipse Webservice Explorer) ==
<?xml version="1.0" encoding="UTF-8" ?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:q0="http://i.session.test.logobject.ch/jaws" xmlns:q1="http://ws.model.test.logobject.ch/jaws" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<q0:f>
<q0:a>dg</q0:a>
<q0:b>345</q0:b>
<q0:d>2006-12-07T16:27:31.171Z</q0:d>
<q0:e>true</q0:e>
<q0:p>
<q1:age>345</q1:age>
<q1:name>dfdfg</q1:name>
<q1:profession>
<q1:experience>45</q1:experience>
<q1:name>dfg</q1:name>
</q1:profession>
</q0:p>
</q0:f>
</soapenv:Body>
</soapenv:Envelope>
== Exception ==
Note the wrong package name for the Profession class! The bug renders JBossWS completely unusable for more complex datamodels! Please also check what happens when the model spans several packages. I know JAWS support is not complete, but letting JBoss generate my WSDLs is not an option. They are interoperability documents after all, and changes need to be managed carefully.
org.jboss.ws.WSException: org.jboss.ws.binding.BindingException: org.jboss.ws.jbossxb.UnmarshalException: Failed to parse source: Failed to resolve class name for {http://ws.model.test.logobject.ch/jaws}profession: No ClassLoaders found for: ch.logobject.test.session.i.Profession
[exec] at org.jboss.ws.soap.SOAPContentElement.getObjectValue(SOAPContentElement.java:323)
[exec] at org.jboss.ws.binding.EndpointInvocation.transformPayloadValue(EndpointInvocation.java:233)
[exec] at org.jboss.ws.binding.EndpointInvocation.getRequestParamValue(EndpointInvocation.java:103)
[exec] at org.jboss.ws.binding.EndpointInvocation.getRequestPayload(EndpointInvocation.java:117)
[exec] at org.jboss.ws.integration.jboss.ServiceEndpointInvokerEJB3.invokeServiceEndpoint(ServiceEndpointInvokerEJB3.java:120)
[exec] at org.jboss.ws.server.AbstractServiceEndpointInvoker.invoke(AbstractServiceEndpointInvoker.java:151)
[exec] at org.jboss.ws.server.ServiceEndpoint.handleRequest(ServiceEndpoint.java:195)
[exec] at org.jboss.ws.server.ServiceEndpointManager.processSOAPRequest(ServiceEndpointManager.java:373)
[exec] at org.jboss.ws.server.StandardEndpointServlet.doPost(StandardEndpointServlet.java:116)
[exec] at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
[exec] at org.jboss.ws.server.StandardEndpointServlet.service(StandardEndpointServlet.java:77)
[exec] at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
[exec] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
[exec] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
[exec] at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
[exec] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
[exec] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
[exec] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
[exec] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
[exec] at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
[exec] at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
[exec] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
[exec] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
[exec] at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156)
[exec] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
[exec] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
[exec] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
[exec] at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
[exec] at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
[exec] at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
[exec] at java.lang.Thread.run(Thread.java:595)
[exec] Caused by: org.jboss.ws.binding.BindingException: org.jboss.ws.jbossxb.UnmarshalException: Failed to parse source: Failed to resolve class name for {http://ws.model.test.logobject.ch/jaws}profession: No ClassLoaders found for: ch.logobject.test.session.i.Profession
[exec] at org.jboss.ws.jbossxb.JBossXBDeserializer.deserialize(JBossXBDeserializer.java:103)
[exec] at org.jboss.ws.soap.SOAPContentElement.getObjectValue(SOAPContentElement.java:250)
[exec] ... 30 more
[exec] Caused by: org.jboss.ws.jbossxb.UnmarshalException: Failed to parse source: Failed to resolve class name for {http://ws.model.test.logobject.ch/jaws}profession: No ClassLoaders found for: ch.logobject.test.session.i.Profession
[exec] at org.jboss.ws.jbossxb.JBossXBUnmarshallerImpl.unmarshal(JBossXBUnmarshallerImpl.java:66)
[exec] at org.jboss.ws.jbossxb.JBossXBDeserializer.deserialize(JBossXBDeserializer.java:95)
[exec] ... 31 more
[exec] Caused by: org.jboss.xb.binding.JBossXBException: Failed to parse source: Failed to resolve class name for {http://ws.model.test.logobject.ch/jaws}profession: No ClassLoaders found for: ch.logobject.test.session.i.Profession
[exec] at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:178)
[exec] at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:126)
[exec] at org.jboss.ws.jbossxb.JBossXBUnmarshallerImpl.unmarshal(JBossXBUnmarshallerImpl.java:62)
[exec] ... 32 more
[exec] Caused by: org.jboss.xb.binding.JBossXBRuntimeException: Failed to resolve class name for {http://ws.model.test.logobject.ch/jaws}profession: No ClassLoaders found for: ch.logobject.test.session.i.Profession
[exec] at org.jboss.xb.binding.sunday.unmarshalling.impl.runtime.RtElementHandler.loadClassForTerm(RtElementHandler.java:1038)
[exec] at org.jboss.xb.binding.sunday.unmarshalling.impl.runtime.RtElementHandler.classForNonArrayItem(RtElementHandler.java:1367)
[exec] at org.jboss.xb.binding.sunday.unmarshalling.impl.runtime.RtElementHandler.startElement(RtElementHandler.java:693)
[exec] at org.jboss.xb.binding.sunday.unmarshalling.impl.runtime.RtElementHandler.startParticle(RtElementHandler.java:89)
[exec] at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.startElement(SundayContentHandler.java:504)
[exec] at org.jboss.xb.binding.parser.sax.SaxJBossXBParser$DelegatingContentHandler.startElement(SaxJBossXBParser.java:323)
[exec] at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
[exec] at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown Source)
[exec] at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
[exec] at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
[exec] at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
[exec] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
[exec] at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
[exec] at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
[exec] at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
[exec] at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
[exec] at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:174)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 1 month
[JBoss JIRA] Created: (JBWS-1417) J2eeApplicationMetaData does not give access to <web-context>
by Thomas Diesler (JIRA)
J2eeApplicationMetaData does not give access to <web-context>
-------------------------------------------------------------
Key: JBWS-1417
URL: http://jira.jboss.com/jira/browse/JBWS-1417
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: jaxws
Reporter: Thomas Diesler
Fix For: jbossws-2.0.0
Review and fix. mmd is null for
<jboss-app>
<module>
<web>
<web-uri>jaxws-eardeployment.war</web-uri>
<context-root>/earjse</context-root>
</web>
</module>
</jboss-app>
private static String getContextRoot(WebMetaData wmd, DeploymentUnit unit)
{
String ctxRoot = wmd.getContextRoot();
DeploymentContext parentContext = unit.getDeploymentContext().getParent();
if (ctxRoot == null && parentContext != null)
{
DeploymentUnit parentUnit = parentContext.getDeploymentUnit();
Set<? extends J2eeApplicationMetaData> amdSet = parentUnit.getAllMetaData(J2eeApplicationMetaData.class);
if (amdSet.size() < 1)
throw new IllegalStateException("Cannot find parent meta data");
J2eeApplicationMetaData amd = amdSet.iterator().next();
J2eeModuleMetaData mmd = amd.getModule(unit.getDeploymentContext().getSimpleName());
if (mmd != null)
{
ctxRoot = mmd.getWebContext();
}
}
return ctxRoot;
}
[tdiesler@localhost test]$ ant -Dtest=jaxws/eardeployment test
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 1 month
[JBoss JIRA] Commented: (JBWS-1093) Deploying a war that also contains normal servlets the web.xml is modified as if they are all endpoints
by Darran Lofthouse (JIRA)
[ http://jira.jboss.com/jira/browse/JBWS-1093?page=comments#action_12348124 ]
Darran Lofthouse commented on JBWS-1093:
----------------------------------------
Fixed the test case for JBoss deployments. An implementation is still required for Tomcat.
> Deploying a war that also contains normal servlets the web.xml is modified as if they are all endpoints
> -------------------------------------------------------------------------------------------------------
>
> Key: JBWS-1093
> URL: http://jira.jboss.com/jira/browse/JBWS-1093
> Project: JBoss Web Services
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: jaxrpc
> Affects Versions: jbossws-1.0.1
> Environment: Deploying to JBoss 4.0.4.GA
> Reporter: Darran Lofthouse
> Assigned To: Darran Lofthouse
> Fix For: jbossws-2.0.0, jbossws-1.0.4
>
>
> When deploying a war that contains web services the servlet definitions for the endpoints need to be modified so that they reference a JBossWS servlet instead of the endpoint implementation, this JBossWS implementation then delegates to the endpoint.
> For JBossWS 1.0.0 servlet entries were only modified if they were identified as endpoints based on the deployment of the webservices.xml
> For JBossWS 1.0.1 as part of removing the dependencies on JBossAS this was refactored and now the non web services servlets are identified if their name ends 'Servlet'. The original logic from JBossWS 1.0.0 needs to be reimplemented but we also need to take into acount the different deployment scenarios.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 1 month
[JBoss JIRA] Updated: (JBWS-1093) Deploying a war that also contains normal servlets the web.xml is modified as if they are all endpoints
by Darran Lofthouse (JIRA)
[ http://jira.jboss.com/jira/browse/JBWS-1093?page=all ]
Darran Lofthouse updated JBWS-1093:
-----------------------------------
Fix Version/s: jbossws-2.0.0
> Deploying a war that also contains normal servlets the web.xml is modified as if they are all endpoints
> -------------------------------------------------------------------------------------------------------
>
> Key: JBWS-1093
> URL: http://jira.jboss.com/jira/browse/JBWS-1093
> Project: JBoss Web Services
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: jaxrpc
> Affects Versions: jbossws-1.0.1
> Environment: Deploying to JBoss 4.0.4.GA
> Reporter: Darran Lofthouse
> Assigned To: Darran Lofthouse
> Fix For: jbossws-2.0.0, jbossws-1.0.4
>
>
> When deploying a war that contains web services the servlet definitions for the endpoints need to be modified so that they reference a JBossWS servlet instead of the endpoint implementation, this JBossWS implementation then delegates to the endpoint.
> For JBossWS 1.0.0 servlet entries were only modified if they were identified as endpoints based on the deployment of the webservices.xml
> For JBossWS 1.0.1 as part of removing the dependencies on JBossAS this was refactored and now the non web services servlets are identified if their name ends 'Servlet'. The original logic from JBossWS 1.0.0 needs to be reimplemented but we also need to take into acount the different deployment scenarios.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 1 month
[JBoss JIRA] Reopened: (JBWS-1093) Deploying a war that also contains normal servlets the web.xml is modified as if they are all endpoints
by Darran Lofthouse (JIRA)
[ http://jira.jboss.com/jira/browse/JBWS-1093?page=all ]
Darran Lofthouse reopened JBWS-1093:
------------------------------------
Fix for trunk
> Deploying a war that also contains normal servlets the web.xml is modified as if they are all endpoints
> -------------------------------------------------------------------------------------------------------
>
> Key: JBWS-1093
> URL: http://jira.jboss.com/jira/browse/JBWS-1093
> Project: JBoss Web Services
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: jaxrpc
> Affects Versions: jbossws-1.0.1
> Environment: Deploying to JBoss 4.0.4.GA
> Reporter: Darran Lofthouse
> Assigned To: Darran Lofthouse
> Fix For: jbossws-2.0.0, jbossws-1.0.4
>
>
> When deploying a war that contains web services the servlet definitions for the endpoints need to be modified so that they reference a JBossWS servlet instead of the endpoint implementation, this JBossWS implementation then delegates to the endpoint.
> For JBossWS 1.0.0 servlet entries were only modified if they were identified as endpoints based on the deployment of the webservices.xml
> For JBossWS 1.0.1 as part of removing the dependencies on JBossAS this was refactored and now the non web services servlets are identified if their name ends 'Servlet'. The original logic from JBossWS 1.0.0 needs to be reimplemented but we also need to take into acount the different deployment scenarios.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 1 month
[JBoss JIRA] Commented: (JBWS-981) Virtual host configuration for EJB endpoints
by Darran Lofthouse (JIRA)
[ http://jira.jboss.com/jira/browse/JBWS-981?page=comments#action_12348099 ]
Darran Lofthouse commented on JBWS-981:
---------------------------------------
Ported fix to trunk, however can not enable test a JBossAS is not yet handling virtual-host element in the jboss-web.xml
> Virtual host configuration for EJB endpoints
> --------------------------------------------
>
> Key: JBWS-981
> URL: http://jira.jboss.com/jira/browse/JBWS-981
> Project: JBoss Web Services
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: jaxws
> Reporter: Thomas Diesler
> Assigned To: Darran Lofthouse
> Fix For: jbossws-2.0.0, jbossws-1.0.4
>
>
> I use JBoss 4.0.4 GA and want to deploy a EJB3 (JSR-181) webserivce. Nearly everything is fine. The problem is that the generated servlet of the webservice is deployed on the default virtual host, but I want to change this to another. How is this possible? I tried to add an jboss-web.xml in META-INF directory of the jar-file containing the webservice bean and interface, but with no success.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 1 month