Ray Thomas

Greenhorn
+ Follow
since Feb 24, 2005
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Ray Thomas

I feel like Harry Potter uttering the name Voldemort. I didn't mean to ruffle anyone's feathers with the comment about Axis/Java vs. .NET. I'm perfectly aware that Axis is open source, free, community developed, no guarantees, etc. but my general experience with open source libraries, especially ones that have been around a while, and even more especially ones that are published under the Apache Software Foundation umbrella, is that they tend to support somewhat well known technologies (like WSDL) _better_ than the commercial alternatives. So, naturally, when that isn't the case, I'm "a little disappointed." It doesn't matter in the end because I got it to work anyway but I much prefer not having to wrestle with something to get it working. Thankfully there's a place like JavaRanch around where we can all get a helping hand (or lend one) when something puts up a fight.

-R
16 years ago
Well I'm a little disappointed that that a .NET framework based tool (SOAPSonar) did _not_ require me to "cook" the WSDL in order for it to figure out how to handle it, but Axis did require the WSDL tweak. Hopefully Axis 2.x will have some of this stuff sorted out. An additional bit of irony is that the WSDL is apparently generated on the server end by Axis (not sure which version).

Anyway, since I have very little control over how the WSDL is produced in the commercial server product, I decided to automate the process of getting the WSDL, "cooking" it, and running WSDL2Java. The ant build file and XSL are attached below in case anyone else needs to do the same sort of thing.

Thanks everyone for the help and suggestions.

----------- build.xml ------------------
?xml version="1.0" encoding="UTF-8"?>

<project name="web_services_tutorial" default="axis">

<property name="axis.home" value="/javalibs/axis-1_3" />
<property name="generated.dir" value="javasource_generated" />
<!-- property name="jwsdp.home" value="/jwsdp-1.4" / -->

<path id="axis.classpath">
<fileset dir="${axis.home}/lib" includes="**/*.jar" />
<!-- fileset dir="${jwsdp.home}" includes="jwsdp-shared/lib/activation.jar" / -->
<!-- fileset dir="${jwsdp.home}" includes="jwsdp-shared/lib/mail.jar" / -->
</path>

<taskdef resource="axis-tasks.properties">
<classpath refid="axis.classpath" />
</taskdef>

<target name="axis">
<mkdir dir="temp_wsdl_orig" />
<mkdir dir="temp_wsdl_mod" />
<get src="http://MIDTIER/arsys/WSDL/public/ARSERVER/SimpleTicketView"
dest="temp_wsdl_orig/SimpleTicketView.xml" />
<xslt in="temp_wsdl_orig/SimpleTicketView.xml"
out="temp_wsdl_mod/SimpleTicketView.xml"
style="SimpleTicketView.xsl" />
<axis-wsdl2java
url="temp_wsdl_mod/SimpleTicketView.xml"
output="${generated.dir}"
testcase="true"
verbose="true"
nowrapped="true"
all="true">
<mapping
namespace="http://axis.apache.org/ns/interop"
package="interop" />
<mapping
namespace="urn:SimpleTicketView"
package="com.example.webservice.ars" />
</axis-wsdl2java>
</target>

</project>
------------------- build.xml -----------------


--------------- SimpleTicketView.xsl -----------
<?xml version="1.0" encoding="ISO-8859-1"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:template match="node()|@*">
<xsl:if test="not(name()='soap:header')">
<xsl:copy>
<xsl:copy-of select="@*" />
<xsl:apply-templates />
</xsl:copy>
</xsl:if>
</xsl:template>

</xsl:stylesheet>
--------------- SimpleTicketView.xsl -----------
16 years ago
Well, the verdict on that is that, yes, technically the form of the soap:header tag in the WSDL does not matter. I saved the WSDL to a file, altered the soap:header tag to the shorthand form, and ran WSDL2Java on the altered file but the generated classes have the same behavior as before.

I tried removing the soap:header tag completely and regenerated using WSDL2Java and that worked. I still have to add the actual header to the request in the client code that uses the Axis generated classes but at least it works.

Now I'm curious if this is a bug in Axis. Seems like it is not generating the appropriate code to handle the soap:body properly if there is a soap:header present in the WSDL. I searched the bugs for Axis on issues.apache.org but didn't find anything that matched this. Looks like all the effort has shifted to the yet unreleased Axis 2.

The problem that remains is that I don't have control over the published WSDL for the service. Working around this means I need to set up my build (ant task) to retrieve the WSDL to a file, run a transform on it to zap the soap:header tag, and then run WSDL2Java.

