users@glassfish.java.net

Re: Entity callbacks/listeners

From: Witold Szczerba <pljosh.mail_at_gmail.com>
Date: Tue, 6 Mar 2007 16:22:37 +0100

Here is my first bright idea how to fix that :)
I could add @Transient boolean tempUnlock field and check that field
together with "locked" in my @PrePersist callback, like this:

@PrePersist
private void checkLock() {
    if (locked && !tempUnlock)
        throw new IllegalStateException(this + " is locked. You may
not modify it.");
}

Now you must explicitly set tempUnlock = true if you want to modify
entity. That would guarantee that no accidental modifications takes
place...

What do you think about such a workaround? I didn't have possibility
to check that yet, I hope it works!

-Witold Szczerba

p.s.
I think, however, that it would be much better if methods annotated as
@PrePersist could take a new entity as a parameter, so there would be
a way to check more things without creating workarounds. Moreover I
think, and I will be insisting on that in future, to add an options
for entity listeners to have access into context, so I could check,
for example, if there user X can modify entity. With services it is
very easy to add new method and forget checking security settings.

2007/3/6, Witold Szczerba <pljosh.mail_at_gmail.com>:
> Hello,
> in my application, I would like some entity beans to be locked for
> changes if situation requires so. I have, for example, Proposal entity
> with field locked : boolean.
>
> I would like to guarantee that there is no possible way to modify that
> entity if it is locked, but there must be some way to unlock it.
>
> I was thinking, I could use @PrePersist callback event, but in that
> method I can only check current state, for example I could throw an
> exception if "locked" is true. But after applying that callback, there
> will be no possible way to unlock that entity, as I cannot check if
> "locked" new state is false...
>
> I was thinking about checking that in SessonBean, but that would be
> VERY easy to forget about that in some place (for example when adding
> new functionality to application in future) and that could cause data
> to become in inconsistent state :/
>
> What are your suggestions? Is there some way to use entity
> callbacks/listeners for my purpose?
>
> Witold Szczerba
>