RE: Configure SSL config for Axis2 1.4.1 client to connect to SOAP/ssl WS
The source of solution was: http://osdir.com/ml/axis-user-ws.apache.org/2009-06/msg00307.html The solution is to set up the following properties for the JVM: javax.net.ssl.keyStore=fully qualified path to keystore file javax.net.ssl.keyStoreType=type of keystore, i.e, JKS javax.net.ssl.keyStorePassword=keystore password javax.net.ssl.trustStore=fully qualified path to truststore file javax.net.ssl.trustStoreType=type of truststore, i.e, JKS javax.net.ssl.trustStorePassword=truststore password javax.net.ssl.contextProvider=provider, i.e. JSSE This is basically the same as depicted by Thilina Mahesh Buddhika: It can be achieved either ny using the -Dpropname=propvalue pattern on the command line, by setting appropriate JVM startup properties using the administration interface of your choice or by explicitly setting that in the Java code. Using system properties for the JVM may be more useful since this way it is guaranteed that the values are present from the time the JVM starts. This is difficult to achieve with explicit Java in a J2EE environment. Regards, Christian -Original Message- From: Christian Gosch Sent: Thursday, December 03, 2009 1:06 PM To: axis-user Subject: Configure SSL config for Axis2 1.4.1 client to connect to SOAP/ssl WS Hi, I have an Axis2 1.4.1 SOAP client (code generated with wsdl2java using XMLBeans) and can use this client successfully to execute operations on a remote server which only accepts SOAP/ssl (https) requests. I do not configure something special: I simply take the https:... URL as it is, and use it, and Axis2 together with the accompanying libraries does the remaining. But the client code is part of a J2EE application deployed on IBM WebSphere 6.0.2, and this application also has to make calls to the IBM WebSphere AdminClient interface to deal with some specific things on the local server. The IBM WebSphere AdminClient also makes use of SOAP/ssl to contact the desired server which is simply the local host in this case. Now I encounter a silly phenomenon: When the first SOAP/ssl connection during VM life time is initiated by the AdminClient (which is not configurable regarding the SSL connection setup) and Axis2 comes behind, everything works fine. But when the first SOAP/ssl connection during VM life time is initiated by Axis2 (which simply uses its default scheme of operation to establish a https connection to a remote host), then AdminClient fails to connect permanently, but Axis2 keeps being fine all the time. I raised a PMR at IBM on this issue, but it languishes, and currently they suspect that the application's client code is to be blamed. I have no problem with that generally, but I cannot see any way to influence the actual ssl configuration or setup for Axis2 1.4.1 SOAP client operation so as to consort better with the AdminClient. Does anyone know how to configure Axis2 1.4.1 to explicitly select the cipher, algorithm, keystore or the like for ssl? What about that magic axis2.xml config file? I did not figure out yet what to put in there at all, where to put the file and how to locate it then to make it work for a *client*... its all nebulous to me... Thanks in advance, -- Dipl.-Inform. Christian Gosch, PMI PMP Systems Architecture, Project Management inovex GmbH Büro Pforzheim Karlsruher Strasse 71 D-75179 Pforzheim Tel: +49 (0)7231 3191-85 Fax: +49 (0)7231 3191-91 c.go...@inovex.de www.inovex.de Sitz der Gesellschaft: Pforzheim AG Mannheim, HRB 502126 Geschäftsführer: Stephan Müller !DSPAM:4b17a9e8326661182215571!
RE: SOAP/ssl: Axis2 1.4.1 (client to remote) vs. IBM WebSphere 6.0.2 AdminClient (to local)
The source of solution was: http://osdir.com/ml/axis-user-ws.apache.org/2009-06/msg00307.html The solution is to set up the following properties for the JVM: javax.net.ssl.keyStore=fully qualified path to keystore file javax.net.ssl.keyStoreType=type of keystore, i.e, JKS javax.net.ssl.keyStorePassword=keystore password javax.net.ssl.trustStore=fully qualified path to truststore file javax.net.ssl.trustStoreType=type of truststore, i.e, JKS javax.net.ssl.trustStorePassword=truststore password javax.net.ssl.contextProvider=provider, i.e. JSSE This is basically the same as depicted by Thilina Mahesh Buddhika: It can be achieved either ny using the -Dpropname=propvalue pattern on the command line, by setting appropriate JVM startup properties using the administration interface of your choice or by explicitly setting that in the Java code. Using system properties for the JVM may be more useful since this way it is guaranteed that the values are present from the time the JVM starts. This is difficult to achieve with explicit Java in a J2EE environment. Regards, Christian -Original Message- From: Christian Gosch Sent: Thursday, December 03, 2009 2:56 PM To: axis-user Subject: SOAP/ssl: Axis2 1.4.1 (client to remote) vs. IBM WebSphere 6.0.2 AdminClient (to local) Hi, in a J2EE web application running on IBM WebSphere 6.0.2 we use Axis2 1.4.1 as WS client to execute SOAP calls to a remote host via SSL *and* the IBM WebSphere AdminClient (from inside the app) to execute tasks on the local host. When AdminClient is used first *before* first use of Axis2 client (ssl), everything is fine and both clients work also on subsequent operations. BUT: When Axis2 client (ssl) is used first *before* first use of AdminClient, then AdminClient fails to connect permanently, but Axis2 runs fine. Has anybody experienced similar things? This may include using CXF or other WS client libraries *for ssl connections* together with IBM WebSphere AdminClient. Thanks for any help on this topic. (Yes, there is another instance of this topic, but this one is shorter :-) Regards, -- Dipl.-Inform. Christian Gosch, PMI PMP Systems Architecture, Project Management inovex GmbH Büro Pforzheim Karlsruher Strasse 71 D-75179 Pforzheim Tel: +49 (0)7231 3191-85 Fax: +49 (0)7231 3191-91 c.go...@inovex.de www.inovex.de Sitz der Gesellschaft: Pforzheim AG Mannheim, HRB 502126 Geschäftsführer: Stephan Müller !DSPAM:4b17c3bb326661492514722!
RE: How to configure SSL key store / trust store location to use for AXIS2 1.4.1 as SOAP/ssl client?
The source of solution was: http://osdir.com/ml/axis-user-ws.apache.org/2009-06/msg00307.html The solution is to set up the following properties for the JVM: javax.net.ssl.keyStore=fully qualified path to keystore file javax.net.ssl.keyStoreType=type of keystore, i.e, JKS javax.net.ssl.keyStorePassword=keystore password javax.net.ssl.trustStore=fully qualified path to truststore file javax.net.ssl.trustStoreType=type of truststore, i.e, JKS javax.net.ssl.trustStorePassword=truststore password javax.net.ssl.contextProvider=provider, i.e. JSSE This is basically the same as depicted by Thilina Mahesh Buddhika: It can be achieved either ny using the -Dpropname=propvalue pattern on the command line, by setting appropriate JVM startup properties using the administration interface of your choice or by explicitly setting that in the Java code. Using system properties for the JVM may be more useful since this way it is guaranteed that the values are present from the time the JVM starts. This is difficult to achieve with explicit Java in a J2EE environment. Regards, Christian -Original Message- From: Christian Gosch Sent: Wednesday, December 09, 2009 7:46 PM To: axis-user Subject: How to configure SSL key store / trust store location to use for AXIS2 1.4.1 as SOAP/ssl client? Hi, how can I configure which SSL key store trust store is used when AXIS2 1.4.1 is the first running code requesting a SSL connection as a SOAP client in a given 1.4 JVM? Problem: IBM WebSphere 6.0 (JDK/JRE 1.4.2) uses a defaultSSLSocketFactory which is a singleton and once it's initialized with some particular value, it'll be reused. (info from IBM L3) If nothing special is said about what to do how, AXIS2 1.4.1 simply requests .../java/jre/lib/security/cacerts as key store trust store file. This is fatal if later (other) SOAP clients require key pairs not present in this JVM default store. Is there some way to tell AXIS2 1.4.1 to request another file for key store / trust store? Are there some JVM properties which can be used? Is there any possibility to achieve that via the magic Options object? Can this be achieved using the magic axis2.xml configuration file? (Again: Where is this file, or where is it looked for, and what is allowed to be inside?) Desperate, -- Dipl.-Inform. Christian Gosch, PMI PMP Systems Architecture, Project Management inovex GmbH Büro Pforzheim Karlsruher Strasse 71 D-75179 Pforzheim Tel: +49 (0)7231 3191-85 Fax: +49 (0)7231 3191-91 c.go...@inovex.de www.inovex.de Sitz der Gesellschaft: Pforzheim AG Mannheim, HRB 502126 Geschäftsführer: Stephan Müller !DSPAM:4b1ff09b326661456082889!
How to configure SSL key store / trust store location to use for AXIS2 1.4.1 as SOAP/ssl client?
Hi, how can I configure which SSL key store trust store is used when AXIS2 1.4.1 is the first running code requesting a SSL connection as a SOAP client in a given 1.4 JVM? Problem: IBM WebSphere 6.0 (JDK/JRE 1.4.2) uses a defaultSSLSocketFactory which is a singleton and once it's initialized with some particular value, it'll be reused. (info from IBM L3) If nothing special is said about what to do how, AXIS2 1.4.1 simply requests .../java/jre/lib/security/cacerts as key store trust store file. This is fatal if later (other) SOAP clients require key pairs not present in this JVM default store. Is there some way to tell AXIS2 1.4.1 to request another file for key store / trust store? Are there some JVM properties which can be used? Is there any possibility to achieve that via the magic Options object? Can this be achieved using the magic axis2.xml configuration file? (Again: Where is this file, or where is it looked for, and what is allowed to be inside?) Desperate, -- Dipl.-Inform. Christian Gosch, PMI PMP Systems Architecture, Project Management inovex GmbH Büro Pforzheim Karlsruher Strasse 71 D-75179 Pforzheim Tel: +49 (0)7231 3191-85 Fax: +49 (0)7231 3191-91 c.go...@inovex.de www.inovex.de Sitz der Gesellschaft: Pforzheim AG Mannheim, HRB 502126 Geschäftsführer: Stephan Müller
Configure SSL config for Axis2 1.4.1 client to connect to SOAP/ssl WS
Hi, I have an Axis2 1.4.1 SOAP client (code generated with wsdl2java using XMLBeans) and can use this client successfully to execute operations on a remote server which only accepts SOAP/ssl (https) requests. I do not configure something special: I simply take the https:... URL as it is, and use it, and Axis2 together with the accompanying libraries does the remaining. But the client code is part of a J2EE application deployed on IBM WebSphere 6.0.2, and this application also has to make calls to the IBM WebSphere AdminClient interface to deal with some specific things on the local server. The IBM WebSphere AdminClient also makes use of SOAP/ssl to contact the desired server which is simply the local host in this case. Now I encounter a silly phenomenon: When the first SOAP/ssl connection during VM life time is initiated by the AdminClient (which is not configurable regarding the SSL connection setup) and Axis2 comes behind, everything works fine. But when the first SOAP/ssl connection during VM life time is initiated by Axis2 (which simply uses its default scheme of operation to establish a https connection to a remote host), then AdminClient fails to connect permanently, but Axis2 keeps being fine all the time. I raised a PMR at IBM on this issue, but it languishes, and currently they suspect that the application's client code is to be blamed. I have no problem with that generally, but I cannot see any way to influence the actual ssl configuration or setup for Axis2 1.4.1 SOAP client operation so as to consort better with the AdminClient. Does anyone know how to configure Axis2 1.4.1 to explicitly select the cipher, algorithm, keystore or the like for ssl? What about that magic axis2.xml config file? I did not figure out yet what to put in there at all, where to put the file and how to locate it then to make it work for a *client*... its all nebulous to me... Thanks in advance, -- Dipl.-Inform. Christian Gosch, PMI PMP Systems Architecture, Project Management inovex GmbH Büro Pforzheim Karlsruher Strasse 71 D-75179 Pforzheim Tel: +49 (0)7231 3191-85 Fax: +49 (0)7231 3191-91 c.go...@inovex.de www.inovex.de Sitz der Gesellschaft: Pforzheim AG Mannheim, HRB 502126 Geschäftsführer: Stephan Müller
SOAP/ssl: Axis2 1.4.1 (client to remote) vs. IBM WebSphere 6.0.2 AdminClient (to local)
Hi, in a J2EE web application running on IBM WebSphere 6.0.2 we use Axis2 1.4.1 as WS client to execute SOAP calls to a remote host via SSL *and* the IBM WebSphere AdminClient (from inside the app) to execute tasks on the local host. When AdminClient is used first *before* first use of Axis2 client (ssl), everything is fine and both clients work also on subsequent operations. BUT: When Axis2 client (ssl) is used first *before* first use of AdminClient, then AdminClient fails to connect permanently, but Axis2 runs fine. Has anybody experienced similar things? This may include using CXF or other WS client libraries *for ssl connections* together with IBM WebSphere AdminClient. Thanks for any help on this topic. (Yes, there is another instance of this topic, but this one is shorter :-) Regards, -- Dipl.-Inform. Christian Gosch, PMI PMP Systems Architecture, Project Management inovex GmbH Büro Pforzheim Karlsruher Strasse 71 D-75179 Pforzheim Tel: +49 (0)7231 3191-85 Fax: +49 (0)7231 3191-91 c.go...@inovex.de www.inovex.de Sitz der Gesellschaft: Pforzheim AG Mannheim, HRB 502126 Geschäftsführer: Stephan Müller
RE: HTTPS WebService through HTTP Proxy
I’m not quite sure, but shouldn’t it be sufficient to talk to the proxy as required, and let the proxy do whatever it is supposed to? In other words: I think from an Axis client’s view only the instance this client directly talks to should matter. What happens there (immediate processing or forwarding forth and back of the SOAP messages by means of a proxy or gateway) should not matter at all for the Axis client. This applies to all aspects of the communication, i. e. ports, resource URLs, encryption, authentication, authorization… Christian _ From: Pedro Quintas [mailto:pedro.quin...@first.pt] Sent: Thursday, October 15, 2009 2:00 AM To: axis-user@ws.apache.org Subject: HTTPS WebService through HTTP Proxy Importance: High Hello. I need to call a HTTPS WebService through a HTTP proxy. I set on Options object the following: options.setProperty(HTTPConstants.CUSTOM_PROTOCOL_HANDLER, new Protocol(“https”, (ProtocolSocketFactory)new AuthSSLProtocolSocketFactory(endpoint), 443)); options.setTransportInProtocol(Constants.TRANSPORT_HTTPS); options.setProperty(HTTPConstants.AUTHENTICATE, authenticator); options.setProperty(HTTPConstants.PROXY, proxyProperty); // proxyProperty have set ProxyName, ProxyPort, UserName, PassWord And another options. I put the TCPMon, between my program and the proxy to see what is send. On TCPMon I see the connection made to the proxy and then to the HTTPS WebService, all in plaintext and this is wrong because after the connection to the proxy, all data transmited should been encrypted. Any one already have this problem? How can I solve this? Sorry for my bad English. Thanks, Kintas !DSPAM:4ad66624326667108612316!
RE: Possible to get more information from an AxisFault?
That would be a nice thing to have indeed!!
When Axis2 WS client code decides to classify an error situation as an
AxisFault, the client application seems to have no chance to find out
what has happened behind the scenes. It's just like saying failed. and
nothing more. This can be very odd when the used Axis2 configuration is
just idiosyncratic about what happens on the wire, and you simply do
not know about that.
But it is possible to force the HTTP base implementation usually used by
Axis2 (which is commons-httpclient) to log the HTTP traffic, regardless
of using https on the actual connection: commons-httpclient internally
uses commons-logging, and there you can enable the category / filter
org.apache.commons.httpclient.wire to get the http traffic logged.
Usually this helps a lot in dev/test environments, but is not accessible
by the application for self examination.
Christian
-Original Message-
From: laredotornado [mailto:laredotorn...@gmail.com]
Sent: Tuesday, October 13, 2009 4:04 PM
To: axis-user@ws.apache.org
Subject: Possible to get more information from an AxisFault?
Hi,
We''ve written a web service and a client that connects to it, both in
Java
(client generated using the code below) ...
project xmlns:j=jelly:core xmlns:ant=jelly:ant
preGoal name=java:compile
ant:property name=downloadedWSDL
value=target/MatchingService.wsdl
/
ant:get
src=http://localhost:8080//apps/dor/dmv/myapp/myfn//services/MatchingSe
rv
ice?wsdl
dest=${downloadedWSDL}
username=username
password=password /
ant:mkdir dir=${maven.build.dir}/src /
java classname=org.apache.axis2.wsdl.WSDL2Java fork=true
classpathref=maven.dependency.classpath
arg line=-uri ${downloadedWSDL} /
arg line=-or /
arg line=-d adb /
arg line=-o target/ /
/java
ant:javac
debug=true
debuglevel=vars,lines,source
destdir=${maven.build.dest}
excludes=**/package.html
srcdir=${basedir}/target/src
ant:classpath
ant:path refid=maven.dependency.classpath /
/ant:classpath
/ant:javac
/preGoal
/project
I wanted to know how to get axis faults to send back more information
than
simply what we are seeing below. Regardless of the exception
generated by
the web service, the exception thrown in the client is the same. Is
there
a
way to add a message into the client so at least we know greater
detail
about what caused the error?
org.apache.axis2.AxisFault: Exception occurred while trying to invoke
service method verifyAge
at
org.apache.axis2.util.Utils.getInboundFaultFromMessageContext(Utils.java
:4
86)
at
org.apache.axis2.description.OutInAxisOperationClient.handleResponse(Out
In
AxisOperation.java:343)
at
org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOper
at
ion.java:389)
at
org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInA
xi
sOperation.java:211)
at
org.apache.axis2.client.OperationClient.execute(OperationClient.java:163
)
at
myco.dor.dmv.driver.matching.soap.MatchingServiceStub.verifyAge(Matching
Se
rviceStub.java:522)
at
myco.dor.dmv.driver.matching.test.AgeVerifyTests.testVerifyAgeWithNullId
en
tityParams(AgeVerifyTests.java:62)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:
39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Im
pl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:164)
at junit.framework.TestCase.runBare(TestCase.java:130)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at
junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:120)
at junit.framework.TestSuite.runTest(TestSuite.java:230)
at junit.framework.TestSuite.run(TestSuite.java:225)
at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTe
st
Runner.java:297)
at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeInVM(JUnit
Ta
sk.java:1072)
at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask
.j
ava:682)
at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeOrQueue(JU
ni
tTask.java:1434)
at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask
.j
ava:632)
at org.apache.tools.ant.Task.perform(Task.java:364)
at
org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:195)
at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)
at
RE: Cannot load SchemaTypeSystem
Ouuh sorry I missed that single .class file... but anyway, if all of the xsb stuff is on the runtime class path (i. e. the directories containing it all) this is OK. I preferred to pack this all together as a JAR and add it to the JAR zoo of the application. But that problem solved, now the constructors. The generated XyzStub class is the user-friendly frontend of all generated stuff. For standard scenarios this will do, and it has some additional constructors allowing you to add additional configuration besides the endpoint. I think this is merely a guess what may be needed in usual scenarios -- but in the simplest cases, you should be done simply using the constructor taking the endpoint only. In my case I needed additional configuration, and that forced me to use a neighbour class of XyzStub -- Xyz. This class provides some additional functionality to set up Options. I needed this to prevent the generated code to use chunked transfer, which usually is allowed to use, but was not in ma case. Not that helpful maybe, but the existing constructors should work if provided with useful non-null arguments. (but whats useful at the end...) hth, --cg -Original Message- From: sch...@afrigis.co.za [mailto:sch...@afrigis.co.za] Sent: Friday, October 09, 2009 7:31 AM To: axis-user@ws.apache.org; fryar...@gmail.com Subject: RE: Cannot load SchemaTypeSystem Awesome Michael, That did the job, in my case I had to copy it to the build directory as it is a web app but it worked perfectly. Now though I encountered a lovely surprise, a NullPointerException thrown by one of the generated stubs, specifically this line: _messageContext.getTransportOut().getSender().cleanup(_messageContext); I will add some log statements in here but I am guessing it is _messageContext. I now the stub had various constructors and for some of these if you only provide the end point it sets the other, which I believe is this _messageContext to null, not sure why those constructors exist then if you should not really be using them, or am I missing something? -- Kind Regards Schalk Neethling -Original Message- From: FRYARS, Michael [mailto:fryar...@gmail.com] Sent: 08 October 2009 10:06 PM To: axis-user@ws.apache.org Subject: Re: Cannot load SchemaTypeSystem In among all those .xsb files you'll find a single .class file, and this .class must be available at runtime. [Note: XMLBeans generates the .class directly, it doesn't generate a .java and then have it compiled] I saw the problem you describe when running JUnit tests which used an axis2-generated SOAP client. The AAR deployed in the axis2 WAR was fine. But the (eclipse) project that held the tests didn't have this XMLBeans .class file in the 'bin' directory. It was present in the 'resource' directory, which was the target directory for XMLBeans generated source, but it wasn't copied to the bin directory and so wasn't available to the test client at runtime. Simply copying it across to the bin directory solved the problem. Regards, Michael sch...@afrigis.co.za a écrit : Hi there Christian, I did find the resource folder with stacks of .xsb files on. I added this to the sources in the build path in Eclipse as well as to the Output... tab. However, I still get the problem, any ideas as to where else I need to set something? Maybe something to do with Tomcat? Thanks for your help. -- Kind Regards Schalk Neethling -Original Message- From: Christian Gosch [mailto:christian.go...@inovex.de] Sent: 08 October 2009 02:13 PM To: axis-user Subject: RE: Cannot load SchemaTypeSystem XMLbeans does not only generate classes, but lots of additional binaries, which must be presesnt on the classpath. Look through your output folder, and you will find an additional folder with this stuff. Add it to your runtime classpath, and you may be done :-) --cg -Original Message- From: sch...@afrigis.co.za [mailto:sch...@afrigis.co.za] Sent: Thursday, October 08, 2009 12:29 PM To: axis-user@ws.apache.org Subject: Cannot load SchemaTypeSystem Hi there, I finally got Axis2 to generate the appropriate stubs etc for me, finally having to use the command line tool, and I chose XMLBeans as my data binding solution as I have worked with it before and found it real easy to use. After having to hunt around for some jar files I can finally run a servlet to test out the generated code. I start of the servlet with the following: GetPointsByRadiusDocumentImpl pointsByRadius = new GetPointsByRadiusDocumentImpl(GetPointsByRadiusDocument.type); However, when running the servlet I get the exception mentioned above i.e. java.lang.RuntimeException: Cannot load SchemaTypeSystem. Unable to load class with name
RE: Cannot load SchemaTypeSystem
XMLbeans does not only generate classes, but lots of additional binaries, which must be presesnt on the classpath. Look through your output folder, and you will find an additional folder with this stuff. Add it to your runtime classpath, and you may be done :-) --cg -Original Message- From: sch...@afrigis.co.za [mailto:sch...@afrigis.co.za] Sent: Thursday, October 08, 2009 12:29 PM To: axis-user@ws.apache.org Subject: Cannot load SchemaTypeSystem Hi there, I finally got Axis2 to generate the appropriate stubs etc for me, finally having to use the command line tool, and I chose XMLBeans as my data binding solution as I have worked with it before and found it real easy to use. After having to hunt around for some jar files I can finally run a servlet to test out the generated code. I start of the servlet with the following: GetPointsByRadiusDocumentImpl pointsByRadius = new GetPointsByRadiusDocumentImpl(GetPointsByRadiusDocument.type); However, when running the servlet I get the exception mentioned above i.e. java.lang.RuntimeException: Cannot load SchemaTypeSystem. Unable to load class with name schemaorg_apache_xmlbeans.system.sEFB7B44E94FC7E3BBFB970E23CA0512F.TypeS ys te mHolder. Make sure the generated binary files are on the classpath. Any help will be much appreciated. Thanks! Schalk AfriGIS e-mail facility may not be used for the distribution of chain letters or offensive email. AfriGIS hereby distances itself from and accepts no liability for the unauthorized use of its e-mail facility or the sending of e-mail communications for other than strictly business purposes. AfriGIS furthermore disclaims liability for any unauthorized instruction for which permission was not granted. Required as per Sec 50 Companies Act 61 of 1973 Afrigis Pty LTD Reg No 1997/0067/1607. !DSPAM:4acdbf1b326661199011006!
How can I force namespace declarations in the envelope? (Axis2 1.4.1 / XMLbeans 2.3 / Java 1.4.2)
Hi, by default, Axis2 seems to put namespace declarations like 'xmlns:ns=http://my.namespace.com/this/one/is/it;' at the latest / deepest point in the XML possible, which seems to be perfectly in line with W3C requirements. My SOAP client has to talk to the Web Service via a XML security gateway (probably Cisco ACE XML gateway) which is configured to require all namespaces of the request to be declared in the SOAP envelope. How can I achieve that using Axis2 1.4.1? Environment: - IBM WebSphere Application Server 6.0.2 / IBM Java 1.4.2 JRE (stuck to) - Axis2 1.4.1 / XMLbeans 2.3.0 (only for client operation) Examples: That is what Axis2 currently produces, using simply the generated Java stub class: ?xml version='1.0' encoding='UTF-8'? soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; soapenv:Header Request xmlns=http://premconn.premiereconnect.com/2007/02; soapenv:mustUnderstand=0 ReceiverKeyhttp://my.receiver.key//ReceiverKey RequestIDf0aFQR5s_AIBYHgdN16pqlf/RequestID Authentication XDDSAuth RequesterID###/RequesterID Password***/Password /XDDSAuth /Authentication /Request /soapenv:Header soapenv:Body ns:ListCreateRequest xmlns:ns=http://premconn.premiereconnect.com/2007/02; ns:SubmitIdf0aFQR5s_AIBYHgdN16pqlf/ns:SubmitId etc. etc. etc. And *that* is what ACE XML gateway seems to expect: ?xml version='1.0' encoding='UTF-8'? soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; xmlns:ns=http://premconn.premiereconnect.com/2007/02; soapenv:Header ns:Request soapenv:mustUnderstand=0 ns:ReceiverKeyhttp://my.receiver.key//ns:ReceiverKey ns:RequestIDf0aFQR5s_AIBYHgdN16pqlf/ns:RequestID ns:Authentication ns:XDDSAuth ns:RequesterID###/ns:RequesterID ns:Password***/ns:Password /ns:XDDSAuth /ns:Authentication /ns:Request /soapenv:Header soapenv:Body ns:ListCreateRequest ns:SubmitIdf0aFQR5s_AIBYHgdN16pqlf/ns:SubmitId etc. etc. etc. How can I force Axis2 to produce output that conforms to these requirements? Maybe this is related to Jira #AXIS2-4215 , URL: https://issues.apache.org/jira/browse/AXIS2-4215 Thanks in advance for useful hints and help, -- Dipl.-Inform. Christian Gosch, PMI PMP Systems Architecture, Project Management inovex GmbH Büro Pforzheim Karlsruher Strasse 71 D-75179 Pforzheim Tel: +49 (0)7231 3191-85 Fax: +49 (0)7231 3191-91 c.go...@inovex.de www.inovex.de Sitz der Gesellschaft: Pforzheim AG Mannheim, HRB 502126 Geschäftsführer: Stephan Müller
RE: How can I force namespace declarations in the envelope? (Axis2 1.4.1 / XMLbeans 2.3 / Java 1.4.2)
Finally I found a solution by deep and rigorous web search... http://stackoverflow.com/questions/74960/how-do-i-add-a-namespace-reference-to-a-soap-response-with-apache-axis2-and-wsdl2 explains how to do it. BUT: The result is not that nice. To be honest: I forgot to mention that I generated the client code with WSDL2Java and wanted to use the generated stu(b|ff) just as it fell on my HD. The solution presented on the page urled above basically supports this approach by adding minimal extensions to the generated code. BUT: (1) You have to add the extension to every method request implementation in the generated code. At least every method implementation your client code will use :-) (2) The approach is to add a namespace declaration as early as possible to the envelope generated. Thats quite fine, but its not early enough: The SOAP message body is already constructed and already contains its own namespace declaration(s) as required, when the envelope is generated. Thus the namespace in question (or: all namespaces in question) tend(s) to be declared twice: In the envelope and at (their) first occurrence in the body. (3) The SOAP header is generated *after* adding the namespace declaration in this approach, but its visibility scope downwards into the element hierarchy is only 1 step, that is: Elements directly beneath the Header element make use of the namespace declared, but elements deeper inside will receive their own default namespace declaration -- using the same URL of course. Finally I do not yet have a confirmation that this format of SOAP call really will pass the XML security gateway. But calling the Web Service directly works fine :-) I will update this thread if there are relevant news :-) Christian -Original Message- From: Christian Gosch Sent: Tuesday, September 22, 2009 3:30 PM To: axis-user Subject: How can I force namespace declarations in the envelope? (Axis2 1.4.1 / XMLbeans 2.3 / Java 1.4.2) Hi, by default, Axis2 seems to put namespace declarations like 'xmlns:ns=http://my.namespace.com/this/one/is/it;' at the latest / deepest point in the XML possible, which seems to be perfectly in line with W3C requirements. My SOAP client has to talk to the Web Service via a XML security gateway (probably Cisco ACE XML gateway) which is configured to require all namespaces of the request to be declared in the SOAP envelope. How can I achieve that using Axis2 1.4.1? Environment: - IBM WebSphere Application Server 6.0.2 / IBM Java 1.4.2 JRE (stuck to) - Axis2 1.4.1 / XMLbeans 2.3.0 (only for client operation) Examples: That is what Axis2 currently produces, using simply the generated Java stub class: ?xml version='1.0' encoding='UTF-8'? soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; soapenv:Header Request xmlns=http://premconn.premiereconnect.com/2007/02; soapenv:mustUnderstand=0 ReceiverKeyhttp://my.receiver.key//ReceiverKey RequestIDf0aFQR5s_AIBYHgdN16pqlf/RequestID Authentication XDDSAuth RequesterID###/RequesterID Password***/Password /XDDSAuth /Authentication /Request /soapenv:Header soapenv:Body ns:ListCreateRequest xmlns:ns=http://premconn.premiereconnect.com/2007/02; ns:SubmitIdf0aFQR5s_AIBYHgdN16pqlf/ns:SubmitId etc. etc. etc. And *that* is what ACE XML gateway seems to expect: ?xml version='1.0' encoding='UTF-8'? soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; xmlns:ns=http://premconn.premiereconnect.com/2007/02; soapenv:Header ns:Request soapenv:mustUnderstand=0 ns:ReceiverKeyhttp://my.receiver.key//ns:ReceiverKey ns:RequestIDf0aFQR5s_AIBYHgdN16pqlf/ns:RequestID ns:Authentication ns:XDDSAuth ns:RequesterID###/ns:RequesterID ns:Password***/ns:Password /ns:XDDSAuth /ns:Authentication /ns:Request /soapenv:Header soapenv:Body ns:ListCreateRequest ns:SubmitIdf0aFQR5s_AIBYHgdN16pqlf/ns:SubmitId etc. etc. etc. How can I force Axis2 to produce output that conforms to these requirements? Maybe this is related to Jira #AXIS2-4215 , URL: https://issues.apache.org/jira/browse/AXIS2-4215 Thanks in advance for useful hints and help, -- Dipl.-Inform. Christian Gosch, PMI PMP Systems Architecture, Project Management inovex GmbH Büro Pforzheim Karlsruher Strasse 71 D-75179 Pforzheim Tel: +49 (0)7231 3191-85 Fax: +49 (0)7231 3191-91 c.go...@inovex.de www.inovex.de Sitz der Gesellschaft: Pforzheim AG Mannheim, HRB 502126 Geschäftsführer: Stephan Müller !DSPAM:4ab8d33e326661724765873!
