soap - Consuming WCF Service with Digest authentication from Java -

soap - Consuming WCF Service with Digest authentication from Java -

i want create client in java connects web service requires digest authentication. since not familiar java , java stack, i've made research , came across jax-ws, axis2, xcf, , metro. have learned jax-ws api , there reference implementation in jdk lacks digest authorization support.

my first effort utilize axis2 since there built-in back upwards in eclipse ide. next code seems follow digest authentication workflow somehow still fails authorization in end.

service1stub stub = new service1stub(); httptransportproperties.authenticator authenticator = new authenticator(); list<string> authschemes = new arraylist<string>(); authschemes.add(authenticator.digest); authenticator.setauthschemes(authschemes); authenticator.setusername("doman user"); authenticator.setpassword("domain password"); authenticator.setpreemptiveauthentication(true); options options = stub._getserviceclient().getoptions(); options.setproperty(org.apache.axis2.transport.http.httpconstants.authenticate, authenticator); options.setproperty(org.apache.axis2.transport.http.httpconstants.chunked, org.apache.axis2.constants.value_false); getdata getdata = new getdata(); getdata.setvalue(25); getdataresponse info = stub.getdata(getdata); system.out.println(data.getgetdataresult());

my sec effort utilize metro framework errors related jaxb versions.

java.lang.linkageerror: jaxb 2.1 api beingness loaded bootstrap classloader, ri needs 2.2 api.

i have utilize jdk 1.6.0_03 guess happening because of jdk version mismatch, don't want utilize suggested "endorsed directory mechanism" because might cause lots of troubles during deployment.

i totally lost , looking simplest, quickest , up-to-date way of consuming web service requires digest authentication in java? preferably little dependencies possible.

java classloading mess, sorry. root cause there no strong names there in .net world, , hence runtime linker takes whatever match comes first on classpath, regardless of whether that's library version code compiled against. osgi scheme solves problem, never gained mainstream adoption.

the error message cited:

java.lang.linkageerror: jaxb 2.1 api beingness loaded bootstrap classloader, ri needs 2.2 api.

is uncharacteristically useful , specific, of time happens instead you're left staring @ nosuchmethoderror or of sort. on time, larn recognise these library version mismatches. in case, library author(s) have written code recognize mutual error case , print improve error message (bless 'em).

rant over, here's info hope set on right track:

java classloaders hierarchical , resolution bottom-up but there's blessed class loader @ root of hierarchy that's responsible loading core runtime library vendor shenanigans have led lot of stuff getting included in core runtime library shouldn't have been in there, it's shortcut becoming dominant in otherwise darwinistic selection process. jaxb 1 of these things, you've found out. jaxb2 pretty decent, evolves independent of core runtime and, well, here are. the jdk , jre installation has folder called lib\endorsed can add together jar files need loaded root loader, bypassing what's in rt.jar.

in summary, if manually add together 2.2 version of jaxb library %java_home%\lib\endorsed, should override included 2.1 version , web service client deploy. have happen on every scheme run web service client, until jdk updated 7.x version included jaxb 2.2. if same jvm running other jaxb based applications, these may or may not break result.

yes, painful. tangent investigate deliberately utilize older version of metro that's built jaxb 2.1. long you're bound deploying on 1.6.0_03, may improve option, despite losing of recent improvements in metro.

updated: here's blog post on topic. contains links farther information.

java soap jax-ws axis2 java-metro-framework