Hi Ruwan, please see my comments inline!
> > 2) HTTP-200 reply, create Hessian fault > > ------------------------------------ > > > > Config used: > > <syn:outSequence> > > <syn:property name="HTTP_SC" value="200" scope="axis2"/> > > <syn:send/> > > </syn:outSequence> > > > > > > This doesn't work. On the esb side the following exception occurs: > > > > 2008-04-07 11:06:15,485 [10.137.148.70-lenny] [HttpClientWorker-1] ERROR > > HttpCoreNIOSender IO Error sending response message > > org.apache.axis2.AxisFault: Unable to find the hessian content in the > > payload > > at > > org.apache.synapse.format.hessian.HessianMessageFormatter.handleExceptio > > n(HessianMessageFormatter.java:216) > > at > > org.apache.synapse.format.hessian.HessianMessageFormatter.writeTo(Hessia > > nMessageFormatter.java:174) > > > Well, I think I forgot to tell you to remove the messageFormatter and > messageBuilder pair for "text/html" in the axis2.xml to try this. The > axis2.xml file can be found at $ESB_HOME/webapp/WEB_INF/classes/conf > folder. Basically you need to remove the following entries from the > axis2.xml; Ah, I was close to remove them. I'm not familiar with those builder/formatter pairs. When (und which condition and in which order) are they executed? As this is a very central place this is a general behaviour for all service, right? I should have a more detailed look at this and get back to you... > <messageFormatter contentType="text/html" > > class="org.apache.axis2.transport.http.ApplicationXMLFormatter"/> > > <messageBuilder contentType="text/html" > > class="org.apache.axis2.builder.ApplicationXMLBuilder"/> > > Note: please note that there is a similar set of formatter and a builder > for the "application/xml" content type as well and you must not remove > those. Thanks, I will take care. :-) > > The answer from the server is no valid hessian reply, so the "complaint" > > of the ESB is somehow correct. Unfortunately this blocks the client for > > some time until it receives a HTTP 200 reply, which it tries to handle > > as a Hessian reply, but the InputStream is null, which results in a > > NullPointerException on the Hessian-Client part. If I got you right it > > should be expected to get a newly created Hessian fault which would not > > contain the original stack information like the html-report. Otherwise > > you would need to extract the stack details. > > > Yes, you are correct, but what happened here is that since the text/html > message builder is there it builds the message as an html message and we > expect that to be a hessian message, which is the root cause of this > error. Please try this after removing the html message builder and > formatter pair. Will do so! Thanks for the explanation - now the behaviour is clear. > > So if I would like to go with option one I had to create a > > defaultHessianOut-Sequence which had to use the X-Path filter and the > > property mediator. I than would need to specify this sequence for each > > and every Hessian-Service. Right? I would like to reduce the > > configuration overhead as much as possible. > > > Well, I just added a new feature called mandatory sequence onto the > synapse trunk, where all the messages will be mediated using this > sequence before coming into the proxy service mediation. I don't think > we can do anything more than that because this is an exceptional > behavior (probably which is wrong) and we can not inject this into > Synapse. Of course. > > Maybe a configurable protocol-specific default-sequence would be a nice > > addition for the future? > > > This sounds interesting to me.... :-), as I told you I have just > implemented a mandatory sequence and the name of that sequence has to be > "pre-mediate". So we do not need any further protocol specific default > sequences because that can be handled using a filter inside this > sequence. For example; > > <sequence name="pre-mediate"> > <filter source="$axis2:messageType" regex="application/hessian"> > > <syn:filter xpath="//html"> > <syn:property name="messageType" value="text/html" scope="axis2" /> > <syn:property name="ContentType" value="text/html" scope="axis2" /> > </syn:filter> > > </filter> > </sequence> > > Does this solves your problem? Yeah, I think this should solve the problem. But this implies running this filter on every request, also on SOAP requests were this would make no sense at all. Maybe this check is not very expensive, but I'm doubtful whether this would be a good approach or not. I know there is always a trade-off between generic, very flexible and more static solutions. I also thought of storing a kind of "service or protocol type" information in the registry for other reasons - namely testing. One other feature I'm missing is a way to check whether my current esb configuration is valid. I mean not valid in terms of syntactical checks but valid from a functional view. E.g. did the administrator specify the right service endpoints? Are hostnames and ports correct? It would be cool, if one could easily test this on different levels (single endpoint, all endpoints, single proxy service, all proxy services). In order to do meaningful testing one would have to generate a proper request, send it, and present the result. Maybe one could specify the name of an existing test method of the service. How to incorporate this, if the esb (registry) does not know, which protocol to use? This is only one example where I think having this information centrally available would help. Protocol-specific sequences are another example. Regards, Eric _______________________________________________ Esb-java-dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/esb-java-dev
