WMS Java Mapscript : msIO_getStdoutBufferBytes bug

José Vilson de Mello de Farias vilson.farias at DIGITRO.COM.BR
Wed Aug 9 09:32:33 EDT 2006


Greetings,

  I've compiled MapServer from the CVS HEAD 4.9-dev (2006-07-28) and I'm 
suposing the msIO_getStdoutBufferBytes is not working properly when used 
in Java Mapscript. I've written a very simple example to explain how it 
happens. Please take a look at it :

      public void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOExcept

      {
        PrintWriter p = resp.getWriter();
        mapObj map = new mapObj("/home/maps/rs.wms.map");

        OWSRequest reqOWS = new OWSRequest();
        reqOWS.setParameter("SERVICE", "WMS");
        reqOWS.setParameter("VERSION", "1.1.0");
        reqOWS.setParameter("REQUEST", "GetCapabilities"); 
     

        mapscript.msIO_installStdoutToBuffer();
        map.OWSDispatch(reqOWS); 
     

        String contentType = mapscript.msIO_stripStdoutBufferContentType();
        byte[] content = mapscript.msIO_getStdoutBufferBytes();
        p.print(new String(content));

      } 


The "byte[] content" stores the result of 
msIO_stripStdoutBufferContentType and it has some garbage data at the 
end. After the > 0x3E we have an NL 0x0A and finally a EOF 0x00, BUT the 
content doesn't stop at this point, there are more data after the 0x00 
and the Java Mapscript can "see" it. That's a big problem, because when 
this "content" is returned, the resulting XML is corrupted. Please check 
this example bellow.

    000018a0  20 20 20 20 20 20 20 20  20 3c 2f 4c 65 67 65 6e  |         </Legen|
    000018b0  64 55 52 4c 3e 0a 20 20  20 20 20 20 20 20 3c 2f  |dURL>.        </|
    000018c0  53 74 79 6c 65 3e 0a 20  20 20 20 3c 2f 4c 61 79  |Style>.    </Lay|
    000018d0  65 72 3e 0a 20 20 3c 2f  4c 61 79 65 72 3e 0a 3c  |er>.  </Layer>.<|
    000018e0  2f 43 61 70 61 62 69 6c  69 74 79 3e 0a 3c 2f 57  |/Capability>.</W|
    000018f0  4d 54 5f 4d 53 5f 43 61  70 61 62 69 6c 69 74 69  |MT_MS_Capabiliti|
    00001900  65 73 3e 0a 00 14 00 00  00 14 00 00 00 14 00 00  |es>.............|
    00001910  00 14 00 00 00 14 00 00  00 14 00 00 00 14 00 00  |................|
    00001920  00 14 00 00 00 14 00 00  00 14 00 00 00 14 00     |...............|

Is it a known bug? I'm afraid this kind of garbage can produce 
undesirable effects in WMS support. For this simples example I can 
"manually" remove it but I'm not sure how to deal with it in other 
cases. I'll be greatful if you could give me some light.


Best regards,

-- 
*José Vilson de Mello de Farias*
/Analista de Sistemas
//SSE - Segurança Pública/

*DÍGITRO TECNOLOGIA*
*E-mail:* vilson.farias at digitro.com.br 
<mailto:vilson.farias at digitro.com.br%20>
*Messenger: *vilsonfarias at hotmail.com 
<mailto:vilson.farias at digitro.com.br%20>
***Site:* www.digitro.com.br <http://www.digitro.com.br%20> 
<http://www.digitro.com.br%20>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapserver-users/attachments/20060809/4f440cdf/attachment.html


More information about the mapserver-users mailing list