Re: Problem retrieving Timestamp from persistance
Hi, 1. In your table, what is the SQL type of the column corresponding to the Timestamp field ? 2. What is the run-time type of the returned by m.getObject() for the Timestamp field ? I assume MapMessage is your entity class ? And it has a Timestamp field that is persisted and retreived ? If you can make up an entity and a sample test that shows the string-like behaviour that would be helpful. Thanks, Dinkar
RE: Mapping a temporary table
Hi, Recently, some thing similar (actually more complex manipulation of SQL) was attempted to filter out soft-deleted records. Check out the thread [1]. [1] http://n2.nabble.com/Restrict-collection-items-td1690569.html#a1771060 -- View this message in context: http://n2.nabble.com/Mapping-a-temporary-table-tp2133474p2153452.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
RE: Mapping a temporary table
Hello, Is there any way (API; internal is fine..) to dynamically "intercept" a SQL query (AFTER it has been generated from JPQL) and modify it slightly (e.g. do a simple string replace on a table name by another one), just before it's sent down to the DB through the JDBC connection? I know about the JDBCListener, but that's a "one way street" - or is it not? There is probably something else? This would be a perfect solution for us for the use case described by Yann; and there is other use cases where this could be very handy. Thanks a ton, Michael -Original Message- From: Pinaki Poddar [mailto:ppod...@apache.org] Sent: mardi, 13. janvier 2009 05:21 To: users@openjpa.apache.org Subject: Re: Mapping a temporary table Consider Native Query that is dynamically constructed with temporary table name + appropriate ResultSetMapping that pours the projections of SQL query to your Entity class. -- View this message in context: http://n2.nabble.com/Mapping-a-temporary-table-tp2133474p2149510.html Sent from the OpenJPA Users mailing list archive at Nabble.com. This email and any files transmitted with it are CONFIDENTIAL and intended solely for the use of the individual or entity to which they are addressed. Any unauthorized copying, disclosure, or distribution of the material within this email is strictly forbidden. Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of Odyssey Financial Technologies SA unless otherwise specifically stated. An electronic message is not binding on its sender. Any message referring to a binding engagement must be confirmed in writing and duly signed. If you have received this email in error, please notify the sender immediately and delete the original.
Re: Entitymanager lookup using JNDI on webshpere
Devu,
Apologies. I should have clarified. You can do the lookup from your POJO as
long as the POJO method is called from a method of your EJB.
example:
MYEjb {
public void mymethodwhichneedsacachevalue() {
CachePOJO.getValue(key);
}
}
CachePOJO {
private void initialize() {
InitialContext ctx = new InitialContext();
Entitymanger mgr = ctx.lookup("java:comp/env/MyPCJndi");
//use mgr to load values from DB.
}
public String getValue(String key) {
// initialize is called if not initialized?
...
}
}
Question - does your cache store a static reference to the entity manager or
does it only get used once during initialization? If it is a one time
usage, this pattern should work fine. If you need to store the entity
manager, this pattern likely will not work. (There are various transaction
and thread safety issues to consider.) Alternately, you'll could look up
the entity manager upon each usage or switch to an application managed
design.
-Jeremy
On Tue, Jan 13, 2009 at 2:37 AM, devu213 wrote:
>
> Hi Kevin /Jeremy,
>
> Thanks for your replies.
>
> In the code that you mention, I would have to follow a pattern like this...
>
> MYEjb {
>
> EntityManager em = null;
>InitialContext ctx = new InitialContext();
>em = (EntityManager)ctx.lookup("java:comp/env/MyPCJndi");
>
> public void mymethodwhichneedsacachevalue() {
> Cache.getValue(key, manager); // the manager is passed to
> the cache. Don't want this
> }
>
> }
>
> CachePOJO {
>
>
> public String getValue(String key, EntityManager manager) {
> //singleton...uses manager to initialize from database for the
> first time
>}
>
> }
>
>
> What I really want is
>
>
> CachePOJO {
>
>private void initialize() {
> InitialContext ctx = new InitialContext();
> Entitymanger mgr = ctx.lookup(jndinameofmgr);
> //use mgr to load values from DB.
> }
>
> }
>
> Yes, the cache is accessed from an EJB, but I don't want to be passing the
> manager around. In fact, I have this pattern problem repeatedly because we
> have DAO classes that always now need to get initialized with the manager
> which is passed from the EJB class (session facade). I end up having to
> pass
> my entitymanager around.
>
>
> In a previous project with hibernate, I remember being able to get the
> sessions directly from the container using JNDI and they would be bound to
> a
> transaction if there was one existing. I want to be able to work with a
> similar pattern but stumble since the only place I am able to get a manager
> from right now is inside an EJB which I then have to pass around to lower
> layers.
>
> Thanks in advance.
>
> Devu.
>
> Jeremy, I don't have an option to go to WAS 7 right now, I will have to
> live
> with the fix packs. Will try out the method in Kevin's link.
>
>
>
> Kevin Sutter wrote:
> >
> > Devu213,
> > Besides Jeremy's references below, I want to be aware of WebSphere's
> > support
> > of OpenJPA. I started to cover this the WebSphere and Java Persistence
> > blog
> > [1], but to cover your specific situation... You are correct that the
> > version shipped with the WebSphere EJB3 Feature Pack was OpenJPA 1.0.
> > But,
> > we have created a service stream for this release in OpenJPA (1.0.x). If
> > any problems are discovered in the 1.0 release, then we can fix them in
> > OpenJPA 1.0.x. This updated version of OpenJPA will then get picked up
> > for
> > WebSphere iFixes and FixPacks. So, you are not "stuck" with OpenJPA 1.0.
> > It will get updated just like the rest of your WebSphere offering as
> > additional FixPacks are applied.
> >
> > WebSphere v7 shipped a version of 1.2 OpenJPA. This version will get
> > supported via the 1.2.x branch of OpenJPA. You could follow Jeremy's
> > references below to use this newer version of OpenJPA with the EJB3
> > Feature
> > Pack, but then you no longer have access to the WebSphere extensions that
> > sit on top of the OpenJPA binaries. It is an option though.
> >
> > Good luck,
> > Kevin
> >
> > [1]
> >
> http://webspherepersistence.blogspot.com/2008/09/support-for-openjpa.html
> >
> >
> > On Mon, Jan 12, 2009 at 10:42 AM, Jeremy Bauer
> > wrote:
> >
> >> Hi devu213,
> >> To use JNDI to lookup an EM or EMF in WebSphere app server you can
> define
> >> a
> >> class level annotation (or via XML in your ejb module deployment
> >> descriptor)
> >> on your session bean or servlet and use the "name" attribute to specify
> >> the
> >> JNDI name. For example:
> >>
> >> @Stateless
> >> @PersistenceContext(unitName="MyPC", name="MyPCJndi")
> >> public class JPABean implements JPALocal, JPARemote {
> >> ...
> >>@Resource SessionContext sessionCtx;
> >>
> >> public void beanMethod() {
> >>
> >> // 1) Lookup via comp/env namespace of the initial/current context
> >>EntityMan
Re: Entitymanager lookup using JNDI on webshpere
devu213,
Based on your recent reply, have you tried the global jndi lookup in your
Cache method? Along the lines of Jeremy's second example?
>> // or 2) Use direct lookup from the injected session ctx of the session
>> bean
>>em = (EntityManager)sessionCtx.lookup("MyPCJndi");
The use of the global jndi name is the spec'd access method. The use of the
component name space (java:comp/env) is actually a WebSphere extension
(other vendors may also provide this support, but it's not required by the
spec). So, if you stick with the global jndi name, it should work outside
of an EJB.
The one thing I am not positive on is whether the globally accessed EM will
automatically get linked up with the current transaction. But, let's do one
step at a time.
Thanks,
Kevin
On Tue, Jan 13, 2009 at 2:37 AM, devu213 wrote:
>
> Hi Kevin /Jeremy,
>
> Thanks for your replies.
>
> In the code that you mention, I would have to follow a pattern like this...
>
> MYEjb {
>
> EntityManager em = null;
>InitialContext ctx = new InitialContext();
>em = (EntityManager)ctx.lookup("java:comp/env/MyPCJndi");
>
> public void mymethodwhichneedsacachevalue() {
> Cache.getValue(key, manager); // the manager is passed to
> the cache. Don't want this
> }
>
> }
>
> CachePOJO {
>
> public String getValue(String key, EntityManager manager) {
> //singleton...uses manager to initialize from database for the
> first time
>}
>
> }
>
>
> What I really want is
>
>
> CachePOJO {
>
>private void initialize() {
> InitialContext ctx = new InitialContext();
> Entitymanger mgr = ctx.lookup(jndinameofmgr);
> //use mgr to load values from DB.
> }
>
> }
>
> Yes, the cache is accessed from an EJB, but I don't want to be passing the
> manager around. In fact, I have this pattern problem repeatedly because we
> have DAO classes that always now need to get initialized with the manager
> which is passed from the EJB class (session facade). I end up having to
> pass
> my entitymanager around.
>
>
> In a previous project with hibernate, I remember being able to get the
> sessions directly from the container using JNDI and they would be bound to
> a
> transaction if there was one existing. I want to be able to work with a
> similar pattern but stumble since the only place I am able to get a manager
> from right now is inside an EJB which I then have to pass around to lower
> layers.
>
> Thanks in advance.
>
> Devu.
>
> Jeremy, I don't have an option to go to WAS 7 right now, I will have to
> live
> with the fix packs. Will try out the method in Kevin's link.
>
>
>
> Kevin Sutter wrote:
> >
> > Devu213,
> > Besides Jeremy's references below, I want to be aware of WebSphere's
> > support
> > of OpenJPA. I started to cover this the WebSphere and Java Persistence
> > blog
> > [1], but to cover your specific situation... You are correct that the
> > version shipped with the WebSphere EJB3 Feature Pack was OpenJPA 1.0.
> > But,
> > we have created a service stream for this release in OpenJPA (1.0.x). If
> > any problems are discovered in the 1.0 release, then we can fix them in
> > OpenJPA 1.0.x. This updated version of OpenJPA will then get picked up
> > for
> > WebSphere iFixes and FixPacks. So, you are not "stuck" with OpenJPA 1.0.
> > It will get updated just like the rest of your WebSphere offering as
> > additional FixPacks are applied.
> >
> > WebSphere v7 shipped a version of 1.2 OpenJPA. This version will get
> > supported via the 1.2.x branch of OpenJPA. You could follow Jeremy's
> > references below to use this newer version of OpenJPA with the EJB3
> > Feature
> > Pack, but then you no longer have access to the WebSphere extensions that
> > sit on top of the OpenJPA binaries. It is an option though.
> >
> > Good luck,
> > Kevin
> >
> > [1]
> >
> http://webspherepersistence.blogspot.com/2008/09/support-for-openjpa.html
> >
> >
> > On Mon, Jan 12, 2009 at 10:42 AM, Jeremy Bauer
> > wrote:
> >
> >> Hi devu213,
> >> To use JNDI to lookup an EM or EMF in WebSphere app server you can
> define
> >> a
> >> class level annotation (or via XML in your ejb module deployment
> >> descriptor)
> >> on your session bean or servlet and use the "name" attribute to specify
> >> the
> >> JNDI name. For example:
> >>
> >> @Stateless
> >> @PersistenceContext(unitName="MyPC", name="MyPCJndi")
> >> public class JPABean implements JPALocal, JPARemote {
> >> ...
> >>@Resource SessionContext sessionCtx;
> >>
> >> public void beanMethod() {
> >>
> >> // 1) Lookup via comp/env namespace of the initial/current context
> >>EntityManager em = null;
> >>InitialContext ctx = new InitialContext();
> >>em = (EntityManager)ctx.lookup("java:comp/env/MyPCJndi");
> >>
> >> // or 2) Use direct lookup from the injected session ctx of the session
> >> bean
> >>em = (EntityManager)sessionCtx.lookup("MyPCJndi");
> >>
>
Re: Problem retrieving Timestamp from persistance
Hey, thanx for the comment, sorry it took me a while.. I can't paste my code, but I can explain better: I do: MapMessage m = TopicSubscriber.receive(); for each field in the message: Object value = m.getObject(SomeIndex); Now, when the fields are int, long, String etc. it work just fine, and the object returned are Integer, Long String... But, when the field type is Timestamp, the getObject() return String by default. The result is a ugly String which needs to be formatted to Date. The thing is I don't want to give up on the generic call to getObject(). The optimal thing for me was to be able to replace the default getObject() considering Date to return Date object. Is there a way to perform such thing? Dinkar Rao wrote: > > Since java.sql.Timestamp extends java.util.Date, a get() on the > Timestamp field should already return Date... > > ...unless I totally misunderstood your question. Can you paste your > entity definition and a simple test ? > > Thanks, > Dinkar > > -- View this message in context: http://n2.nabble.com/Problem-retrieving-Timestamp-from-persistance-tp2108549p2151359.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: Entitymanager lookup using JNDI on webshpere
Hi Kevin /Jeremy,
Thanks for your replies.
In the code that you mention, I would have to follow a pattern like this...
MYEjb {
EntityManager em = null;
InitialContext ctx = new InitialContext();
em = (EntityManager)ctx.lookup("java:comp/env/MyPCJndi");
public void mymethodwhichneedsacachevalue() {
Cache.getValue(key, manager); // the manager is passed to
the cache. Don't want this
}
}
CachePOJO {
public String getValue(String key, EntityManager manager) {
//singleton...uses manager to initialize from database for the
first time
}
}
What I really want is
CachePOJO {
private void initialize() {
InitialContext ctx = new InitialContext();
Entitymanger mgr = ctx.lookup(jndinameofmgr);
//use mgr to load values from DB.
}
}
Yes, the cache is accessed from an EJB, but I don't want to be passing the
manager around. In fact, I have this pattern problem repeatedly because we
have DAO classes that always now need to get initialized with the manager
which is passed from the EJB class (session facade). I end up having to pass
my entitymanager around.
In a previous project with hibernate, I remember being able to get the
sessions directly from the container using JNDI and they would be bound to a
transaction if there was one existing. I want to be able to work with a
similar pattern but stumble since the only place I am able to get a manager
from right now is inside an EJB which I then have to pass around to lower
layers.
Thanks in advance.
Devu.
Jeremy, I don't have an option to go to WAS 7 right now, I will have to live
with the fix packs. Will try out the method in Kevin's link.
Kevin Sutter wrote:
>
> Devu213,
> Besides Jeremy's references below, I want to be aware of WebSphere's
> support
> of OpenJPA. I started to cover this the WebSphere and Java Persistence
> blog
> [1], but to cover your specific situation... You are correct that the
> version shipped with the WebSphere EJB3 Feature Pack was OpenJPA 1.0.
> But,
> we have created a service stream for this release in OpenJPA (1.0.x). If
> any problems are discovered in the 1.0 release, then we can fix them in
> OpenJPA 1.0.x. This updated version of OpenJPA will then get picked up
> for
> WebSphere iFixes and FixPacks. So, you are not "stuck" with OpenJPA 1.0.
> It will get updated just like the rest of your WebSphere offering as
> additional FixPacks are applied.
>
> WebSphere v7 shipped a version of 1.2 OpenJPA. This version will get
> supported via the 1.2.x branch of OpenJPA. You could follow Jeremy's
> references below to use this newer version of OpenJPA with the EJB3
> Feature
> Pack, but then you no longer have access to the WebSphere extensions that
> sit on top of the OpenJPA binaries. It is an option though.
>
> Good luck,
> Kevin
>
> [1]
> http://webspherepersistence.blogspot.com/2008/09/support-for-openjpa.html
>
>
> On Mon, Jan 12, 2009 at 10:42 AM, Jeremy Bauer
> wrote:
>
>> Hi devu213,
>> To use JNDI to lookup an EM or EMF in WebSphere app server you can define
>> a
>> class level annotation (or via XML in your ejb module deployment
>> descriptor)
>> on your session bean or servlet and use the "name" attribute to specify
>> the
>> JNDI name. For example:
>>
>> @Stateless
>> @PersistenceContext(unitName="MyPC", name="MyPCJndi")
>> public class JPABean implements JPALocal, JPARemote {
>> ...
>>@Resource SessionContext sessionCtx;
>>
>> public void beanMethod() {
>>
>> // 1) Lookup via comp/env namespace of the initial/current context
>>EntityManager em = null;
>>InitialContext ctx = new InitialContext();
>>em = (EntityManager)ctx.lookup("java:comp/env/MyPCJndi");
>>
>> // or 2) Use direct lookup from the injected session ctx of the session
>> bean
>>em = (EntityManager)sessionCtx.lookup("MyPCJndi");
>>
>> }
>>
>> Looking up an EntityManagerFactory via @PersistenceUnit works similarly.
>>
>> Notice though, that lookup is via the ENC of the EJB. I don't know
>> how/if
>> global JNDI can be used to get a factory. (Anyone?) So, if you initialize
>> your POJO cache within the context of the EJB, the lookup will work. If
>> you
>> need to initialize the cache outside of a container,
>> Persistence.createEntityManagerFactory should work for you. I'd verify
>> that
>> all of your jars specified in your jar-file entry are available on the
>> classpath of your application. You may need to add the jars to the class
>> path entry in the manifest of your module.
>>
>> Here's an IBM infocenter document that explains how to configure an
>> alternate persistence provider[1]. The key items when using an alternate
>> version of OpenJPA is to make sure you've included all the necessary
>> OpenJPA
>> jars in your application or via shared library and the application
>> classloader is configured to load PARENT_LAST. This allows the OpenJPA
