egeorge

I resolved this by altering the table in the jasperserver database. I increased the field size from 100 to 500, although I don't think this is a very good solution at all. alter table jijdbcdatasource alter column password type varchar(500); I agree with mr.john.lynn that if there is a true limit, then it should be reflected in the datasource creation web interface.

I have an HTML5 chart in my report and I want to set the default type from a parameter, but still allow the gear-dropdown to change the type afterwards. I am using Visualize.js to embed my report into another application. My jrxml defines the chart in this way: <hc:chart type="Pie" xmlns:hc="http://jaspersoft.com/highcharts" xsi:schemalocation="http://jaspersoft.com/highcharts http://jaspersoft.com/schema/highcharts.xsd"> <hc:chartsetting name="default"> <hc:chartproperty name="chart.type"> <hc:propertyexpression><!--[CDATA[$P{chartTypeParam}]]--></hc:propertyexpression> </hc:chartproperty> </hc:chartsetting> Where chartTypeParam is the parameter passed into the report. This works fine to set the default type of the chart. But when I then use the gear menu dropdown in the rendered report to change the type, it just reloads with the same value that was passed in as a parameter. I want the parameter to define only the default, and still allow the user to select a new type afterwards. I can get around this problem by making a copy of the chart element for every type I want, then hiding all but one chart as specified by the parameter, but that is horrific and unmaintainable. I would have to have the same configuration code 6 different times. Any advice would be helpful.

I have found the reason for this. If you deploy jasperserver onto *more than one* virtual server, then this error will occur when the ehcache tries to load itself twice. The solution I have found, is to set up a single virtual server in glassfish, then associate that with multiple listeners. That is if you actually need more than one listener. In my case, I need it to listen on JK, for proxied calls, and also on a "plain" http socket for REST calls.

I am experiencing exactly the same error installing the JR war (4.7.0) on glassfish (also 3.1.2). It is baffling to me because the installation should be identical to the one that went smoothly on a different server.

Here is a quick and dirty xslt that will strip out the pesky uuid attribute you can run your jrxml files through this using xsltproc or whatever similar tool you might use: version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:fo="http://www.w3.org/1999/XSL/Format">