maggix

This thread helped me a lot, check if it's useful for you http://jasperforge.org/plugins/espforum/view.php?group_id=112&forumid=102&topicid=59680&page=1

Hello mdahlman, thank you for your suggestion! It's always good to look at problems from a different perspective:your solution works great. I assigned the "No Access" permissions to the "SharedElements" folder (which does not contain reports) and then assigned "Read Only" to the child folers inside "SharedElements" (which contain queries, images and so on). Users now can see only the Reports folder but are allowed to run reports. However, the "Execute" privilege would definitely be a nice addition to JAsperServer, so (after a check to avoid duplicates) I posted this issue to the tracker as you suggested: http://jasperforge.org/projects/jasperserver/tracker/view.php?id=4550 For the moment I will keep this configuration waiting for the next JS release. At least I avoided manual edit of XML files, which would make upgrade more difficult. Regards, Giovanni

Hello, I was wondering if there was a way to hide some of the folders in Jasperserver without using the "no access" setting in permissions. I created a folder containing the reports and another one which contains the resources for those reports (images, input data types, queries and such). If I set "no access" to the "Shared Resources" folder, users cannot run reports because they can't access those resources, however if I set the "hidden" flag in the database, no one is able to see that folder (not even administrators) for editing purposes. There are other threads in this forum that deal with this problem, but none of them has a solution. I was wondering if someone knew how to change the applicationContext-security.xml to change the way Jasperserver deals with permissions on resources: I'd like to be able to achieve a setting that does not display folders to the users but allows the reports ran by those users to access the resources contained. I hope I explained what I mean :) Thank you in advance Giovanni

Hello, I'd like to inform you that the problem did apply in my case only when Inputcontrol had reference to an external "datatype", so the MultiSelect Queries and such were not affected. However I solved my problem by recreating the input controls, case can be closed for me

Hello, I attached an image of my working Jaspersoft 3.5 configuration. As you can see, the Input controls of each report are links to the shared input controls, which in turn use the shared data types in /datatypes Same goes for the images and for the scriptlets I am not sure that attaching the .sql dump of the database could be of any help, since many of the input controls are Multiple selects that feed data from database with SQL Selects...

Hello, as lucianc wrote, the problem may be related to input controls. Check name consistency and try to see if deleting and recreating input controls solve your problem, as it seems to work for me. Regards, Giovanni

I am quoting here a reply I wrote on the JasperForge forums, as it seems I found the solution to the problem. Seems like the references to the shared (linked) Inputcontrol, DataTypes, Queries was broken during upgrade. " Hello, after further investigation it turned out that I concentrated my searches on the Scriptlet variables, while the problem was in the migration of DataTypes , InputControls and Queries, which references were broken during the upgrade. Our JasperServer installation heavily takes advantage of the fact that JS allows linking to resources and controls. So I created a structure like |-Reports |-ProductionReports |-..... |-SharedElements |-InputControls |-ProductionReportsInputConrols |- ... |-DataTypes |-Queries I hope I gave the idea :) Which means that data types are shared among many input controls, and each input control is shared among many reports. Each report has at least 6 InputControls associated with it. While the names were correct, it turned out that the references to those elements were somehow broken during migration, resulting in missing references when running the report. When I run the report in iReport, the error does not show up because iReport does not take in account the Inputcontrols defined on the server, and it relies only on the Input Parameters specified in the jrxml (correct me if I'm wrong). I took a test report and had to delete the references then create a set of "Local" inputcontrols to get it working. It seems that I'll have to delete and create again all the shared resources, because simply editing those resources doesnt seem to get it working.Only the shared resources that I deleted and created as new worked again. Should I have done something to avoid this? Did it happen to someone else? Thank you for helping me, now I am stopping my test of JS 3.7 RC and waiting for the release to come out before trying again and see if migration works. Tell me if I should update this topic or consider the issue solved (In my opinion it is not, because other people may find themselves in the same situation, but at least now I know how to somewhat fix it) Regards, Giovanni "

