Re: [eclipselink-users] Getting context information in @PrePersist-Life

[Johannes Michler <orgler@xxxxxxxxx>]

Hi,

 

thanks for your reply. We're not using Spring, but exposing the methods to modify our entity-objects directly (using CXF running in a CXFNonSpringServlet servlet on jetty). Not sure how this maps requests to threads, but I'll give it a try to set the username to the ThreadLocal field at the begin of every call (When the entity-manger is created). Any idea how much performance-overhead is produced by using such a Thread-local variable?

 

I'll give your solution a try tomorrow, still hoping there is some little bit more elegant way of solving this prob :-) But It should work since from creating the entity manager over all modifications to the committing everything should be serial code in one thread and therefore the Thread-local variable should point to the correct username.

 

 

-Joe

2009/7/18 Tim Hollosy <hollosyt@xxxxxxxxx>

I know we're doing it now in our Spring MVC app. I just took a peek at
the code, here's how it's done. We use a combination of a @PrePerist
on an EntityListener that we attach to a @MappedSuperClass that has
our createdBy/createdOn's.

In spring, for our authentication, we use an interceptor, itintercepts
requests and auth's them. There we store the current user name in a
static string variable.

Now here's where it gets weird :) I didn't write this, a colleague
did, I don't really understand it but it's worked so far (not
production tested).

But the string variable is a ThreadLocal variable
http://java.sun.com/javase/6/docs/api/java/lang/ThreadLocal.html

So it's like private ThreadLocal<String> currentUser;

and the static getter in the interceptor looks like this:

 public static String getCurrentUserName() {
                       return currentUser.get();
               }

Then in our EntityListener we call the static getter to get the user name.

Hopefully that helps!

This way if you want to take advantage of the functionality, you
simply extend the MappedSuperclass, and you're done.

Let me know how that goes, also if anyone knows why this is incredibly
stupid or knows of some Spring IoC voodoo that would be more graceful,
I'm all ears :)

./tch

On Fri, Jul 17, 2009 at 10:32 AM, Johannes Michler<orgler@xxxxxxxxx> wrote:
> Hi,
>
> I'm writing some Data Access Layer using Eclipselink. My Database-Tables
> have columns for the creator, updator, createDate and updateDate of the
> table-entries. I'd like to update these entries on each persist/update. So
> far, I've found 3 ways of doing so:
>
> 1) in all my setter-methods in my Entity-Objects, du a setUpdated("now") and
> setUpdator(Username). This is quite ugly, because it needs my to write this
> code very often (10 tables=classes with 5 methods each approximately). And
> furthermore, the Entity-Objects don't know the current user, and this
> information cannot be retrieved in a static way. So I'd have to add a
> username-parameter to all my setter methods or do the setCreator() call
> after the "real-setter" call every time I call a setter.
>
> 2) manually set the data when calling entitymanager.commit(). It's easy to
> get the username there, but Cascade.Persist and other complex operations
> during the transaction make it quite heavy to find all newly created or
> changed objects.
>
> 3) Using @PrePersist and @PreUpdate. This would solve many problems, and the
> for the create/updates dates everything works fine. But how to get the
> current username there? the Entity-object doesn't know it of course, and
> static isn't an option. I'd need some kind of injection. Maybe I could set
> the username as a custom property of the entitymanager? But how could I get
> the current EntityManager in the PrePersist-Method?
>
> Or is there a way to attach a Persist-Listener to an entityManager? This
> would be perfect, but I found no such addPersistListener-Method on
> EntityManager :-(
>
>
> Any help would be great, cause Options 1 or 2 would cause me lots of work
> :-(
>
>
> -Johannes
>

> _______________________________________________
> eclipselink-users mailing list
> eclipselink-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
>
>
_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users