January 2008 - jbossws-issues - Jboss List Archives

[JBoss JIRA] Created: (JBWS-1872) EJB3 WebService implementation must have @Remote (instead of @Local) Business interface

by Michael McKibben (JIRA)

EJB3 WebService implementation must have @Remote (instead of @Local) Business interface --------------------------------------------------------------------------------------- Key: JBWS-1872 URL: http://jira.jboss.com/jira/browse/JBWS-1872 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: jbossws-2.0.1 Environment: JBossAS 4.2.2.GA Reporter: Michael McKibben When my EJB has a @Local annotation I get the following error: 2007-10-24 17:55:04,811 ERROR [org.jboss.deployment.MainDeployer] Could not start deployment: file:/home/mike/Applications/jboss-4.2.2.GA/server/all/deploy/admanager-ws.jar java.lang.NullPointerException at org.jboss.ws.metadata.builder.jaxws.JAXWSMetaDataBuilderEJB3.buildMetaData(JAXWSMetaDataBuilderEJB3.java:69) at org.jboss.wsf.stack.jbws.UnifiedMetaDataDeploymentAspect.create(UnifiedMetaDataDeploymentAspect.java:71) at org.jboss.wsf.framework.deployment.DeploymentAspectManagerImpl.deploy(DeploymentAspectManagerImpl.java:115) at org.jboss.wsf.container.jboss42.ArchiveDeployerHook.deploy(ArchiveDeployerHook.java:97) at org.jboss.wsf.container.jboss42.DeployerInterceptor.start(DeployerInterceptor.java:90) at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.start(SubDeployerInterceptorSupport.java:188) at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:95) 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 $Proxy34.start(Unknown Source) 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 sun.reflect.GeneratedMethodAccessor25.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 $Proxy9.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.GeneratedMethodAccessor3.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:508) at java.lang.Thread.run(Thread.java:595) Replacing @Local annotation with @Remote, my EJB endpoint deploys cleanly -- 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, 2 months

3
3
0 / 0

[JBoss JIRA] Created: (JBWS-1973) MTOM/XOP attachments inlined when using JAX-WS handlers

by Alessio Soldano (JIRA)

MTOM/XOP attachments inlined when using JAX-WS handlers ------------------------------------------------------- Key: JBWS-1973 URL: http://jira.jboss.com/jira/browse/JBWS-1973 Project: JBoss Web Services Issue Type: Bug Security Level: Public (Everyone can see) Components: jbossws-native Affects Versions: jbossws-2.0.2 Reporter: Alessio Soldano Assigned To: Alessio Soldano I found out that eventual attachments are moved inline when there are jaxws handlers in place. In order to prevent this, calls to XOPContent.visitAndRestoreXOPData() were added in the HandlerDelegateJAXRPC, so that the model transits to the xml-valid and the xop:Include are restored: boolean status = (handlerChain != null ? handlerChain.handleResponse(msgContext) : true); if (type == HandlerType.ENDPOINT) XOPContext.visitAndRestoreXOPData(); return status; This should be done for JAXWS too. -- 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, 2 months

3
3
0 / 0

[JBoss JIRA] Created: (JBWS-1958) Clarification: @EndpointConfig overrides through jboss.xml

by Heiko Braun (JIRA)

Clarification: @EndpointConfig overrides through jboss.xml ---------------------------------------------------------- Key: JBWS-1958 URL: http://jira.jboss.com/jira/browse/JBWS-1958 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: jbossws-2.0.2 Reporter: Heiko Braun Assigned To: Heiko Braun Fix For: jbossws-native-2.0.4 jboss.xml allows config-name and config-file to be set for a deployment. WRT metro and cxf the @EndpointConfig annotation does actually need to move to the SPI. -- 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, 2 months

2
3
0 / 0

[JBoss JIRA] Created: (JBWS-1910) Cannot provide WebServiceContext

by Heiko Braun (JIRA)

Cannot provide WebServiceContext -------------------------------- Key: JBWS-1910 URL: http://jira.jboss.com/jira/browse/JBWS-1910 Project: JBoss Web Services Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Heiko Braun Fix For: jbossws-2.0.3 Invocation from ESB cannot supply a ServletContext, whic is a regular use case. This causes the WebServiceContext creation to fail. This requires a refactoring that removes the dependency upon JSDK classes. -- 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, 2 months

