[JBossWS] - Username token is not interoperable with gSOAP client
by navin_bhat
Environment:JBOSS AS 4.2.3,JBoss-native-3.0.3,JDK 5 update 15,Windows XP SP2,Eclipse 3.3.x.
Description :
I generated service code from wsdl using wsconsume (contract first approach). I wrote the service skeleton code as a stateless EJB.I enabled WS-Security features as described in the user guide using the following two annotations.
//Enable the login module to verify the user name and password
@SecurityDomain("JBossWSDigest")
//Enable the WS_Security modules
@EndpointConfig(configName ="Standard WSSecurity Endpoint")
I deployed the service in JBoss Application server 4.2.3. The client is written in gSOAP framework (Running on linux) generated from the same wsdl file.WS-Security is enabled in the gSOAP client.When the gSOAP client sends a request, the JBoss service throws an exception, the stack trace is shown below.Let me know if more details are required to debug the issue.
NOTE: The same JBoss service works fine with JBoss client with the same setup as gSOAP client.
Stacktrace:
11:54:42,538 INFO [ReceiveUsernameOperation] Username: PDC
11:54:42,538 INFO [ReceiveUsernameOperation] Password: welcome
11:54:43,226 ERROR [SOAPFaultHelperJAXWS] SOAP request exception
javax.ejb.EJBAccessException: Authentication failure
at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.handleGeneralSecurityException(Ejb3AuthenticationInterceptor.java:68)
at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:70)
at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:110)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:46)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.wsf.container.jboss42.InvocationHandlerEJB3.invoke(InvocationHandlerEJB3.java:103)
at org.jboss.ws.core.server.ServiceEndpointInvoker.invoke(ServiceEndpointInvoker.java:219)
at org.jboss.wsf.stack.jbws.RequestHandlerImpl.processRequest(RequestHandlerImpl.java:476)
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.stack.jbws.EndpointServlet.service(EndpointServlet.java:81)
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 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:182)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
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:157)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
at java.lang.Thread.run(Thread.java:595)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180204#4180204
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180204
18 years
Accesing an EJB from a WS server endpoint
by Razvan Deaconescu
Hi!
I am trying (unsuccessfully) to acces an EJB from within a webservice
endpoint in JBoss 4.2.3GA
The EJB is deployed within an ear. The WS endpoint is deployed in a war
file. I am trying to access the WS endpoint using InitalContext's lookup
method:
--
Context initial = new InitialContext();
Object objref = initial.lookup("java:comp/env/ejb/SimpleDB");
---
However, this fails with "EJB not found exception". I probably didn't do
the correct mapping in the WS web.xml file:
---
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
version="2.4">
<servlet>
<servlet-name>SecureStore</servlet-name>
<servlet-class>SecureStore.SecureStoreServer</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>SecureStore</servlet-name>
<url-pattern>/SecureStoreServer</url-pattern>
</servlet-mapping>
<!-- reference on a remote bean without ejb-link-->
<ejb-ref>
<ejb-ref-name>ejb/Op</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<home>org.objectweb.earsample.beans.secusb.OpHome</home>
<remote>org.objectweb.earsample.beans.secusb.Op</remote>
</ejb-ref>
<!-- reference on a remote bean using ejb-link-->
<ejb-ref>
<ejb-ref-name>ejb/EjbLinkOp</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<home>org.objectweb.earsample.beans.secusb.OpHome</home>
<remote>org.objectweb.earsample.beans.secusb.Op</remote>
<ejb-link>secusb.jar#Op</ejb-link>
</ejb-ref>
<!-- reference on a local bean -->
<ejb-local-ref>
<ejb-ref-name>ejb/OpLocal</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<local-home>org.objectweb.earsample.beans.secusb.OpLocalHome
</local-home>
<local>org.objectweb.earsample.beans.secusb.OpLocal</local>
<ejb-link>secusb.jar#Op</ejb-link>
</ejb-local-ref>
</web-app>
---
I have tried all the above reference methods but none of them worked.
Can anyone give me a hint about what I should do?
Regards,
Razvan
18 years
[JBossWS] - Re: Are ports reusable/concurrent?
by jorgemoralespou_2
I have thought on initially creating a pool of ports, to eache endpoint I must use, and use these instances from pool, this way preventing concurrency, but I'm not sure if this is efficient, or even, really needed. I wanted to know prior to develop, because it`s a lot of work, since I have lots of clients, and different endpoints.
Since my class is going to be invoked acting like a proxiing web service, I can't not guarantee there are not going to be concurrent invocations.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180028#4180028
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180028
18 years
[JBossWS] - Re: Are ports reusable/concurrent?
by jorgemoralespou_2
We have done this:
| // Static initialization of webservice client
| static protected SendSms stub;
|
| static{
| QName qname = new QName(
| "http://www.csapi.org/wsdl/parlayx/sms/send/v2_2/service",
| "SendSms");
| SendSmsService service = new SendSmsService(null, qname);
| stub = service.getSendSms();
| }
|
|
| @Override
| protected String sendMessage(...params...) throws Exception {
| String response = null;
|
| if (stub==null){
| throw new Exception("There is no stub for SendSms PX 2.1 service created.");
| }
|
| //Configure stub
| stub.getRequestContext().put(StubExt.PROPERTY_CLIENT_TIMEOUT,1000);
| stub.getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, ...);
| response = stub.sendSms(...params....);
| return response;
| }
|
|
But I doing tests to see if it is ThreadSafe to do this, or configuring an endpoint on the stub, will afect other clients sending messages to a previously configured stub in a previous (but concurrent) call.
In this cases I see that Stub generation only happens in the static initialization, and this way, performance is much more better.
Am I doing something wrong?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4179980#4179980
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4179980
18 years