Still hoping someone has a better suggestion.

-R
16 years ago
I am trying to use Axis 1.3 (also tried 1.2) to consume a web service published by Remedy ARSystem. I know the service / WSDL is configured properly and works with at least one test client tool (SOAPSonar) so I somewhat sure the Axis client library is the component that is misbehaving.

The problem is that WSDL2Java produces code that puts the request parameter values in the header section of the soap envelope and not in the body where the server expects them. I haven't been able to find a way to make the Axis generated objects put the request parameters in the service element of the soapenv:body section where they need to be.

Can anyone help me figure out how to make Axis 1.3 work.

Attached below are:
1) A sample of an improperly structured request from Axis
2) A sample of a properly structured request from SOAPSonar
(both captured with Ethereal)
3) The WSDL produced by the Remedy ARSystem web service follow below.

16 years ago
Even though this question was posted quite a while back, I just saw it while searching for something else so here's an answer:

Supposing that the class generated for the header info is MyHeaderType and the generated stub class (MyWebServiceStub) instance is assigned to a variable named binding, then:

MyHeaderType header = new MyHeaderType("param1", "param2", "paramEtc");
binding.addHeader("", "urn:MyWebServiceNamespace", header);

Just couldn't stand to see a question without an answer. Hope my answer works for somebody besides me.
16 years ago
I looked around quite a bit for a resolution to this issue with IHS and WAS but never found anything. Since I'm betting someone else eventually has the same issue, I thought I'd post it here so it won't get lost forever in a dusty corner of my brain.


The issue:

IBM Http Server 6.0 (a.k.a. IHS or Apache 2 with various IBM WebSphere plugin modules) running as a service on Windows 2000 Advanced Server fails to start Automatically when the machine boots up. The System Event Log then contains a "Service Control Manager" event with an ambiguous message stating that "The IBM HTTP Server 6.0 service terminated with service-specific error 1." There are no messages in any of the web server log files no matter what the LogLevel, and no additional information in the system event object. To make things more mysterious, IHS then starts without problems after the machine has finished initializing.

The cause: (not confirmed but strongly suspected)

The WAS plugin module fails to initialize because it attempts to communicate with the WebSphere 6 service prematurely (i.e. while WAS is still initializing too). The "suspected" part is that the IHS service terminates because the WAS plugin is not programmed to handle some sort of exception gracefully and the whole IHS process just crashes as a result.


The resolution: (at least this worked for me)

Add a dependency in the service configuration for the IHS service so that it waits to start until the WebSphere service has finished starting up.

a. Start regedt32 and navigate to "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services" key
b. Copy the full service name for the "IBMWAS6Service - ???" service to the clipboard (The ??? part will be node name suffix based on the machine name)
c. Open the "IBMHTTPServer6.0" service key, edit the DependOnService REG_MULTI_SZ value, add a line (there should already be 2 dependencies, Tcpip and Afd, in the list), and paste in the WAS service name from the clipboard on the new line.

(Note: regedit.exe won�t work because it doesn't have a proper editor for REG_MULTI_SZ values. regedt32.exe allows these values to be edited more easily. I guess that's one of the reasons why regedt32 still around.)

Hope this ends up helping someone. It was sure a headache getting it narrowed down. BTW, I think this problem usually affects WebSphere running on a multiple processor machine since there's probably a natural serialization effect on single processor machines that might avoid the whole parallel, concurrent startup issue.
17 years ago
If it helps, Tomcat 5 implements the side trip to the login page as a forward and the info you seem to be after shows up in the Servlet 2.4 "forward" request attributes ("javax.servlet.forward.request_uri", "javax.servlet.forward.context_path", "javax.servlet.forward.servlet_path", and "javax.servlet.forward.query_string"). WebSphere 6 might be up to date enough to support this but older WebSphere versions (including 5.1) are only up to Servlet 2.3 and probably don't support Servlet 2.4 features. Also, I don't know for sure, but I suspect it is app-server specific how the container retains the original "target" request until the user finally submits the j_security_check form.

I'd like to be able to override the "target page" info in certain circumstances so if someone knows how to get at this info in a standard way (or even an app-server specific way), please post. The particular case where this would come in handy is when an application has a subset of functions that require complicated session state context (e.g. midway through some sort of wizard sequence). If the user sits on that kind of page for a while and lets the session time out, and then clicks the "next" link, I'd like to be able to intercept the target page and land them somewhere else after they authenticate. It's a bit ugly to spread that kind of logic in odd places throughout an app.
17 years ago