Remove Method And JpaPermission Store

[matkapx]

Hi, i have really strange situation .
I actually don't know how to expalin it.

With jboss tools seam-gen i had created default Seam Entity named Company.
In the companyList.xhtml. i added a delete column to rich:datatable

<rich:column>
  <h:commandLink value="Delete" action="#{companyHome.delete}">
   <f:param name="brandId" value="#{item.id}"/>                               </h:commandLink>
</rich:column>

and this is companhHome class delete method

 @End@Transactional
    public void delete(){
         getInstance().setId(brandId);
         System.out.println("Supersil H Commadnlik "+getInstance().getName());
         statusMessages.add("Command Link delete method");
         super.remove();
    }

when i check the Eclipse console,

16:07:50,222 INFO  [STDOUT] Supersil H Commadnlik 11111
16:07:50,224 INFO  [STDOUT] Hibernate: 
    delete 
    from
        UserPermission 
    where
        target=?

16:07:50,227 INFO  [STDOUT] Hibernate: 
    delete 
    from
        Company 
    where
        id=? 
        and version=?

It deletes company from database.That is what i wanted but i don't understand why it tries to remove some data from UserPermission class. The Company Entity class does not have any relation with UserPermission(OneToMany , ManyToOne , OneToOne).
UserPermission only used for JPAPermissionStore and defined in components.xml file as below

<security:jpa-permission-store user-permission-class="org.domain.seamfinal.entity.UserPermission" />

I don't understand  why and what  it tries to delete from UserPermission Entity ?
This does only happen in companyList.xhtml.

If i go in to company.xhtml and invoke remove method there is no such delete query for UserPermission entity.

Hope someone faced this before, and found a solution.

[matkapx]

I created a blank project, and the same thing happened again.
I think it is the default behavior of Persistance Permission Resolver.
Is that correct ?

Well it seems like i should move to Drols with RuleBased Permission Resolver

[armahdi]

lol yeah exactly! thats what happened to my accountpermission class and some how the delete to some other object was making a delete call to AccountPermission table. which was very annoying.. I did it some other way i think.

I think i ran a delete sql native query to by pass the delete routine from the EntityHome.

but it sounds amazingly stupid how will it do that.

No one answers on these forums that much. looks like Seam 2 is already dead and no one is even bothering to resuscitate it.

Syed

[antibrumm.mfrey0.bluewin.ch]

I've never used the jpa permission store but i can imagine that this behavior is absolutely correct.

I would say it works like this (without having the knowledge):

You create an object and give permission to a user to edit it. Seam stores the object and also stores the objectpermission for the user. This you should see also in your logs.? If you now delete this object seam is clever enough and removes also the permission object. Hopefully, else you would most probably run into a foreignkey issue.

So i would say this is normal :)

[armahdi]

ok.. thanks for the reply... does seem like a possible answer. but what in case there is nothing related in the permission store related to THAT specific object..
What you say is plausible and seems like a good explanation but in my case at least there were no permissions for the object that I was trying to delete and may be thats the reason it was trying to delete it but in my case the accountpermission table was on a totally different schema where the user had no access to it would end up in an exception. So for me either I had to deal with an exception which I was not expecting or just remove it by passing the permission store and throwing a native query to the DB.

I had a similar topic opened on this forum some time back for the same issue, i dont think any body answered I guess, but the details are there.

What you say is may be true and is doing a smart delete as well but some time too much smartness gets in your way and it was deleting any reference in the account permission whether it exists or not.

there should be a cascading option also defined for THAT level i think. may be thats a good idea.

Thanks.
Syed