The question whether to return null or to throw an exception arises every time one implements a method that performs some kind of lookup that may fail to produce a result. There is no universal answer to this question. Often times one prefers to return null in this case because throwing an exception is costly [1]. After all, why does java.util.Map#get return null if the key is not found? What is actually more important is that the behavior of the method is clearly documented and that the calling code performs the required checks.
The getSOAPPartContentType method indeed doesn't perform a null check on the result of getDataHandler. This has now been fixed. On the other hand, I tested Axiom with the response message you have posted earlier, and the current code processes this message successfully (i.e. getSOAPPartContentType is able to locate the SOAP part and to return its content type). Since the problem occurs with WAS 7.0, we can't give any further advice, and you will have to investigate that together with IBM support. Andreas [1] http://blog.dynatrace.com/2011/04/12/the-cost-of-an-exception/ On Fri, May 20, 2011 at 22:32, Anil Atyam <aanilku...@gmail.com> wrote: > My apologies. I didn't mean to question the ability of the programmers. There > could be a compelling reason to do so which I don't follow. Otherwise, I have > highest respect to these programmers and open source contributors. > > > > Thanks > Anil Atyam > Ph: 703 473 0039 > > > On May 20, 2011, at 3:48 PM, Andreas Veithen <andreas.veit...@gmail.com> > wrote: > >> You should be very, very careful before posting comments suggesting >> that the developers in this project are not doing "smart programming", >> especially if these comments tend to show your own inexperience in >> Java programming. >> >> I recommend reading the following article to learn about the do's and >> don'ts for a public mailing list: >> >> http://www.catb.org/~esr/faqs/smart-questions.html >> >> >> On Fri, May 20, 2011 at 19:40, Anil Atyam <aanilku...@gmail.com> wrote: >>> Folks >>> >>> >>> getDataHandler method of org.apache.axiom.attachments.Attachments returns >>> NULL when it can't find the content part it is looking based on the content >>> id. Shouldn't it return something else? I mean, if you return null its very >>> obvious that you get null pointer exception from this call is originiated, >>> in my case, org.apache.axiom.attachments.Attachments.getSOAPPartContentType. >>> >>> I am not really sure why would you want to return null. Instead, You can >>> handle the null case and throw an exception stating, required content based >>> on content id not found in message etc. >>> >>> >>> >>> >>> >>> I have copied my response MIME encoded message and please let me know if its >>> missing any MIME parts. My response schema has NO element of type >>> base64Binary, howerver, the response is MIME encoded. >>> >>> >>> >>> >>> >>> Checks whether the MIME part is already parsed by checking the attachments >>> HashMap. If it is not parsed yet then call the getNextPart() till the >>> required part is found. >>> >>> Parameters: blobContentID (without the surrounding angle brackets and "cid:" >>> prefix) Returns: The DataHandler of the mime part referred by the Content-Id >>> or *null* if the mime part referred by the content-id does not exist >>> Checks whether the MIME part is already parsed by checking the attachments >>> HashMap. If it is not parsed yet then call the getNextPart() till the >>> required part is found. >>> >>> Parameters: blobContentID (without the surrounding angle brackets and "cid:" >>> prefix) Returns: The DataHandler of the mime part referred by the Content-Id >>> or *null* if the mime part referred by the content-id does not exist >>> >>> >>> >>> 342 public DataHandler getDataHandler(String blobContentID) { >>> 343 DataHandler dataHandler; >>> 344 if (attachmentsMap.containsKey(blobContentID)) { >>> 345 dataHandler = (DataHandler) >>> attachmentsMap.get(blobContentID); >>> 346 return dataHandler; >>> 347 } else if (!noStreams) { >>> 348 //This loop will be terminated by the Exceptions thrown if >>> the Mime >>> 349 // part searching was not found >>> 350 while ((dataHandler = this.getNextPartDataHandler()) != null) >>> { >>> 351 if (attachmentsMap.containsKey(blobContentID)) { >>> 352 dataHandler = (DataHandler) >>> attachmentsMap.get(blobContentID); >>> 353 return dataHandler; >>> 354 } >>> 355 } >>> 356 } >>> 357 return null; >>> 358 } >>> >>> >>> >>> >>> MIME encoded response from the server side. >>> >>> >>> HTTP/1.1 200 OK >>> Connection: close >>> Date: Thu, 12 May 2011 14:42:15 GMT >>> Server: Microsoft-IIS/6.0 >>> X-Powered-By: ASP.NET >>> X-AspNet-Version: 2.0.50727 >>> Cache-Control: private, max-age=0 >>> Content-Type: multipart/related; type="application/xop+xml"; >>> boundary=--MIMEBoundary634407937359568655; >>> start="<0.634407937359568...@example.org>"; start-info="text/xml; >>> charset=utf-8" >>> Content-Length: 890 >>> >>> ----MIMEBoundary634407937359568655 >>> content-id: <0.634407937359568...@example.org> >>> content-type: application/xop+xml; charset=utf-8; type="text/xml; >>> charset=utf-8" >>> content-transfer-encoding: binary >>> >>> <soap:Envelope xmlns:xop="http://www.w3.org/2004/08/xop/include"; >>> xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"; >>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; >>> xmlns:xsd="http://www.w3.org/2001/XMLSchema"; >>> xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"; >>> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"; >>> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";><soap:Body><TravelDocumentNotificationRS >>> Version="1.000" xmlns="http://www.amtrak.com/schema/2010/01/01";><Success >>> /></TravelDocumentNotificationRS></soap:Body></soap:Envelope> >>> ----MIMEBoundary634407937359568655-- >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org >> For additional commands, e-mail: java-dev-h...@axis.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org > For additional commands, e-mail: java-dev-h...@axis.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org For additional commands, e-mail: java-dev-h...@axis.apache.org
