Hi Dushan, I have created following Axis2 JIRA[1] to track this issue. Please comment about your ESB use cases there.
[1] - https://issues.apache.org/jira/browse/AXIS2-5374 Thanks ! On Thu, Jul 19, 2012 at 3:27 PM, Dushan Abeyruwan <[email protected]> wrote: > Hi Sagara, > Yes, Originally I had this concern i.e the way to determine SOAP 1.1 > and POX, I think ur suggestion is best suit in this case but anyway the > provided solution (Formatter/Builder concept) wont be a perfect one as u > mention, so will keep this as open and hope this will get sorted out in > AIXS2 context, mean time I will hold those issues reported to jira util > that. > > cheers > Dushan > > > On Thu, Jul 19, 2012 at 2:48 PM, Sagara Gunathunga <[email protected]>wrote: > >> >> >> On Thu, Jul 19, 2012 at 2:04 PM, Dushan Abeyruwan <[email protected]>wrote: >> >>> Hi >>> " For an example, in API Manager if you send a POX message with >>> the text/xml, the query parameters on the URL do not get passed to the >>> backend server, whereas they will get passed if we use application/xml >>> instead" >>> My thought is, >>> POX message received with text/xml context to API, then >>> hybrid builder get invoke, though we are receiving TEXT/XML while building >>> the message >>> OMElement element = applicationXMLBuilder.processDocument(new >>> ByteArrayInputStream(bytes), *HybridConstants.APPLICATION_XML*, >>> messageContext); , >>> we are* forcefully including the contentType as application/xml >>> NOTE: >>> we are Keeping the flag in message context with the actual received content >>> type*, thus synapse engine will treat this as application/xml and thus >>> will wont be a issue with query parameter, then at the formatter using >>> the flag just before send to BE setup the actual CONTENT TYPE to the >>> outgoing message thus this will write to the wire >>> >>> *sample code* >>> if (HybridConstants.TEXT_XML.equals(contentType)) { >>> SOAPBuilder builder = new SOAPBuilder(); >>> try { >>> return builder.processDocument(new ByteArrayInputStream(bytes), >>> contentType, messageContext); >>> } catch (Exception e) { >>> // assumption if a failure happens this must be check >>> // whether the message is >>> // is accepted as application XML >>> ApplicationXMLBuilder applicationXMLBuilder = new >>> ApplicationXMLBuilder(); >>> OMElement element = applicationXMLBuilder.processDocument(new >>> ByteArrayInputStream(bytes), HybridConstants.APPLICATION_XML, >>> messageContext); >>> *messageContext.setProperty(HybridConstants.HYBRID_BUILD, true);* >>> return element; >>> } >>> } >>> >> >> Here you first try to build the message with SOAPBuilder and and if it >> fail try to build with ApplicationXMLBuilder, this should work but isn't >> this approach add extra cost for POX messages processing ? It can be a very >> small overhead but in context of a ESB we should not ignore such small >> overheads too. Instead of above logic why don't you check SOAPAction >> header together with Content-Type header. According to SOAP 1.1 spec it's >> mandatory to have SOAPAction with valid SOAP 1.1 message if SOAPAction is >> missing it's safe to assume message as POX. >> >> content-type == text/xml && SOAPAction present => SOAPBuilder >> OW => ApplicationXMLBuilder >> >> Thanks ! >> >> >>> >>> cheers >>> Dushan >>> >>> >>> >>> On Thu, Jul 19, 2012 at 1:34 PM, Hiranya Jayathilaka >>> <[email protected]>wrote: >>> >>>> This solution will take care of the message parsing issue. But the main >>>> problem is Synapse and Axis2 both associating text/xml with SOAP 1.1. >>>> There's a lot of code written based on this assumption. For instance the >>>> parsing issue can be worked around by using something like the message >>>> relay (we do this in API Manager). But still there are certain things that >>>> don't work properly when you send a POX payload with the text/xml content >>>> type. For an example, in API Manager if you send a POX message with the >>>> text/xml, the query parameters on the URL do not get passed to the backend >>>> server, whereas they will get passed if we use application/xml instead. >>>> >>>> This is a very tricky problem to solve. I tried to solve this for API >>>> Manager, but had to give it up considering the time constraint and the >>>> possible stability issues it might introduce. We need to discuss this with >>>> a larger audience before we decide on the final plan. >>>> >>>> Thanks, >>>> Hiranya >>>> >>>> >>>> On Thu, Jul 19, 2012 at 1:24 PM, Dushan Abeyruwan <[email protected]>wrote: >>>> >>>>> >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: Dushan Abeyruwan <[email protected]> >>>>> Date: Thu, Jul 19, 2012 at 1:22 PM >>>>> Subject: Hybrid Message Builder (Solution for >>>>> To: DEV <[email protected]> >>>>> Cc: Miyuru Wanninayaka <[email protected]>, Udayanga Wickramasinghe < >>>>> [email protected]>, Afkham Azeez <[email protected]>, Kasun Indrasiri < >>>>> [email protected]>, Nuwan Dias <[email protected]> >>>>> >>>>> >>>>> Hi, >>>>> Recently we had a few issues [1][2] when invoking REST services >>>>> via ESB REST API when client sends information with the content type >>>>> TEXT/XML (and if BACK END accepts TEXT/XML) so when message receives to >>>>> ESB >>>>> if the content type is defined TEXT/XML by default it will try to build up >>>>> SOAP envelope, but AFAIK most REST calls are based >>>>> on TEXT/XML so theoretically this kind of messages should be able to >>>>> handle >>>>> via ESB, so for this as solution I have written a Builder formatter, >>>>> basically I named this as HYBRID message builder /formatter, the idea is >>>>> when client sends simple xml element with via REST (with content type >>>>> TEXT/XML) , the logic is first the hybrid builder checks if the message >>>>> content type defines as TEXT/XML followed by root element containing any >>>>> SOAP element. if not Hybrid builder invokes the Application XML builder >>>>> internally and will build the message and setting up a flag to message >>>>> context thus during the HybridFormatter invocation we can determine that >>>>> the original client request content type and write it to the output pipe, >>>>> >>>>> (did few mock testings with few use cases and worked well) >>>>> >>>>> any suggestions on this >>>>> >>>>> [1] https://wso2.org/jira/browse/ESBJAVA-1160 >>>>> [2]https://wso2.org/jira/browse/ESBJAVA-1160 >>>>> >>>>> cheers, >>>>> Dushan Abeyruwan >>>>> *Senior Software Engineer* >>>>> *Integration Technologies Team* >>>>> *WSO2 Inc. http://wso2.com/* >>>>> *Mobile:(+94)714408632* >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Dushan Abeyruwan >>>>> *Senior Software Engineer* >>>>> *Integration Technologies Team* >>>>> *WSO2 Inc. http://wso2.com/* >>>>> *Mobile:(+94)714408632* >>>>> >>>>> >>>> >>>> >>>> -- >>>> Hiranya Jayathilaka >>>> Senior Technical Lead; >>>> WSO2 Inc.; http://wso2.org >>>> E-mail: [email protected]; Mobile: +94 77 633 3491 >>>> Blog: http://techfeast-hiranya.blogspot.com >>>> >>> >>> >>> >>> -- >>> Dushan Abeyruwan >>> *Senior Software Engineer* >>> *Integration Technologies Team* >>> *WSO2 Inc. http://wso2.com/* >>> *Mobile:(+94)714408632* >>> >>> >>> _______________________________________________ >>> Dev mailing list >>> [email protected] >>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>> >>> >> >> >> -- >> Sagara Gunathunga >> >> Technical Lead; WSO2, Inc.; http://wso2.com >> V.P Apache Web Services ; http://ws.apache.org/ >> Blog ; http://ssagara.blogspot.com >> >> > > > -- > Dushan Abeyruwan > *Senior Software Engineer* > *Integration Technologies Team* > *WSO2 Inc. http://wso2.com/* > *Mobile:(+94)714408632* > > -- Sagara Gunathunga Technical Lead; WSO2, Inc.; http://wso2.com V.P Apache Web Services ; http://ws.apache.org/ Blog ; http://ssagara.blogspot.com
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
