Understood, I could use the JNDI definition if I create a connection myself in the code and pass that to the report. That may be an option in that I think I can pass the connection into the executing report.
When you use Jasper Studio to build the report and define a JDBC connection there, you get a datasource xml file referenced in the jrxml file. It is very possible that the JDBC connection the user creates is different from the JNDI CubaDS data source, so I’m not sure that automatically creating the JNDI connection is the right thing to do. I’m also not sure if the resulting jrxml file will work if the user doesn’t remove that property referencing the connection xml file before uploading the template. I can test that.
One small disadvantage of using your report template and bands, or defining the connection externally, is that I have to create all the report fields by hand. To avoid that, I have to use a connection created in Jasper Studio. But we can’t mix the approaches, since the fields defined by the SQL don’t have “band” names in them. It’s a lot of manual effort or embed the SQL query in the jrxml file itself. And then I get the datasource xml file, etc…
An alternative would be to extend your report schema to allow us to upload the connection xml file. If we did that, I could extract it in the same way as I extract the jrxml template from the database and create the connection in the code. But that requires changes to your schema.
My only solution so far has been to put the xml file in the main directory of app-core (build/tomcat/webapps/app-core) manually. I can then access it, but it has a plain text password and that would be accessible on the web. NOT a good solution yet. :-/ Jasper Reports has a Jasper Server that I’m trying NOT to require since I don’t think it will work with your report band definitions. It would require SQL defined in the report. If you use Jasper Server, then it provides the data source to the report by storing the definition in a database and hiding the password. It also appears to encrypt the password in xml files.
All in all, still a work in progress. No good solution presents itself yet. I am open to suggestions.