I have a customer who posts an HTTP stream to my service. But he doesn’t set up a content-type value for the HTTP post. IS doesn’t seem to like it - it put a variable with no name (NULL) in the pipeline and the variable is not visible (anything else would end up with a node, ffdata or contentStream, etc).
I would like to have something like request.getinputstream in JSP/Servlet.
I was reading an ezine where the author mentioned we could use Service.getRequest((Values)pipeline); to get the bytes out. But Developer doesn’t like the class cast from IData to Values.
P.S. A possible workaround is to write a servlet on top of WmTomcat.
If I unregister the default handler, the system won’t be able to parse query string name/value pairs - I don’t want to mess up the system. My customer is not willing to change the content-type (actually the customer is using a packaged software and has no clue what is a content-type). So I still need to get the request object.
My current plan is to deploy a simple servlet on top of WmTomcat.
The input data is just an XML string. The problem is that the string doesn’t have a variable name even the content-type was set as application/x-www-form-urlencoded. (I don’t think the customer set it intentionally because x-www-form-urlencoded is the default content type. I think the customer just didn’t do anything about the type or variable name).
When I saved the pipeline, it has an entry like . Usually it would have something like 09262007
I set up a small ASP.NET web app to get the data from inputStream then pass it to wm.tn:receive. I would like to find a way so that I don’t need this extra layer.
In Igor Androsov’s ezine he mentioned that developers could use Service.getRequest((Values)pipeline); to get the inputStream. Javac was OK with the code when I saved it, at runtime I got class cast exception. Your way of using Values.use(pipeline) solved the problem. Hopefully webMethods will keep supporting the deprecated functions for backward compatability.