[JBossWS] - Native WS-Reliable Messaging Error - The RM Destination requ
by kerryrward
I am trying to implement a web service that does both MTOM-XOP and reliable messaging. I have the service running with MTOM-XOP and patterned it after the MTOMEndPoint EJB3 example provided in the jboss native ws 3.0.2. I am running JBoss 4.2.2.
I then tried to implement the steps from the Reliable Messaging Tutorial at
http://jbws.dyndns.org/mediawiki/index.php?title=Native_WS-ReliableMessag...
I had problems with the wsdl I modified, so I added the following annotations to the endpoint and let JBOSS build the wsdl instead
@WebService(
| name = "EflexServiceEndpoint",
| serviceName = "EflexService",
| endpointInterface = "com.eflex.webservice.EflexServiceEndpoint"
| // wsdlLocation = "WEB-INF/wsdl/EflexService.wsdl"
| )
| @SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE)
| @BindingType(value = "http://schemas.xmlsoap.org/wsdl/soap/http?mtom=true")
| @EndpointConfig
| (
| configFile = "META-INF/wsrm-jaxws-endpoint-config.xml",
| configName = "Standard WSRM Endpoint"
| )
| @PolicyAttachment(@Policy(
| policyFileLocation = "META-INF/wsrm-exactly-once-in-order-policy.xml",
| scope = PolicyScopeLevel.WSDL_BINDING)
| )
|
| public class EflexServiceEndpointBean implements EflexServiceEndpoint
| {
|
|
Here is the exception I get:
anonymous wrote : 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:221)
| at org.jboss.wsf.stack.jbws.RequestHandlerImpl.processRequest(RequestHandlerImpl.java:466)
| at org.jboss.wsf.stack.jbws.RequestHandlerImpl.handleRequest(RequestHandlerImpl.java:284)
| at org.jboss.wsf.stack.jbws.RequestHandlerImpl.doPost(RequestHandlerImpl.java:201)
| at org.jboss.wsf.stack.jbws.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:134)
| at org.jboss.wsf.stack.jbws.EndpointServlet.service(EndpointServlet.java:84)
|
Which seems to say that my service is expecting WSRM, but that the client has not implemented it.
Here is my client code.
| public final class EflexServiceClient
| {
|
| private static final String serviceURL = "http://localhost:80/wseflex/EflexService";
|
| public static void main(String[] args) throws Exception
| {
| InputStream is = null;
| if (args.length != 0)
| {
| is = new FileInputStream(args[0]);
| } else {
| is = new ByteArrayInputStream("<test>reqest</test>".getBytes());
| }
|
| QName serviceName = new QName("http://webservice.eflex.com/", "EflexService");
| URL wsdlURL = new URL(serviceURL + "?wsdl");
| Service service = Service.create(wsdlURL, serviceName);
| EflexServiceEndpoint port = (EflexServiceEndpoint)service.getPort(EflexServiceEndpoint.class);
| SOAPBinding binding = (SOAPBinding)((BindingProvider)port).getBinding();
| binding.setMTOMEnabled(true);
| ((StubExt)port).setConfigName("Standard Anonymous WSRM Client", "META-INF/wsrm-jaxws-client-config.xml");
|
| Source src = new StreamSource(is);
| SourceRequest request = new SourceRequest();
| request.setData(src);
|
| SourceResponse response = port.echoSource(request);
| Source respSource = response.getData();
|
| ((RMProvider)port).closeSequence();
| ...
|
|
Any help on this is greatly appreciated. Thanks.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4172930#4172930
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4172930
18 years
[Beginners Corner] - Application Access Error
by dasari123
Hi,
iam getting the following exception while trying to access my application that is deployed in Jboss 4.0.2 GA.
java.lang.LinkageError: loader constraints violated when linking org/apache/struts/action/ActionMapping class
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Unknown Source)
at java.lang.Class.getConstructor0(Unknown Source)
at java.lang.Class.newInstance0(Unknown Source)
at java.lang.Class.newInstance(Unknown Source)
at org.apache.struts.chain.commands.util.ClassUtils.getApplicationInstance(ClassUtils.java:66)
at org.apache.struts.chain.commands.servlet.CreateAction.getAction(CreateAction.java:66)
at org.apache.struts.chain.commands.AbstractCreateAction.execute(AbstractCreateAction.java:82)
at org.apache.struts.chain.commands.ActionCommandBase.execute(ActionCommandBase.java:48)
at org.apache.commons.chain.impl.ChainBase.execute(ChainBase.java:190)
at org.apache.commons.chain.generic.LookupCommand.execute(LookupCommand.java:304)
at org.apache.commons.chain.impl.ChainBase.execute(ChainBase.java:190)
at org.apache.struts.chain.ComposableRequestProcessor.process(ComposableRequestProcessor.java:280)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1858)
at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:446)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.bofa.ach.acxis.filter.AuthenticationFilter.doFilter(AuthenticationFilter.java:95)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
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:230)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Unknown Source)
Can any one help me in resolving the issue.
Thanks
dasari
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4172928#4172928
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4172928
18 years
Problems with TimerBean and transaction-rollback
by frusso＠email.it
Hi everybody,
I'm working with JBoss 5 CR 1 playing around with a Timer Bean. Here
are some details:
- the Timer's time-out method is marked with a RequiresNew TX-attribute
- the timeout I create is a one-shot timer (it has to be executed
exactly once)
The Timer Bean's timeout code resembles what follows:
@Timeout
@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
public void foo(Timer timer) {
try {
if(accessDataStore()) {
...
} else {
...
}
} catch(DataStoreException e) {
sessionCtx.setRollbackOnly();
}
}
What upsets me is that whenever the guard of the if statement throws a
DataStoreException, the setRollbackOnly() method is called but the
timer does not get rescheduled: querying the PUBLIC.TIMERS table of
the JBoss Hypersonic internal DB, I can see no timer is scheduled
anymore. This does not sound appropriate to me due to what the JEE 5
spec states:
"If the timer is a single-action timer, the container removes the
timer after the timeout callback method
has been successfully invoked (e.g., when the transaction that has
been started for the invocation of the
timeout callback method commits)." (JSR 220 - EJB Core Contracts and
Requirements v 3.0 Final Release - Section 18.2.2)
I've temporarily solved the problem creating a repetitive-timer and
canceling it if and only if the timeout method succeeds, but I feel
like the right approach was the former one.
Any help is appreciated.
Thanks in advance,
Francesco Russo
18 years