bbergquist

Lucien, I would certainly be able to give this a try but I'm having trouble (not familiar) with how to find what the fix actually was. Would it be possible to send me the changed file or give me just a little more info an what I need to do to my local build to put in the same fix.

The scenario in the bug report is exactly the same scenario that I had with the exception that the bug reporter was using LDAP as the external authentication source and I'm using an external JDBC source. The symptom of the user being created and the roles being created but the roles not be associated with the user, the exception being thrown, and the fact that subsequent login with that user corrected the roles to group association is exactly the same. What is happening is when the user to role association is being done down in the code, the a query is performed to lookup the role. But in this case the role is newly created (probably within the same transaction) and the query does not see the role. Some persistence providers would flush any objects from memory to the persistence storage before performing the query but I don't believe that is required by spec. So the query does not find the role created and the one that it associated with the user object is just an in memory role with no persistence. When the user is persisted, the exception occurs because you now have a persistence managed user associated with non-persistence managed role. Putting the flush in when the role is created ensures that later when the query for the role is done, it will find the role and return a persistence managed role. Now when the role is associated with the user and the user is persisted, both are persistence managed and no error occurs. Since at any point it is allowed to perform a flush, there really is no risk in putting in the change I mentioned. The only downside might be a performance hit if you were performing this operation many times very frequently because you are now causing the persistence cached object to be synchronized with storage (ie. a database update or insert) where it might be more efficient to batch this up later. In this use case, however, it is very unlikely that roles are created very frequently and repeatedly so the flush will occur at most once per role being created.

Lucian, I was just about to go enter a bug for this. I had to create an account and got sidetrack but finally got around to it today. I saw this bug http://jasperforge.org/sf/go/artf3008?nav=1 This seems to be the same bug. I don't know how (or if I can) update the bug with my comments so I'm posting here instead but I think the fix that I provided will take care of this problem. It did for me. Brett

Thanks for the tip. I will give that a try.

Is there anyway to set a default value for REPORT_MAX_COUNT either from a Scriptlet or some other mechanism. I'm using JasperServer and have a report with a large dataset and would like to enforce a maximum record count for the report. If I were driving the report filling myself, I would pass in this parameter but since JasperServer is running the report, I don't know how to set this parameter. Actually I do know of a way but I don't like how it is done. In JasperServer I can create an input control called "REPORT_MAX_COUNT" and then provide a value there when the report is run. The problem is that this input control must be available and must be entered by the user and I don't know how to give a default value. So is there anyway to set this built in parameter via a Scriptlet?

It seems that the inegration of roles, permissions, and resources is not quite complete. For example, I can create a new folder resource "/output" and give the role ROLE_USER permission to Administer this resource. It seems like the idea is that now a user with ROLE_USER should be able to create a folder "/output/pdf" for example since he can Administer the "/output" folder. The problem is, if I log in as a user with ROLE_USER role, the "Managed Repository" menu is not even there. So I decided to fix this. I modified "applicationContext-security.xml" to allow ROLE_USER to get to the "Manage Repository" menu. This worked okay but then I found all of the resources listed had the "Assign" link available where I could change the permissions for a resource, unfortunately even for those resources that the logged in user does not have "Administer" permission set. So I decided to fix this. I modified "RepoAdminAction.java" to set a hashmap called "adminResources" in the RequestContext request scope with an entry for each resource the the current user has "Administer" permission for. This looks at all of the roles assigned to the user as well as the permissions explicitly assigned to the user. I borrowed most of this code from "ObjectPermissionAction.java" because this had the code that would walk up the folders to find any inherited "Administer" permission. It seems that this would be better put into "RepositoryServiceSecurityChecker.java" and the effective permission lookup in "ObjectPermissionServiceImpl.java" but this this appeared to be the quickest and best understood by me, so I implemented it in "RepoAdminAction.java". I then modified jsp/repoAdmin/defaultView.jsp" so the "Assign" link was rendered as just plain text if the current user does not have "Administer" permission for the resource. I also modified the "Assign Permissions" link with the current folder on this page to operate the same. With these changes it is possible to give a certain role or use Administer permissions on a portion of the repository without having to give the user ROLE_ADMINISTRATOR and allowing the user to do everything. If this is something that seems worthwhile, I can provide the changes that I did back to the community.

