Jump to content

QueryExecuterFactory not invoked on JasperServer


msn

Recommended Posts

Hi all

First of all, I am working with JasperServer and iReport version 3.5.0.

I have made a custom data source which seems to work fine. I have based it on the WebScraper example in order to make sure that all names are correct (as long as I am only trying to get it to work anyway), but I have changed the functionality of it a bit.

In iReport, when I add a classpath to the needed .class files, add a query language 'webscraper' (matching that specified in applicationContext-webscraperDS.xml), and set the data source to be Query Executer mode, then everything is working just fine.

On the JasperServer, my custom data source is available in the list when I add a new Data Source on the JasperServer. I have uploaded a test report, which I have set to use my custom data source. The report does show, but it is filled with data from the custom data source using the data source's default properties (default parameters), NOT based on the <queryString language="webscraper"> of the report.

That is why I guess that the QueryExecuterFactory is never invoked, and as there are no errors it must not even try.

Is there a way to add a Query Executer mode to the JasperServer, that forces the use of the QueryExecuterFactory (as pointed to in the applicationContext-webscraperDS.xml)?
Or does anyone have another idea to why the query string is not used, even though the report has one defined?


Any ideas are appreciated.
Thanks


 

Link to comment
Share on other sites

  • Replies 5
  • Created
  • Last Reply

Top Posters In This Topic

I figured it out myself through trial and error.

In order to make JasperServer recognize my custom query language, I had to add it to the following file:

  ...\jasperserver-3.5.0\apache-tomcat\webapps\jasperserver\WEB-INF\flows\queryBeans.xml

As my custom query language is "webscraper", I added <value>webscraper</value> to it so it looks like this:

...<property name="queryLanguages">  <list>    <value>sql</value>    <value>hql</value>    <value>webscraper</value>  </list></property>...[/code]

Also I figured out, that the DataSource reference to when adding the report to JasperServer no longer matters. It could be any data source. When the <queryString> is supplied, and the custom language recognized, the correct data source will be created by the QueryExecuter class. I believe this connection between query language and QueryExecuter class is made in the applicationContext-webscraperDS.xml.

Link to comment
Share on other sites

  • 2 months later...

For a queryExecuter to work so that it picks up the queryString in the JRXML, you need to make sure that you do not set the JRParameter.REPORT_DATA_SOURCE in the parameter map. If you set REPORT_DATA_SOURCE, the queryString in the JRXML will be ignored.

 

 

A lot of report data sources cannot be used in query input controls, because they lack result set field types and possible additional data that some data sources which is in the field description tag in JXML. If a data source type can be used in a query input control, the way to make it appear on the query maintenance screen for query input controls is as you found: adding the queryLanguage into the queryBeans.xml.

 

Sherman

Jaspersoft

 

Link to comment
Share on other sites

You've hit on a subtle issue with respect to data sources in JasperServer.

Sherman is correct about setting JRParameter.REPORT_DATA_SOURCE in the parameter map. If you create a JasperServer report unit which uses a data source from the repository, and that data source sets the JRParameter.REPORT_DATA_SOURCE parameter, JasperServer says "OK, I already have my JRDataSource and I don't have to run the query".

If this seems a little confusing, read on.

There are really three possible ways you can get a JRDataSource to a report in JasperServer (notice that I don't mean JasperServer data source, because this is actually optional):

1. JasperServer data source only

You can create an implementation of a JasperServer custom data source which can work without a query. It can get all the information it needs from Spring configuration or from the parameters of the JasperServer data source in repository. When this custom data source is used in a report, it sets the parameter JRParameter.REPORT_DATA_SOURCE in the parameter map, which JasperServer then passes on to the report.

An example of this is the Webscraper datasource when used without a query. This is used in the example report customDataSource/reports/webscrapertest.jrxml.

2. QueryExecuter only

You can create an implementation of JRQueryExecuterFactory and JRQueryExecuter that can get all the information they need to create a JRDataSource from the query itself.

An example of this is the Webscraper query executer, which is used in the example report customDataSource/reports/webscraperQEtest.jrxml, which works without a JasperServer data source.

3. JasperServer data source with QueryExecuter

In this case, the JasperServer data source and the JRQueryExecuter work together to create the JRDataSource. The JasperServer data source sets parameters which get used by the JRQueryExecuter implementation. The JRQueryExecuter parses the query and creates the JRDataSource for the report.

Examples of this are the JDBC and JNDI JasperServer data sources, which work with the SQL JRQueryExecuter to create a JRDataSource from a SQL query.

The confusing thing about the webscraper example is that it can be run as either type 1 or type 2, but when you run it as type 2 (using a query), you can't use the JasperServer data source.

Most implementations will be either type 1 or type 2, but not both.

Link to comment
Share on other sites

One more point to connect this up to what you're trying to do:
It sounds like you tweaked the webscraper data source query executer, so you are using the example in "mode 2" as I described above. This means that if you want to use it on JasperServer, just create your report unit without associating a data source.

Let me know if I still haven't cleared this up.



Post Edited by bobtins at 04/05/2010 17:48
Link to comment
Share on other sites

  • 5 years later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...