[JBoss JIRA] Commented: (JBWS-1592) Investigate NPE in opMetaData.getQName() with WS-Security
by Heiko Braun (JIRA)
[ http://jira.jboss.com/jira/browse/JBWS-1592?page=comments#action_12362325 ]
Heiko Braun commented on JBWS-1592:
-----------------------------------
Requires further information:
"Could you provide me with the SOAP messages in transit that have been causing this error?
I am unable to reproduce the exception. But I am pretty sure it's a client side configuration problem.
The messages send from the client have to plain SOAP messages, lacking security headers. But in order to verify i'll need some example requests."
> Investigate NPE in opMetaData.getQName() with WS-Security
> ---------------------------------------------------------
>
> Key: JBWS-1592
> URL: http://jira.jboss.com/jira/browse/JBWS-1592
> Project: JBoss Web Services
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: ws-security
> Reporter: Jason T. Greene
> Assigned To: Heiko Braun
> Fix For: jbossws-2.0.0
>
>
> java.lang.NullPointerException
> at org.jboss.ws.extensions.security.WSSecurityDispatcher.handleInbound(WSSecurityDispatcher.java:13
> 0)
> at org.jboss.ws.extensions.security.jaxws.WSSecurityHandler.handleInboundSecurity(WSSecurityHandler
> .java:59)
> at org.jboss.ws.extensions.security.jaxws.WSSecurityHandlerServer.handleInbound(WSSecurityHandlerSe
> rver.java:41)
> at org.jboss.ws.core.jaxws.handler.GenericHandler.handleMessage(GenericHandler.java:55)
> at org.jboss.ws.core.jaxws.handler.HandlerChainExecutor.handleMessage(HandlerChainExecutor.java:276
> )
> at org.jboss.ws.core.jaxws.handler.HandlerChainExecutor.handleRequest(HandlerChainExecutor.java:112
> )
> at org.jboss.ws.core.jaxws.handler.HandlerDelegateJAXWS.callRequestHandlerChain(HandlerDelegateJAXW
> S.java:65)
> at org.jboss.ws.core.server.AbstractServiceEndpointInvoker.callRequestHandlerChain(AbstractServiceE
> Client:
> sdlURL = new URL("http://chaponniere-linux:8080/procedures-beans/PstProcedureManager?wsdl");
> URL securityURL = new File("jboss-wsse-client.xml").toURL();
> QName serviceName = new QName("http://procedure.procedures/", "PstProcedureManagerService");
> Service service = Service.create(wsdlURL, serviceName);
> ((ServiceExt)service).setSecurityConfig(securityURL.toExternalForm());
>
> PstProcedureManager port = (PstProcedureManager)service.getPort(PstProcedureManager.class);
> //Hello port = (Hello)service.getPort(Hello.class);
> ((StubExt)port).setConfigName("Standard WSSecurity Client");
>
> Map<String, Object> reqContext = ((BindingProvider)port).getRequestContext();
> //reqContext.put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, "http://localhost:8080/jaxws-samples-wssecurity-encrypt");
> reqContext.put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, "http://chaponniere-linux:8080/procedures-beans/PstProcedureManager?wsdl");
>
> String procedureNumber = port.getProcedure(1).getNumber();
> System.out.println(procedureNumber);
> Server:
> @WebService
> @EndpointConfig(configName = "Standard WSSecurity Endpoint")
> public class PstProcedureManager implements PstProcedureInterface {
> @PersistenceContext
> protected EntityManager em;
>
> @WebMethod
> public PstProcedureBean getProcedure(int pId) {
> Collection procedureCol =
> em.createQuery("from PstProcedureBean procedureBean where procedureBean.id = :id")
> .setParameter ("id", pId)
> .getResultList();
>
> return (PstProcedureBean)procedureCol.iterator().next();
> }
> }
>
--
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
16 years, 11 months
[JBoss JIRA] Commented: (JBWS-1622) Multiple context root not supported
by Rick Reumann (JIRA)
[ http://jira.jboss.com/jira/browse/JBWS-1622?page=comments#action_12362211 ]
Rick Reumann commented on JBWS-1622:
------------------------------------
Can someone please more specific about what needs to be done to address this issue? This is very frustrating since I see nothing about this issue in the users guide.
Here was an example of an initial web service I was trying to deploy (which works fine, until I try to deploy another webservice using the same approach):
@WebService
@SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.WRAPPED)
public interface Echo {
@WebMethod String testEcho(String s);
}
@Stateless
@WebService(endpointInterface="com.foobar.edsf.example.ejb.webservices.Echo")
public class EchoBean {
public String testEcho(String s) {
return s;
}
}
If I deploy a similar webservice like the above, I'll get the Multiple context root not supported error. Am I doing something unorthodox or is this a bug? My EJB3 book and the examples that come with the jboss patch here: http://docs.jboss.org/ejb3/app-server/tutorial/installing.html show examples like I'm doing above. Now it seems like I have to use a non-standard @WebContext annotation? I can deal with using the @WebContext annotation but can someone give specifics on how to use it to handle this problem?
WITHOUT adding a @WebContext I'll end up with a wsdl location like:
http://machine-name:8080/EchoBeanService/EchoBean?wsdl
If I try to declare a @WebContext I won't get the multiple context root error, but it changes the wsdl path to a path that it can't find. For example if I give it a path:
@WebContext(contextRoot="/EDSF-tests", secureWSDLAccess=false)
I end up with a wsdl URL:
http://machine-name:8080/EDSF-tests/EchoBean?wsdl
Which doesn't point to the wsdl anymore. Can someone give me some pointers about what I'm doing wrong? Thanks
> Multiple context root not supported
> -----------------------------------
>
> Key: JBWS-1622
> URL: http://jira.jboss.com/jira/browse/JBWS-1622
> Project: JBoss Web Services
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: jbossws-1.2.1
> Environment: JBoss 4.0.5 + EJB3 + JBossWS 1.2.1.GA
> Reporter: Stephan Heffner
>
> Switching JBossWS from 1.2.0.SP1 to 1.2.1.GA I got this error message starting my EAR based application including four Services:
> 09:36:13,998 ERROR [ServiceEndpointPublisher] Cannot obtain waURL for: joe.ear/joe.jar
> 09:36:14,001 ERROR [MainDeployer] Could not create deployment: file:/home/heffner/Java/jboss-4.0.5.GA/server/default/deploy/joe.ear/joe.jar/
> org.jboss.deployment.DeploymentException: Cannot create service endpoint; - nested throwable: (org.jboss.ws.WSException: Multiple context root not supported)
> at org.jboss.deployment.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:53)
> at org.jboss.ws.integration.jboss42.DeployerInterceptor.create(DeployerInterceptor.java:83)
> at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.create(SubDeployerInterceptorSupport.java:180)
> at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:91)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> at $Proxy29.create(Unknown Source)
> at org.jboss.deployment.MainDeployer.create(MainDeployer.java:969)
> at org.jboss.deployment.MainDeployer.create(MainDeployer.java:959)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:818)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
> at sun.reflect.GeneratedMethodAccessor19.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> at $Proxy8.deploy(Unknown Source)
> at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
> at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
> at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
> at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
> at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
> at $Proxy0.start(Unknown Source)
> at org.jboss.system.ServiceController.start(ServiceController.java:417)
> at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> at $Proxy4.start(Unknown Source)
> at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
> at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> at $Proxy5.deploy(Unknown Source)
> at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
> at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
> at org.jboss.Main.boot(Main.java:200)
> at org.jboss.Main$1.run(Main.java:490)
> at java.lang.Thread.run(Thread.java:595)
> Caused by: org.jboss.ws.WSException: Multiple context root not supported
> at org.jboss.ws.integration.jboss42.ServiceEndpointGeneratorEJB.createJBossWebAppDescriptor(ServiceEndpointGeneratorEJB.java:258)
> at org.jboss.ws.integration.jboss42.ServiceEndpointGeneratorEJB.generatWebDeployment(ServiceEndpointGeneratorEJB.java:71)
> at org.jboss.ws.integration.jboss42.DeployerInterceptorEJB3.generateWebDeployment(DeployerInterceptorEJB3.java:127)
> at org.jboss.ws.integration.jboss42.DeployerInterceptorEJB.createServiceEndpoint(DeployerInterceptorEJB.java:49)
> at org.jboss.ws.integration.jboss42.DeployerInterceptor.create(DeployerInterceptor.java:78)
> ... 75 more
> Switching back to 1.2.0.SP1 works.
> I'm using onyl Annotations to configure the provided services. Example of one test service:
> @Local
> @WebService
> public interface DatabaseService
> {
> @WebMethod
> public String dbmsAlert(@WebParam(name = "alert") String alert, @WebParam(name = "message") String message);
> }
> @Stateless
> @WebService(endpointInterface = "de.spiegel.joe.service.DatabaseService")
> public class DatabaseServiceImpl implements DatabaseService
> {
> private static final Logger log = Logger.getLogger(DatabaseServiceImpl.class);
> @PersistenceContext
> EntityManager entityManager;
>
> public String dbmsAlert(String alert, String message)
> {
> log.debug("Received alert '"+alert+"' with message '"+message+"'.");
> return "OK";
> }
> }
> What can I do to solve this issue?
--
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
16 years, 11 months
[JBoss JIRA] Created: (JBWS-1496) Fix BPEL samples
by Thomas Diesler (JIRA)
Fix BPEL samples
----------------
Key: JBWS-1496
URL: http://jira.jboss.com/jira/browse/JBWS-1496
Project: JBoss Web Services
Issue Type: Task
Security Level: Public (Everyone can see)
Reporter: Thomas Diesler
Assigned To: Alejandro Guizar
Fix For: jbossws-1.2.0
Please fix for 1.2.0
This is seen in jboss50
java.lang.NullPointerException
at org.jbpm.bpel.integration.server.SoapHandler.handleRequest(SoapHandler.java:183)
at org.jboss.ws.core.jaxrpc.handler.HandlerWrapper.handleRequest(HandlerWrapper.java:121)
at org.jboss.ws.core.jaxrpc.handler.HandlerChainBaseImpl.handleRequestInternal(HandlerChainBaseImpl.java:275)
at org.jboss.ws.core.jaxrpc.handler.HandlerChainBaseImpl.handleRequest(HandlerChainBaseImpl.java:235)
at org.jboss.ws.core.jaxrpc.handler.ServerHandlerChain.handleRequest(ServerHandlerChain.java:53)
at org.jboss.ws.core.jaxrpc.handler.HandlerDelegateJAXRPC.callRequestHandlerChain(HandlerDelegateJAXRPC.java:96)
at org.jboss.ws.core.server.AbstractServiceEndpointInvoker.callRequestHandlerChain(AbstractServiceEndpointInvoker.java:99)
To do the QA run
$ cd build
$ ant hudson-setup
You don't have to fix the standalone samples.
--
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
16 years, 11 months
[JBoss JIRA] Updated: (JBWS-981) Virtual host configuration for EJB endpoints
by Darran Lofthouse (JIRA)
[ http://jira.jboss.com/jira/browse/JBWS-981?page=all ]
Darran Lofthouse updated JBWS-981:
----------------------------------
Fix Version/s: jbossws-2.0.1
(was: jbossws-2.0.0)
Dependent JBossAS task is still outstanding.
> 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.1
>
>
> 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
16 years, 12 months
[JBoss JIRA] Updated: (JBWS-1133) Unpacked JSR-181 POJO deployment fails for subsquent deployment.
by Darran Lofthouse (JIRA)
[ http://jira.jboss.com/jira/browse/JBWS-1133?page=all ]
Darran Lofthouse updated JBWS-1133:
-----------------------------------
Fix Version/s: jbossws-2.0.1
(was: jbossws-2.0.0)
Still one issue to be respolved as this fix causes the generated war of an EJB deployment to be incorrectly deployed as a new web service deployment.
Some indicator is required to stop the isWebserviceDeployment call on the generated web app.
> Unpacked JSR-181 POJO deployment fails for subsquent deployment.
> ----------------------------------------------------------------
>
> Key: JBWS-1133
> URL: http://jira.jboss.com/jira/browse/JBWS-1133
> Project: JBoss Web Services
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: jaxws
> Affects Versions: jbossws-1.0.1
> Reporter: Darran Lofthouse
> Assigned To: Darran Lofthouse
> Fix For: jbossws-2.0.1
>
>
> Unpacked JSR-181 POJO deployments are not deployed correctly for subsequent server starts.
> This is because when this is first deployed the web.xml which is part of the deployment is modified so that the JBossServiceEndpointServlet servlet is used.
> On subsequent deployments the web.xml is parsed but because all of the servlet classes have been replaced with the JBossServiceEndpointServlet it is JBossServiceEndpointServlet that is checked for annotations instead of the endpoint class.
--
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
16 years, 12 months
[JBoss JIRA] Reopened: (JBWS-429) Create Custom Holders for Custom types that define INOUT parameters and OUT parameters [WSDLToJava Subsystem]
by Darran Lofthouse (JIRA)
[ http://jira.jboss.com/jira/browse/JBWS-429?page=all ]
Darran Lofthouse reopened JBWS-429:
-----------------------------------
> Create Custom Holders for Custom types that define INOUT parameters and OUT parameters [WSDLToJava Subsystem]
> -------------------------------------------------------------------------------------------------------------
>
> Key: JBWS-429
> URL: http://jira.jboss.com/jira/browse/JBWS-429
> Project: JBoss Web Services
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: wstools
> Reporter: Anil Saldhana
> Assigned To: Darran Lofthouse
> Fix For: jbossws-2.0.0
>
>
> WSDL 1.1 can define IN-OUT parameters and OUT. Then there is a need to generate Holders by the WSDLToJava component of JBossWS Tools.
> Now if the type that defines an INOUT parameter, is a type that is NOT supported by standard Jax-RPC types, then custom holder classes need to be generated.
> If the type is supported by Jax-RPC, then standard holders defined in the javax.xml.rpc.holders package can be used. Examples are ShortWrapperHolder, IntegerWrapperHolder, FloatWrapperHolder etc.
> Custom Holders will be handled after the first release of wstools. If there is demand, I can raise the priority.
--
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
16 years, 12 months
[JBoss JIRA] Reopened: (JBWS-1607) WSDL To Java - document/literal, IN OUT parameter incorectly used as return type.
by Darran Lofthouse (JIRA)
[ http://jira.jboss.com/jira/browse/JBWS-1607?page=all ]
Darran Lofthouse reopened JBWS-1607:
------------------------------------
> WSDL To Java - document/literal, IN OUT parameter incorectly used as return type.
> ---------------------------------------------------------------------------------
>
> Key: JBWS-1607
> URL: http://jira.jboss.com/jira/browse/JBWS-1607
> Project: JBoss Web Services
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: wstools
> Reporter: Darran Lofthouse
> Assigned To: Darran Lofthouse
> Fix For: jbossws-2.0.0
>
>
> From the JAX-RPC specification: -
> "If there is a single unlisted output part that is not a component of an inout parameter, then it is the return type. Otherwise, the return type is void."
> A WSDL with the following messages: -
> <message name='PhoneBook_lookup'>
> <part element='ns1:lookup' name='lookup'/>
> </message>
> <message name='PhoneBook_lookupResponse'>
> <part element='ns1:lookup' name='lookup'/>
> </message>
> Causes the following method to be generated in the SEI: -
> public java.lang.String lookup(javax.xml.rpc.holders.StringHolder lookup) throws java.rmi.RemoteException;
> The return type should be void.
--
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
16 years, 12 months
[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:
------------------------------------
> 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
16 years, 12 months