garyng

Hi, I am writing a system that allows users to upload jrxml and run on the tomcat server. So do I need to worry about what the queryString(SQL) can do like dangerous DELETE/UPDATE/DROP/ALTER etc. ? In a similar fashion, should I worry about code injection if the SQL statement are parameterized ? Or would it be easier/safer to just create a RDBMS users who can only READ RDBMS tables and use this user to connection to the jdbc data source? How in general people handle situation like this ?

Hi, I saw this as yet another FAQ in the forum yet there is again no definitive answer. Using the xmldatasource example, I tried to run the CustomerReport on a tomcat server and get the following exception : net.sf.jasperreports.engine.JRException: net.sf.jasperreports.engine.JRException: Could not load object from location : OrdersReport.jasper The is of course the case as given the name, it is expected to load from "current directory" where on tomcat, it is tomcat's root. Does this mean that every report that use subreport should be designed in a way that it takes a report parameter(like SUBREPORT_DIR as in iReport, like $P{SUBREPORT_DIR}/subreport.jasper) when specifing subreport ?

what RDBMS ? I remember there is an article talking about Oracle(which is a bit different). http://www.brianburridge.com/2006/06/04/how-to-call-stored-procedures-from-jasper-reports/ For other RDBMS where the store procedure returns standard resultset format(most I assume), the engine can already handle it as you just give it a query string(standard select) which call your store procedure. The above page should give you an idea even it is only for oracle. Basically, jasperReport in general needs a 'select' statement for its source(assuming DB).

Just some more clarification : The containing box must be larger than the font size, even 1 pixel overlapping(which is the case for the iReport generated sample) would result in the text got suppressed completely. Also, as mentioned in the FAQ, element must not overlap or else the same suppress effect would kick in. This behaviour as I mentioned in the previous post can be quite cumbersome to deal with(and undesirable) for situation like design in Windows then being deployed and run on linux where the font characteristics may be different(not visually but technically 1 or 2 pixels taller/shorter). Having elements displayed with one overlapping another is a visual bug(annoying but tolerable and easy to spot), having the element removed is a show stopper bug(and should not happen because of this reason). And I am only doing on the same Windows machine.

Found the reason of it. Just hope newbies in the future don't need to repeat this excercise again and can just search the forum for answer. It seems that jasperReports' engine are VERY VERY picky about the size. The standard report generated from iReport's wizard while can show properly in its own 'compile/execute' loop. The output(compiled file) somehow failed to show when I put it onto the server(using the same jasperreports jar and same java VM). I need to reduce the size of the containgin box and/or expand the containing band's height then it magically appear on the server based setup. This seems to be a very undesirable behaviour if there is a seperation of duty(report designer doing it in iReport yet the outcome is not what is in their design studio). Why can't it just 'clip' which at least give people a visual clue rather than this magically 'remove'. Especially in the context of PDF/HTML/XML where the presentation is handled by yet another program. It turns a presentation issue into a information loss issue.

Hi, I saw several posts about the same issue but I don't see a definitive solution. I created a very simple "hello world" report in iReport and when run it there, I can see the page title('hello world') using the empty data source. However, when copying the report to my application and run it with JasperFillManager(), all the staticText disappear(no where in sight in the output be it PDF/HTML/XML). Is this a setup issue as it seems that I am not the only one experiencing it. regards