I have JasperServer running with Glassfish and Derby. I hit an issue however with JSErrorPage.jsp and when Springframework forwards to that page. For example, if I do something on which an AccessDenied exception will be thrown, I get a NullPointerException in JSErrorPage.jsp. I tracked this down to the code that is generated by Glassfish for a JSP error page (ie. 'isErrorPage="true"'). The code looks like: Code: public void _jspService(HttpServletRequest request, HttpServletResponse response) throws java.io.IOException, ServletException { PageContext pageContext = null; HttpSession session = null; Throwable exception = org.apache.jasper.runtime.JspRuntimeLibrary.getThrowable(request); response.setStatus(((Integer)request.getAttribute("javax.servlet.error.status_code"«»)).intValue()); ServletContext application = null; ServletConfig config = null; JspWriter out = null; Object page = this; JspWriter _jspx_out = null; PageContext _jspx_page_context = null; The above code tries to get the "javax.servlet.error.status_code" attribute from the request. The problem is that Springframework does not put this attribute into the the request map before forwading to JSErrorPage.jsp. I don't know what the standards say about forwarding to a JSP error page, but I don't think I will be able to change the Glassfish generated code. So any error that causes a forward to JSErrorPage.jsp causes a NullPointerException error and the original error is lost. So can anything be done about this? For now, I wrote a simple servlet filter that sets "javax.servlet.error.status_code" to "200" so that at least the NPE will not happen. This works but I'm not sure it is the proper way to do this.

I've got JasperServer 2.1.0 working with Glassfish V2 and Apache Derby. I connected JasperServer authentication to my own JDBC authentication realm in Glassfish. I ran into an issue however when the my external users and roles are migrated over to the JasperServer security domain. This occurs when both a new user and a new role are being migrated over from the external security realm. Hibernate was throwing an exception stating that a relationship to an unknown object was found when persisting. I traced this down and found that when a new external role is migrated over to JasperServer, it creates and persists role but later when the new user is persisted, the code goes through and finds the roles and associates the roles with the user. But with a brand new role that was just added, Hibernate does not find the role when executing the query. I fixed this problem by adding getHibernateTemplate().flush() to "putRole" in UserAuthorityServiceImpl.java: Code: /* (non-Javadoc) * @see com.jaspersoft.jasperserver.api.metadata.user.service.UserAuthorityService#putRole(com.jaspersoft.jasperserver.api.common.domain.ExecutionContext, com.jaspersoft.jasperserver.api.metadata.user.domain.Role) */ public void putRole(ExecutionContext context, Role aRole) { RepoRole existingRole = getRepoRole(context, aRole.getRoleName()); log.debug("putRole: " + aRole.getRoleName() + ", " + existingRole); if (existingRole == null) { existingRole = (RepoRole) getPersistentClassFactory().newObject(Role.class); log.debug("New Object"«»); } existingRole.copyFromClient(aRole, this); getHibernateTemplate().saveOrUpdate(existingRole); // XXX getHibernateTemplate().flush(); // XXX Set repoUsers = existingRole.getUsers(); for (Iterator it = repoUsers.iterator(); it.hasNext();«») { RepoUser repoUser = (RepoUser) it.next(); repoUser.getRoles().remove(getPersistentObject(aRole)); } Set users = aRole.getUsers(); for (Iterator it = users.iterator(); it.hasNext();«») { User user = (User) it.next(); addRole(context, user, aRole); } } This causes the newly created Role to be found when the query in getRepoRole is executed. Should this be logged as a bug with a possible fix?