I found the problem. It's not really a problem of the PermissionManager. The problem is by the transaction:
this is a quote from e-book seam in action:
Notice the @Transactional annotation on the class. Since remoting requests operate
outside the JSF life cycle, they aren't wrapped in Seam's global transaction. There-
fore, @WebRemote methods must declare transaction boundaries.
the problem is here:
@Transactional private void grant(List<Permission> permissions) { permissionManager.grantPermissions(permissions); } public void test() { TestClass tc=new TestClass(); tc.setIdent("mytestclassObject1"); Principal prrincipal = new SimplePrincipal("root"); Permission p1= new Permission(tc,"view",prrincipal); Permission p2= new Permission(tc,"test",prrincipal); List<Permission> permissions= new ArrayList<Permission>(); permissions.add(p1); permissions.add(p2); grant(permissions); }
@Transactional is present but it will be ignored becuase it's not called from outside.
if I change it to
@Transactional public void grant(List<Permission> permissions) { permissionManager.grantPermissions(permissions); }
and call it form an other seam componet it will work.
I don't know if the PermissionManager need an own transaction if yes, you can add @Transactional to the method:
public boolean grantPermission(Permission permission)
but I don't know if this has an effect if you call it form jsf.
So it's not a bug.
those who use the permissionManager in combinaiton with a @WebRemote method should not forget to care about the transaction by using the @Transactional annotation. So it was my mistake because I made a failure by using the @Transactional annotation.
Sorry @Shane :)
you can delete the bug in jira because it's not a bug or you can itegrate @Transactional in the JpaPermissionStore if you want, if there are no effects to jsf calls
greetz Marco
It's not a bug but it still needs to be addressed, either by documentation or possibly by making all remote calls transactional. So the issue is still relevant for tracking this.