| Re: [eclipselink-dev] EM API Update -- unwrap(cls) |
|
I agree with providing unwrapping of the ServerSession but unwrapping
the connection is a much more complicated feature with quite a few
functional decisions to be made and evaluated (ie, what connection do
users really want (force transactional or the one eclipselink is
using), what side-effects are there to the chosen behaviour, etc..). I
recommend filing an enhancement request to unwrap the connection and
deferring to a later date. --Gordon Michael Keith wrote: Hi Darani, One obvious one would be a shortcut to obtain the ServerSession without having to name it in a property and go through the SessionManager. Another very useful use of "unwrap" would be to return the underlying javax.sql.Connection. A number of folks want to have access to the connection for very specialized cases. We would need to decide whether calling unwrap for a Connection would cause one to be allocated if it has not already been, and there are a few issues associated with that, etc. but it would be worth looking at. -Mike-----Original Message----- From: Darani Yallapragada [mailto:Darani.Yallapragada@xxxxxxx] Sent: Tuesday, December 16, 2008 3:04 PM To: Dev mailing list for Eclipse Persistence Services Subject: [eclipselink-dev] EM API Update -- unwrap(cls) Hello : I am currently working on implementing the following method : public <T> T unwrap(Class<T> cls); I can think of "UnitOfWork" and "JpaEntityManager" classes that should be unwrapped. Are there any other classes that should be unwrapped ? Thank You Regards Darani _______________________________________________ eclipselink-dev mailing list eclipselink-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/eclipselink-dev_______________________________________________ eclipselink-dev mailing list eclipselink-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/eclipselink-dev |