[JBossWS] - Re: Writing a client - no examples for BindingProvider based
by mjhammel
"jeff norton" wrote : I use the same wsprovide and wsconsume targets that you do, but the client still seems to need the WSDL in order to create the service endpoint.
My client doesn't call Service.create() directly. Instead, I reference the client side classes generated by wsconsume:
SubscriberServicesService service = new SubscriberServicesService();
| ss = service.getSubscriberWSPort();
|
| /* Set NEW Endpoint Location */
| BindingProvider bp = (BindingProvider)ss;
| bp.getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, crunchServer);
|
| /* Setup to authenticate with the server. */
| bp.getRequestContext().put(BindingProvider.USERNAME_PROPERTY, subscriberID);
| bp.getRequestContext().put(BindingProvider.PASSWORD_PROPERTY, pw);
The SubscriberServicesService class is one of the classes created by wsconsume. In it you'll find a hard coded path to the WSDL file created by wsprovide. However, this class also has a constructor that can change the location of this file. So when you package your client for use by end users you include the WSDL file generated by wsprovide and reference it's installed location when you do:
SubscriberServicesService service = new SubscriberServicesService("installedLocation/WSDLfile", qname);
My problem is I still don't know what a qname is so I'm not sure how to figure that out at run time so I can update the WSDL location in this manner.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4119744#4119744
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4119744
18 years, 2 months
[JBossWS] - webservice class injecting EJB, nullpointerexception
by HTroeng
Shouldn't it be possible to inject an EJB into a jax-ws webservice class? I get a nullpointerexception when trying to use the EJB, it doesn't look like the ejb is injected into the webservice class?
Code:
Interface:
@WebService
public interface MyService {
public String echoService(String input);
}
Implementation:
@WebService(endpointInterface = "my.package.MyService")
@SOAPBinding(style = Style.RPC)
public class MyServiceImpl implements MyService {
@EJB
SurveillanceService surveillanceService;
@WebMethod(operationName="echoService")
public String echoService(String input) {
boolean isAvail = surveillanceService.isDatabaseAvailable();
return "Hi " + input + ", result from ejb: " + isAvail;
}
}
The EJB does work (confirmed, I use it in other places), It seems that it is something with the Webservice > EJB...
Thanks in advance
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4119706#4119706
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4119706
18 years, 2 months
[JBossWS] - Re: WSSE UsernameToken without HTTP basic auth?
by mikaeljl
So, adding:
reqContext.put(StubExt.PROPERTY_AUTH_TYPE, StubExt.PROPERTY_AUTH_TYPE_WSSE);
|
to the client side removed the http auth header.
Guess this is because the org.jboss.ws.core.client.RemotingConnectionImpl-createRemotingMetaData method is called before the WSSecurityDispatcher calls ctx.put(StubExt.PROPERTY_AUTH_TYPE, StubExt.PROPERTY_AUTH_TYPE_WSSE); ? By setting this property from the client this is avoided.
The problem now is that I can no longer the the login to work properly on the server side.
What should I put in web.xml ? I've tried with
<security-constraint>
| <web-resource-collection>
| <web-resource-name>ProtectedResource</web-resource-name>
| <url-pattern>/*</url-pattern>
| </web-resource-collection>
| <auth-constraint>
| <role-name>friend</role-name>
| </auth-constraint>
| </security-constraint>
| <!-- We do not want http basic authentication
| <login-config>
| <auth-method>BASIC</auth-method>
| <realm-name>JBossWS</realm-name>
| </login-config>
| -->
| <security-role>
| <role-name>friend</role-name>
| </security-role>
|
But that results in the application not being authorized, I've tried to remove the security-constraint but then I can no longer retrieve the current principal information from within my WS implementation...
I've tried to retrieve it using:
Subject caller = (Subject) PolicyContext.getContext(SUBJECT_CONTEXT_KEY);
|
and:
@Resource
| javax.xml.ws.WebServiceContext wsCtx;
| java.security.Principal principal = wsCtx.getUserPrincipal();
But both return null data.
How should I retrive the principal data when using wsse usernametoken?
I can see in the traces that the security information is picked up:
2008-01-14 16:54:37,113 TRACE [org.jboss.security.SecurityAssociation] getSubject, sc=org.jboss.security.SecurityAssociation$SubjectContext@1b6c763{principal=kermit,subject=null}
But how to retrieve it?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4119700#4119700
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4119700
18 years, 2 months
[JBossWS] - Problems with german 'Umlaut'
by Ulf Wiegmann
Hallo,
I'm working for a SOA architectur project and I'm implementing JAX-WS 2.0 web services in the Contract-First way under JBoss 4.2.2.GA .
The service is implemented by an EJB3.0 SLSB, the client is an EJB3.0 SFSB, both runnung in the same container.
The WS-specific java classes will be generated by JBoss 4.2.2 tool wsconsume from the wsdl file for both sites
- service and client.
The problem is, that the UTF-8 decode/encode process doesn't work correctly for german 'umlaut' contained in a string, means that string parameters still contain the UTF-8 representation of an 'umlaut' after transfered to the java target string (in the same wrong way they will be displayed on this page: p.e. Müller , Schöler, Käse) ...
In the wsdl file I specified
<?xml version="1.0" encoding="UTF-8"?>
and
<binding ...>
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http" />
...
soap:body use="literal"
...
But when I use the Eclipse Web Service Explorer instead of the JAX WS 2.0 generated Java client, then at least in the client-server direction all works correctly for the search arguments, meanwhile the search results still contain the UTF-8 representations
What happened?
Ulf
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4119696#4119696
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4119696
18 years, 2 months
[JBossWS] - Re: Writing a client - no examples for BindingProvider based
by mjhammel
"jeff norton" wrote :
| What is your classpath? And what old jars did you need to remove? I have a similar problem getting a client to connect to a web service that has basic authentication enabled. On the service.create(wsdlURL, QName) call I get (my client worked fine before I enabled basic authentication):
|
| | org.jboss.ws.metadata.wsdl.WSDLException: Cannot parse wsdlLocation: http://localhost:8080/foo?wsdl
| |
|
To compile the client, my classpath includes the source to the client, the classes generated by wsconsume and the following:
<path id="client.wsconsume.classpath">
| <fileset dir="${jboss.lib.dir}/endorsed">
| <include name="xercesImpl.jar"/>
| </fileset>
| <fileset dir="${jboss.client.lib.dir}">
| <include name="*.jar"/>
| <exclude name="jaxws-rt.jar"/>
| </fileset>
| <fileset dir="${java.lib.dir}">
| <include name="tools.jar"/>
| </fileset>
| </path>
where
jboss.lib.dir = ${jboss.home}/lib
| jboss.client.lib.dir = ${jboss.home}/client
| java.lib.dir = ${java.home}/lib
I got rid of axis and mail libraries which were being used in the old build. I'm not using Axis in the new project (at least not yet). I also no longer reference an in-build copy of jboss-j2ee.jar (though this is still referenced from the jboss.client.lib.dir) and javax.servlet.jar which were used in the old build (note that I inherited some of this so wasn't clear on why some of those were being used in the first place).
I ran into your problem with not finding the WSDL location after switching to Basic Authentication. In order to get around this I don't try to retrieve the WSDL file from the server during the client build. I have the server side build generate the WSDL file for me using wsprovide, then the client side build reads that file instead of trying to retrieve the WSDL via a URL. My wsconsume looks like this now:
<wsconsume
| fork="true"
| verbose="true"
| destdir="${build.client.classes.dir}"
| sourcedestdir="${build.client.dir}"
| keep="true"
| wsdl="${build.server.dir}/resources/SubscriberServicesService.wsdl">
| <!-- wsdl="http://127.0.0.1:8080/Crunch?wsdl"> -->
| </wsconsume>
My wsprovide looks like this:
<wsprovide
| fork="false"
| keep="true"
| destdir="${build.server.dir}/wsdl"
| resourcedestdir="${build.server.dir}/resources"
| sourcedestdir="${build.server.dir}/source"
| genwsdl="true"
| verbose="true"
| sei="com.cei.crunch.server.ws.SubscriberServices.SubscriberServices">
| <classpath>
| <pathelement path="${build.server.classes.dir}/server"/>
| </classpath>
| </wsprovide>
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4119695#4119695
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4119695
18 years, 2 months
[JBossWS] - Re: Writing a client - no examples for BindingProvider based
by alessio.soldano＠jboss.com
"mjhammel" wrote : "alessio.soldano(a)jboss.com" wrote : This is not your situation, you're not using the persistence context in a servlet, you need injection in a SLSB. And my previous post shows that it works.
|
| That may be, but then there is this discussion:
|
| http://www.jboss.com/index.html?module=bb&op=viewtopic&t=107353
|
| In any case, I've done everything I think I need to do and it still doesn't work. I'd be happy for someone to show me what I've done wrong, but barring that I'd still have to say, in my case, it doesn't work.
|
Once again, you're not trying to use injection in a servlet, you need it in SLSB web service endpoint, don't you? The thread you linked talks about injection in servlets.
This said, going back to your problem, I would suggest you to start from the code I posted in this thread and modify it step by step according to your need.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4119690#4119690
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4119690
18 years, 2 months