2
9
0 / 0

[JBoss JIRA] Created: (JBWS-1785) Customized ESB DeploymentAspectManager

by Heiko Braun (JIRA)

Customized ESB DeploymentAspectManager -------------------------------------- Key: JBWS-1785 URL: http://jira.jboss.com/jira/browse/JBWS-1785 Project: JBoss Web Services Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Heiko Braun Fix For: jbossws-2.1.0 -- 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, 2 months

2
3
0 / 0

[JBoss JIRA] Created: (JBWS-1828) Investigate and design WS-RM Message Store Interface(s)

by Richard Opalka (JIRA)

Investigate and design WS-RM Message Store Interface(s) ------------------------------------------------------- Key: JBWS-1828 URL: http://jira.jboss.com/jira/browse/JBWS-1828 Project: JBoss Web Services Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Richard Opalka Assigned To: Richard Opalka -- 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, 2 months

2
3
0 / 0

[JBoss JIRA] Created: (JBWS-1829) Implement Memory Based WS-RM Message Store

by Richard Opalka (JIRA)

Implement Memory Based WS-RM Message Store ------------------------------------------ Key: JBWS-1829 URL: http://jira.jboss.com/jira/browse/JBWS-1829 Project: JBoss Web Services Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Richard Opalka Assigned To: Richard Opalka -- 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, 2 months

2
3
0 / 0

[JBoss JIRA] Created: (JBWS-1976) Investigate how to decouple RM Sender/RM Reciever from Client Proxy/Server Endpoint

by Richard Opalka (JIRA)

Investigate how to decouple RM Sender/RM Reciever from Client Proxy/Server Endpoint ----------------------------------------------------------------------------------- Key: JBWS-1976 URL: http://jira.jboss.com/jira/browse/JBWS-1976 Project: JBoss Web Services Issue Type: Task Security Level: Public (Everyone can see) Components: jbossws-native Reporter: Richard Opalka Assigned To: Richard Opalka Fix For: jbossws-native-2.0.4 Thomas Diesler wrote: In my understanding the RM Sender/Receiver must be high available (HA) components such that the Client can (always) communicate with the RM Sender and likewise the RM Sender can always communicate with the RM Receiver. Client <--> RM Sender <-------> RM Receiver <--> Endpoint QoS QoS On the contrary, if the RM Sender is coupled with the client proxy or the RM Receiver is coupled with the Endpoint, it would in my opinion defeat the purpose of RM. In other words, if the RM Receiver is only available if the Endpoint is available, the client might as well talk to the Endpoint directly. -- 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, 2 months

1
3
0 / 0

[JBoss JIRA] Created: (JBWS-1402) Ejb3 JMSTransportSupport

by John Gilbert (JIRA)