Hello, after further investigation it turned out that I concentrated my searches on the Scriptlet variables, while the problem was in the migration of DataTypes , InputControls and Queries, which references were broken during the upgrade. Our JasperServer installation heavily takes advantage of the fact that JS allows linking to resources and controls. So I created a structure like |-Reports |-ProductionReports |-..... |-SharedElements |-InputControls |-ProductionReportsInputConrols |- ... |-DataTypes |-Queries I hope I gave the idea :) Which means that data types are shared among many input controls, and each input control is shared among many reports. Each report has at least 6 InputControls associated with it. While the names were correct, it turned out that the references to those elements were somehow broken during migration, resulting in missing references when running the report. When I run the report in iReport, the error does not show up because iReport does not take in account the Inputcontrols defined on the server, and it relies only on the Input Parameters specified in the jrxml (correct me if I'm wrong). I took a test report and had to delete the references then create a set of "Local" inputcontrols to get it working. It seems that I'll have to delete and create again all the shared resources, because simply editing those resources doesnt seem to get it working. Only the shared resources that I deleted and created as new worked again. Should I have done something to avoid this? Did it happen to someone else? Thank you for helping me, now I am stopping my test of JS 3.7 RC and waiting for the release to come out before trying again and see if migration works. Tell me if I should update this topic or consider the issue solved (In my opinion it is not, because other people may find themselves in the same situation, but at least now I know how to somewhat fix it) Regards, Giovanni

I also attached the server.log file from Glassfish of an unsuccessful run of a report

I got help from user lucianc on Jasperforge forums: http://jasperforge.org/plugins/espforum/view.php?group_id=112&forumid=102&topicid=69386 A more detailed error log: HTTP Status 500 - type Exception report message descriptionThe server encountered an internal error () that prevented it from fulfilling this request. exception org.springframework.web.util.NestedServletException: Request processing failed; nested exception is org.springframework.webflow.execution.ActionExecutionException: Exception thrown executing [ViewReportAction@325b5 formObjectName = 'formObject', formObjectClass = [null], formObjectScope = Flow] in state 'checkForParams' of flow 'viewReportFlow' -- action execution attributes were 'map[[empty]]' root cause org.springframework.webflow.execution.ActionExecutionException: Exception thrown executing [ViewReportAction@325b5 formObjectName = 'formObject', formObjectClass = [null], formObjectScope = Flow] in state 'checkForParams' of flow 'viewReportFlow' -- action execution attributes were 'map[[empty]]' root cause java.lang.NullPointerException

Thank you for your time, I am going to look into it and post my findings as a reply on this topic!

I did as told (I commented the lines you asked me to remove) and the result is that the jasperserver.log does not display any error, while on the server page I get the following error. I attach the server.log file HTTP Status 500 -type Exception report message descriptionThe server encountered an internal error () that prevented it from fulfilling this request. exception org.springframework.web.util.NestedServletException: Request processing failed; nested exception is org.springframework.webflow.execution.ActionExecutionException: Exception thrown executing [ViewReportAction@19a6d0b formObjectName = 'formObject', formObjectClass = [null], formObjectScope = Flow] in state 'checkForParams' of flow 'viewReportFlow' -- action execution attributes were 'map[[empty]]' root cause org.springframework.webflow.execution.ActionExecutionException: Exception thrown executing [ViewReportAction@19a6d0b formObjectName = 'formObject', formObjectClass = [null], formObjectScope = Flow] in state 'checkForParams' of flow 'viewReportFlow' -- action execution attributes were 'map[[empty]]' root cause java.lang.NullPointerException note The full stack traces of the exception and its root causes are available in the Sun GlassFish Enterprise Server v2.1 logs. Sun GlassFish Enterprise Server v2.1

Hello, the installation went smoothly using the Buildomatic script provided in the Jasperserver distribution. Yes, all the reports I created stopped working after the update. I used Java SDK 1.6u17 installed on my system. The war file is deployed in the /autodeploy folder in the GlassFish "domain1" directory, as it should be. I also opened a thread in the forums to see if someone can provide some suggestions I could not think of. Regards, Giovanni

The jasperserver log file is called jasperserver.log and is located at C:SunAppServerdomainsdomain1autodeployjasperserver.warWEB-INFlogs on my machine. I am attaching you the logfile I get after a server restart, as well as server.log which is the Glassfish logfile located in domain1logs directory. This logfile is obtained with the server running in Debug Mode. As for the app server itself, with some noteworth log entries such as the one I attached in the CODE section below due to its length and this one: [#|2010-01-13T18:12:29.632+0100|WARNING|sun-appserver2.1|javax.enterprise.system.tools.admin|_ThreadID=10;_ThreadName=main;_RequestID=b253dd7c-bbb7-4ea3-b9c1-cd62ea5186d6;|Not registering AMX MBean against old MBean "com.sun.appserv:j2eeType=WebModule,name=jasperserver,J2EEServer=server,J2EEApplication=null,category=runtime" due to malformed composite WebModule name.|#] I also attached the server log. I know that this doesn't add much informations but I can assure I am clueless and I'm trying to be as helpful as possible. Thank you Giovanni Code: Post Edited by maggix at 01/13/2010 17:06

Hello, thank you for replying! Attached in the "code" section is the logfile from Glassfish V2. Action I took for this logfile: 1- I logged in as jasperadmin/jasperadmin on localhost (first 2 lines) 2- I clicked on the report Could it be something regarding scriptlets? I had a custom scriptlet named dateUtilitiesScriptlet in the package I called dateUtilitiesScriptletP, which imports net.sf.jasperreports.engine.JRDefaultScriptlet and extends JRDefaultScriptlet.( public class DateUtilitiesScriptlet extends JRDefaultScriptlet ) It was compiled using jasperreport included in the 3.5.0 distribution, should it be recompiled for the libraries included in 3.7.0 RC? [EDIT] I tried uploading the .jrxml again, and checking all Resources from within JasperServer 3.7 , but still no luck. The error is the same as before Regards Giovanni Code: Post Edited by maggix at 01/13/2010 13:30