Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-users] Getting context information in @PrePersist-Lifecycle method

Hi,

just reporting back here in cause somebody is interested. The approach suggested by you is working fine. In my eyes, this is what I would assume a Thread-Local-Variable to work. So far I haven't experienced any problems, neither when using eclipselink locally nor when invoking it via a webservice hosted in a CXF-Servlet.

Nevertheless, if you'd remeber/get reported any drawbacks on this method, it would be nice if you could post them here, so I could think over my solution again.

-Joe

2009/7/20 Tim Hollosy <hollosyt@xxxxxxxxx>
Good luck,
I'll talk to the engy who came up with this method on Monday and see
if I can get some info on why it works/when it may not.

./tch



On Sun, Jul 19, 2009 at 7:34 AM, Johannes Michler<orgler@xxxxxxxxx> wrote:
> 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
>
>
> _______________________________________________
> 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


Back to the top