Ejb3 JMSTransportSupport ------------------------ Key: JBWS-1402 URL: http://jira.jboss.com/jira/browse/JBWS-1402 Project: JBoss Web Services Issue Type: Patch Security Level: Public (Everyone can see) Environment: I made these changes to work with JBossWS 1.0.3 and JBoss AS 4.0.4. Reporter: John Gilbert Allow the use of Ejb3 MDBs to support soap over jms. Note: This is a different solution then outlined in the referenced forum discussion. Here is a sample Ejb3 MDB which is also annotated with JWS annotations: @MessageDriven(activationConfig = { @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"), @ActivationConfigProperty(propertyName = "destination", propertyValue = "queue/AuthorizationCallbackQueue"), @ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "AUTO_ACKNOWLEDGE"), @ActivationConfigProperty(propertyName = "subscriptionDurability", propertyValue = "Durable") }) @WebService(name = "AuthorizationCallbackService", serviceName = "AuthorizationCallbackService") @SOAPBinding(style = Style.RPC, use = Use.LITERAL, parameterStyle = ParameterStyle.BARE) @SOAPMessageHandlers( { @SOAPMessageHandler(className = "org.jboss.ws.wsse.WSSecurityHandlerInbound") }) @SecurityDomain("portal") public class AuthorizationCallbackMDB extends JMSTransportSupport implements MessageListener { @WebMethod @Oneway public void authorizationResponse(@WebParam(name = "paymentId") long paymentId, @WebParam(name = "status") boolean status) throws java.rmi.RemoteException { ... } } The following changes where made to get this to work: jbossws-core.jar -> org.jboss.ws.server.ServiceEndpointInfo constructor } else if (udi.type == UnifiedDeploymentInfo.Type.JSR181_EJB3) { String ejbName = sepMetaData.getLinkName(); UnifiedApplicationMetaData applMetaData = (UnifiedApplicationMetaData) udi.metaData; UnifiedBeanMetaData beanMetaData = (UnifiedBeanMetaData) applMetaData .getBeanByEjbName(ejbName); if (beanMetaData instanceof UnifiedMessageDrivenMetaData) { this.type = Type.MDB21; } else { this.type = Type.SLSB30; } } jbossws-jboss-integration.jar -> org.jboss.ws.integration.jboss.DeployerInterceptorEJB3 protected UnifiedDeploymentInfo createUnifiedDeploymentInfo(DeploymentInfo di) throws Exception { ... for (Object container : ejb3Module.getContainers().values()) { if (container instanceof StatelessContainer) { StatelessContainer slc = (StatelessContainer) container; UnifiedBeanMetaData uslc = new UnifiedBeanMetaData(); uslc.setEjbName(slc.getEjbName()); uslc.setEjbClass(slc.getBeanClassName()); beans.add(uslc); } if (container instanceof MDB) { MDB mdc = (MDB) container; if (mdc.resolveAnnotation(WebService.class) != null) { UnifiedBeanMetaData umdc = new UnifiedMessageDrivenMetaData(); umdc.setEjbName(mdc.getEjbName()); umdc.setEjbClass(mdc.getBeanClassName()); ActivationConfigPropertyMetaData p = (ActivationConfigPropertyMetaData) mdc .getActivationConfigProperties().get("destination"); ((UnifiedMessageDrivenMetaData) umdc) .setDestinationJndiName(p.getValue()); beans.add(umdc); } } } ... } protected boolean isWebserviceDeployment(DeploymentInfo di) { ... for (Object manager : ejb3Module.getContainers().values()) { if (manager instanceof StatelessContainer) { StatelessContainer container = (StatelessContainer) manager; if (container.resolveAnnotation(WebService.class) != null) { isWebserviceDeployment = true; break; } } if (manager instanceof MDB) { MDB container = (MDB) manager; if (container.resolveAnnotation(WebService.class) != null) { isWebserviceDeployment = true; break; } } } ... } The only thing I couldn't fix was the generated endpoint address in the wsdl. It still comes out like this <soap:address location='http://localhost:8080/payment-authorizer-0/AuthorizationCallbackMDB'/> instead of something like this <soap:address location='jms://localhost/queue/AuthorizationCallbackQueue'/> On a similar note I have created a straight forward jboss remoting JmsClientInvoker. It only works with Oneway messages, which is reasonable. -- 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, 2 months

3
2
0 / 0

[JBoss JIRA] Created: (JBWS-1432) WSDL to Java - If parameters can not be unwrapped fall back to bare and log a warning.

by Darran Lofthouse (JIRA)

WSDL to Java - If parameters can not be unwrapped fall back to bare and log a warning. --------------------------------------------------------------------------------------- Key: JBWS-1432 URL: http://jira.jboss.com/jira/browse/JBWS-1432 Project: JBoss Web Services Issue Type: Feature Request Security Level: Public (Everyone can see) Components: wstools Reporter: Darran Lofthouse Assigned To: Darran Lofthouse Fix For: jbossws-1.2.0.CR1 WSDL to Java - If parameters can not be unwrapped fall back to bare and log a warning. At the moment unless the parameters for all operations can be unwrapped we throw an exception and stop processing the WSDL. If instead we unwrap what we can it will make it a lot easier to configure WSDL to Java and users will not need to worry about setting the parameter-style unless they want to force bare style. -- 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, 2 months

2
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbossws-issues January 2008