Re: correct way to load persistent metadata at startup

[Pinaki Poddar]

Hi,
>   I am attempting to load all the persistent class metadata eagerly.

   OpenJPA provides several ways to load persistent metadata eagerly. The
suggested approaches assume that META-INF/persistence.xml has listed the
persistent classes.

1.  is arguably the
most straightforward approach, notwithstanding some comments on this thread
about this option that had stated otherwise. 

2. Create a dummy EntityManager with
EntityManagerFactory.createEntityManager(). Metadata initialization will
kick in that way too. 

 
  

Kevin Sutter wrote:
> 
> Hi Heather,
> Interesting use of the OpenJPA metadata processing.  Just from your brief
> description, I would be careful on depending on an implementation versus
> defined interfaces.  Even if we could get this initialization done earlier
> for you, unless there was some defined mechanism to force this (ie. the
> openjpa.InitializeEagerly property), I wouldn't count on it.  In this
> particular case, the metadata repository is meant for OpenJPA processing.
> 
> I know with OpenJPA the lines may not be crystal clear between public
> API's,
> provider SPI's, or internal classes.  Of course, since this is an
> open-source project, you are welcome to peruse the complete contents of
> the
> code base and see if a solution is doable or not.  I would just be careful
> on being too dependent on a specific implementation.
> 
> Kevin
> 
> On Fri, May 15, 2009 at 9:30 AM, Heather Sterling 
> wrote:
> 
>> Thanks Kevin.
>>
>> Our scenario is that we have added product-specific annotations to the
>> persistent classes. In particular, we have some annotations that we need
>> in
>> our perPersist entity listener to generate unique identifiers before the
>> object is persisted. We're currently initializing all of the metadata at
>> the
>> beginning. We essentially iterate through the persistent classes and
>> create
>> maps that hold this extra information. I guess it's possible for us to
>> lazily load this data in the entity listener if it hasn't been loaded for
>> a
>> particular class. I also looked to see if there was another hook we could
>> potentially use, but didn't see any that seemed to fit the problem.
>>
>>
>> Heather Sterling
>> Systems Management Development
>> Phone: 919-254-7163 T/L: 444-7163
>> Cell: 919-423-3143
>> Email: hst...@us.ibm.com
>>
>>
>> [image: Inactive hide details for Kevin Sutter ---05/12/2009 12:53:30
>> PM---Heather,]
>> Kevin Sutter ---05/12/2009 12:53:30 PM---Heather,
>>
>>
>>
>>
>> *Kevin Sutter *
>>
>> 05/12/2009 12:48 PM
>> Please respond to users
>>
>>
>>
>>  To: users@openjpa.apache.org
>>  cc:
>>  Subject: Re: correct way to load persistent metadata at startup
>>
>>
>> Heather,
>> Good question...  :-)  This topic has come up recently due to some
>> potential
>> locking issues (serialized access) when reading the metadata repository
>> in
>> a
>> multi-threaded environment.  At this point, there is not a clear cut
>> answer
>> for forcing the initialization of the metadata repository.  The code for
>> the
>> new openjpa.InitializeEagerly property was committed to trunk last August
>> (after the 1.2.0 release was created), but we've since determined that it
>> may not be complete for all cases.  You are welcome to try it out from
>> either the 1.3.x or trunk branches and see if it helps in your particular
>> situation.
>>
>> Let us know what you find out.  Also, can you explain your need for
>> getting
>> this data eagerly vs letting the lazy loading process play out?  Thanks!
>>
>> Kevin
>>
>>
>>
>> On Mon, May 11, 2009 at 2:40 PM, Heather Sterling 
>> wrote:
>>
>> >
>> >
>> > I am attempting to load all the persistent class metadata eagerly.  I
>> > realize this isn't great performance-wise, but I need to do it for the
>> > time-being.   I had wanted to call:
>> >
>> >ClassMetaData[] classMetaDatas =
>> > conf.getMetaDataRepositoryInstance().getMetaDatas();
>> >
>> > but realized the data was loaded lazily when nothing came back.  I
>> switched
>> > to using:);
>> >
>> > Collection c =
>> conf.getMetaDataRepositoryInstance().loadPersistentTypes(.
>> > true, null);
>> >
>> > which returned the classes to me, but getMetaDatas() still returned
>> > nothing.  Finally, I resorted to iterating through the class names,
>> which
>> > seemed to work.
>> >
>> >Set names = conf.getMetaDataRepositoryInstance
>> > ().getPersistentTypeNames(false, null);
>> >if (names != null) {
>> >for (Iterator it = names.iterator(); it.hasNext();) {
>> >String persistentClassname = (String)it.next();
>> >System.out.println("Pre-loading metadata for: " +
>> > persistentClassname);
>> >try {
>> >ClassMetaData cc =
>> conf.getMetaDataRepositoryInstance
>> > ().getMetaData(Class.forName(persistentClassname), null, true);
>> >} catch (ClassNotFoundException e) {
>> >// TODO A

Re: Database support

[Kevin Sutter]

Hi Fay,
Yes, good catch.  I was thinking of that one when I was putting the list
together.  At this point, I would put SolidDB in the "Not Currently Covered"
category.  Thanks.

Kevin

On Fri, May 15, 2009 at 4:19 PM, Fay Wang  wrote:

>
> Hi Kevin,
>
> What about SolidDB? The memory-based relational database?
>
> --- On Fri, 5/15/09, Kevin Sutter  wrote:
>
> > From: Kevin Sutter 
> > Subject: Re: Database support
> > To: users@openjpa.apache.org
> > Date: Friday, May 15, 2009, 2:09 PM
> > Okay, so I'm looking at our stated
> > database support [1].  From this chart, I
> > would divide up the databases into the following
> > categories.  The "Not
> > Currently Covered" category is where I would focus my
> > phishing efforts
> > first.  Any discussion?
> >
> > Covered Interest by members of OpenJPA Community
> > ===
> > o  Derby
> > o  DB2
> > o  Informix
> > o  Oracle
> > o  MS SQL Server ???
> > o  Sybase ???
> >
> >
> > Not Currently Covered Interest by members of OpenJPA
> > Community
> > =
> > o  MySQL
> > o  PostgreSQL
> > o  H2
> > o  HSQLDB (Hypersonic)
> > o  Firebird ???
> >
> >
> > Are these still required?
> > =
> > o  Borland Interbase
> > o  Borland JDataStore
> > o  Empress
> > o  Intersystems Cache
> > o  MS Access
> > o  MS Visual FoxPro
> > o  Pointbase
> >
> > Thanks,
> > Kevin
> >
> > [1]
> >
> http://openjpa.apache.org/builds/latest/docs/manual/manual.html#dbsupport
> >
> > On Thu, May 14, 2009 at 10:01 AM, David Beer <
> david.m.b...@googlemail.com>wrote:
> >
> > > Hi Kevin
> > >
> > > Some database vendors usually have some sort of
> > universal contact which
> > > might be the best way of going about it. Posting a one
> > of message to
> > > support forums might well be an idea that could work.
> > >
> > > David
> > >
> > > On Thu, 14 May 2009 08:46:03 -0500 Kevin Sutter
> > > 
> > wrote:
> > >
> > > > Hi David,
> > > >
> > > > On Wed, May 13, 2009 at 5:10 PM, David Beer
> > > > wrote:
> > > >
> > > > > Hi Kevin
> > > > >
> > > > > I currently use OpenJPA with the H2 database
> > for my embeded
> > > > > programs, and will be considering MySQL for
> > larger scale programs.
> > > > > I think that the more database vendors or
> > suppliers we can get
> > > > > links with the better for both sides. I am
> > happily using H2 with
> > > > > OpenJPA but there were some features I had
> > to ask about and how to
> > > > > work with OenJPA.
> > > > >
> > > > > So my point is that we need a way of getting
> > committers or users
> > > > > from both sides to help so we need a way of
> > maybe certifying a
> > > > > database version.
> > > >
> > > >
> > > > It sounds like we're on the same page.  The
> > tricky part is signing up
> > > > this help and support from these database vendors
> > and users groups.
> > > > Maybe I should just post to these vendor's user
> > forums and ask for
> > > > some support. Just go phishing...  :-)
> > > >
> > > > Kevin
> > > >
> > > >
> > > > >
> > > > >
> > > > > Jut my thoughts.
> > > > >
> > > > > David
> > > > >
> > > > > On Wed, 13 May 2009 16:36:53 -0500 Kevin
> > Sutter
> > > > > 
> > wrote:
> > > > >
> > > > > > Hi,
> > > > > > I'm trolling...  I'm looking for
> > ideas on how we can better
> > > > > > integrate with the various database
> > vendors.  Many of us
> > > > > > committers have our own "favorite"
> > databases due to our
> > > > > > employers' needs.  But, what about
> > the MySQL, or Postgres, or SQL
> > > > > > Server, or pick your favorite
> > databases?  I know we have had some
> > > > > > interest from these database vendors on
> > our users and dev forums,
> > > > > > but I'm looking for ways to get these
> > vendors more involved.
> > > > > > When they produce a new version of
> > their database, it would be
> > > > > > great to announce OpenJPA
> > support.  And, if they have new
> > > > > > features to take advantage of, that
> > would be even better.
> > > > > >
> > > > > > Everybody's development and tests teams
> > are limited.  I understand
> > > > > > that. But, I'm looking for ideas on how
> > we can work together to
> > > > > > accomplish this task.  I'm going
> > to cross post on both users and
> > > > > > dev forums to see if there any lurkers
> > that might have some ideas.
> > > > > >
> > > > > > Just to provide a real world
> > example...  I was just pinged about
> > > > > > MS SQL Server 2008 support.  Our
> > OpenJPA manual only documents SQL
> > > > > > Server 2005 support.  I don't have
> > experience with SQL Server.
> > > > > > So, it made me think how we could
> > improve this aspect of our
> > > > > > OpenJPA database support.
> > > > > >
> > > > > > Any thoughts?
> > > > > >
> > > > > > Kevin
> > > > >
> > > > >
> > >
> > >
> >
>
>
>
>

Re: Database support

[Fay Wang]

Hi Kevin,

What about SolidDB? The memory-based relational database?

--- On Fri, 5/15/09, Kevin Sutter  wrote:

> From: Kevin Sutter 
> Subject: Re: Database support
> To: users@openjpa.apache.org
> Date: Friday, May 15, 2009, 2:09 PM
> Okay, so I'm looking at our stated
> database support [1].  From this chart, I
> would divide up the databases into the following
> categories.  The "Not
> Currently Covered" category is where I would focus my
> phishing efforts
> first.  Any discussion?
> 
> Covered Interest by members of OpenJPA Community
> ===
> o  Derby
> o  DB2
> o  Informix
> o  Oracle
> o  MS SQL Server ???
> o  Sybase ???
> 
> 
> Not Currently Covered Interest by members of OpenJPA
> Community
> =
> o  MySQL
> o  PostgreSQL
> o  H2
> o  HSQLDB (Hypersonic)
> o  Firebird ???
> 
> 
> Are these still required?
> =
> o  Borland Interbase
> o  Borland JDataStore
> o  Empress
> o  Intersystems Cache
> o  MS Access
> o  MS Visual FoxPro
> o  Pointbase
> 
> Thanks,
> Kevin
> 
> [1]
> http://openjpa.apache.org/builds/latest/docs/manual/manual.html#dbsupport
> 
> On Thu, May 14, 2009 at 10:01 AM, David Beer 
> wrote:
> 
> > Hi Kevin
> >
> > Some database vendors usually have some sort of
> universal contact which
> > might be the best way of going about it. Posting a one
> of message to
> > support forums might well be an idea that could work.
> >
> > David
> >
> > On Thu, 14 May 2009 08:46:03 -0500 Kevin Sutter
> > 
> wrote:
> >
> > > Hi David,
> > >
> > > On Wed, May 13, 2009 at 5:10 PM, David Beer
> > > wrote:
> > >
> > > > Hi Kevin
> > > >
> > > > I currently use OpenJPA with the H2 database
> for my embeded
> > > > programs, and will be considering MySQL for
> larger scale programs.
> > > > I think that the more database vendors or
> suppliers we can get
> > > > links with the better for both sides. I am
> happily using H2 with
> > > > OpenJPA but there were some features I had
> to ask about and how to
> > > > work with OenJPA.
> > > >
> > > > So my point is that we need a way of getting
> committers or users
> > > > from both sides to help so we need a way of
> maybe certifying a
> > > > database version.
> > >
> > >
> > > It sounds like we're on the same page.  The
> tricky part is signing up
> > > this help and support from these database vendors
> and users groups.
> > > Maybe I should just post to these vendor's user
> forums and ask for
> > > some support. Just go phishing...  :-)
> > >
> > > Kevin
> > >
> > >
> > > >
> > > >
> > > > Jut my thoughts.
> > > >
> > > > David
> > > >
> > > > On Wed, 13 May 2009 16:36:53 -0500 Kevin
> Sutter
> > > > 
> wrote:
> > > >
> > > > > Hi,
> > > > > I'm trolling...  I'm looking for
> ideas on how we can better
> > > > > integrate with the various database
> vendors.  Many of us
> > > > > committers have our own "favorite"
> databases due to our
> > > > > employers' needs.  But, what about
> the MySQL, or Postgres, or SQL
> > > > > Server, or pick your favorite
> databases?  I know we have had some
> > > > > interest from these database vendors on
> our users and dev forums,
> > > > > but I'm looking for ways to get these
> vendors more involved.
> > > > > When they produce a new version of
> their database, it would be
> > > > > great to announce OpenJPA
> support.  And, if they have new
> > > > > features to take advantage of, that
> would be even better.
> > > > >
> > > > > Everybody's development and tests teams
> are limited.  I understand
> > > > > that. But, I'm looking for ideas on how
> we can work together to
> > > > > accomplish this task.  I'm going
> to cross post on both users and
> > > > > dev forums to see if there any lurkers
> that might have some ideas.
> > > > >
> > > > > Just to provide a real world
> example...  I was just pinged about
> > > > > MS SQL Server 2008 support.  Our
> OpenJPA manual only documents SQL
> > > > > Server 2005 support.  I don't have
> experience with SQL Server.
> > > > > So, it made me think how we could
> improve this aspect of our
> > > > > OpenJPA database support.
> > > > >
> > > > > Any thoughts?
> > > > >
> > > > > Kevin
> > > >
> > > >
> >
> >
> 

Re: correct way to load persistent metadata at startup

[Jeremy Bauer]

Heather,

Have you looked into creating a custom sequence generator[1]?  Within the
generator, the persistent class and/or fields could be interrogated for
annotations and you could generate a value based on them.  This is more of a
runtime vs. init-time solution, though.

Here's an example:

package generator;

import java.lang.reflect.AccessibleObject;

import org.apache.openjpa.jdbc.conf.JDBCConfiguration;
import org.apache.openjpa.jdbc.kernel.JDBCStore;
import org.apache.openjpa.jdbc.meta.ClassMapping;
import org.apache.openjpa.meta.FieldMetaData;

public class MyGenerator extends
org.apache.openjpa.jdbc.kernel.AbstractJDBCSeq
{
@Override
public JDBCConfiguration getConfiguration() {
return null;
}

@Override
protected Object nextInternal(JDBCStore arg0, ClassMapping arg1)
throws Exception {

FieldMetaData fmd = arg1.getFieldMapping("someField");
AccessibleObject fld = (AccessibleObject)fmd.getBackingMember();
MyAnnotation anno =
(MyAnnotation)fld.getAnnotation(MyAnnotation.class);
// Return the value of the annotation.  This will get persisted in
the DB column.
return anno.value();
}
}


@Entity
@SequenceGenerator(name="myGenerator",
sequenceName="generator.MyGenerator()")
public class GenValue {

@MyAnnotation("FieldValue")
@GeneratedValue(generator="myGenerator",
strategy=GenerationType.SEQUENCE)
public String someField;

...
}

[1]
http://openjpa.apache.org/builds/latest/docs/manual/ref_guide_sequence.html

-Jeremy

On Fri, May 15, 2009 at 2:06 PM, Kevin Sutter  wrote:

> Hi Heather,
> Interesting use of the OpenJPA metadata processing.  Just from your brief
> description, I would be careful on depending on an implementation versus
> defined interfaces.  Even if we could get this initialization done earlier
> for you, unless there was some defined mechanism to force this (ie. the
> openjpa.InitializeEagerly property), I wouldn't count on it.  In this
> particular case, the metadata repository is meant for OpenJPA processing.
>
> I know with OpenJPA the lines may not be crystal clear between public
> API's,
> provider SPI's, or internal classes.  Of course, since this is an
> open-source project, you are welcome to peruse the complete contents of the
> code base and see if a solution is doable or not.  I would just be careful
> on being too dependent on a specific implementation.
>
> Kevin
>
> On Fri, May 15, 2009 at 9:30 AM, Heather Sterling 
> wrote:
>
> > Thanks Kevin.
> >
> > Our scenario is that we have added product-specific annotations to the
> > persistent classes. In particular, we have some annotations that we need
> in
> > our perPersist entity listener to generate unique identifiers before the
> > object is persisted. We're currently initializing all of the metadata at
> the
> > beginning. We essentially iterate through the persistent classes and
> create
> > maps that hold this extra information. I guess it's possible for us to
> > lazily load this data in the entity listener if it hasn't been loaded for
> a
> > particular class. I also looked to see if there was another hook we could
> > potentially use, but didn't see any that seemed to fit the problem.
> >
> >
> > Heather Sterling
> > Systems Management Development
> > Phone: 919-254-7163 T/L: 444-7163
> > Cell: 919-423-3143
> > Email: hst...@us.ibm.com
> >
> >
> > [image: Inactive hide details for Kevin Sutter ---05/12/2009 12:53:30
> > PM---Heather,]
> > Kevin Sutter ---05/12/2009 12:53:30 PM---Heather,
> >
> >
> >
> >
> > *Kevin Sutter *
> >
> > 05/12/2009 12:48 PM
> > Please respond to users
> >
> >
> >
> >  To: users@openjpa.apache.org
> >  cc:
> >  Subject: Re: correct way to load persistent metadata at startup
> >
> >
> > Heather,
> > Good question...  :-)  This topic has come up recently due to some
> > potential
> > locking issues (serialized access) when reading the metadata repository
> in
> > a
> > multi-threaded environment.  At this point, there is not a clear cut
> answer
> > for forcing the initialization of the metadata repository.  The code for
> > the
> > new openjpa.InitializeEagerly property was committed to trunk last August
> > (after the 1.2.0 release was created), but we've since determined that it
> > may not be complete for all cases.  You are welcome to try it out from
> > either the 1.3.x or trunk branches and see if it helps in your particular
> > situation.
> >
> > Let us know what you find out.  Also, can you explain your need for
> getting
> > this data eagerly vs letting the lazy loading process play out?  Thanks!
> >
> > Kevin
> >
> >
> >
> > On Mon, May 11, 2009 at 2:40 PM, Heather Sterling 
> > wrote:
> >
> > >
> > >
> > > I am attempting to load all the persistent class metadata eagerly.  I
> > > realize this isn't great performance-wise, but I need to do it for the
> > > time-being.   I had wanted to call:
> > >
> > >ClassMetaData[] classMetaDatas =
> > > conf.getMe

Re: Database support

[Kevin Sutter]

Okay, so I'm looking at our stated database support [1].  From this chart, I
would divide up the databases into the following categories.  The "Not
Currently Covered" category is where I would focus my phishing efforts
first.  Any discussion?

Covered Interest by members of OpenJPA Community
===
o  Derby
o  DB2
o  Informix
o  Oracle
o  MS SQL Server ???
o  Sybase ???


Not Currently Covered Interest by members of OpenJPA Community
=
o  MySQL
o  PostgreSQL
o  H2
o  HSQLDB (Hypersonic)
o  Firebird ???


Are these still required?
=
o  Borland Interbase
o  Borland JDataStore
o  Empress
o  Intersystems Cache
o  MS Access
o  MS Visual FoxPro
o  Pointbase

Thanks,
Kevin

[1]
http://openjpa.apache.org/builds/latest/docs/manual/manual.html#dbsupport

On Thu, May 14, 2009 at 10:01 AM, David Beer wrote:

> Hi Kevin
>
> Some database vendors usually have some sort of universal contact which
> might be the best way of going about it. Posting a one of message to
> support forums might well be an idea that could work.
>
> David
>
> On Thu, 14 May 2009 08:46:03 -0500 Kevin Sutter
>  wrote:
>
> > Hi David,
> >
> > On Wed, May 13, 2009 at 5:10 PM, David Beer
> > wrote:
> >
> > > Hi Kevin
> > >
> > > I currently use OpenJPA with the H2 database for my embeded
> > > programs, and will be considering MySQL for larger scale programs.
> > > I think that the more database vendors or suppliers we can get
> > > links with the better for both sides. I am happily using H2 with
> > > OpenJPA but there were some features I had to ask about and how to
> > > work with OenJPA.
> > >
> > > So my point is that we need a way of getting committers or users
> > > from both sides to help so we need a way of maybe certifying a
> > > database version.
> >
> >
> > It sounds like we're on the same page.  The tricky part is signing up
> > this help and support from these database vendors and users groups.
> > Maybe I should just post to these vendor's user forums and ask for
> > some support. Just go phishing...  :-)
> >
> > Kevin
> >
> >
> > >
> > >
> > > Jut my thoughts.
> > >
> > > David
> > >
> > > On Wed, 13 May 2009 16:36:53 -0500 Kevin Sutter
> > >  wrote:
> > >
> > > > Hi,
> > > > I'm trolling...  I'm looking for ideas on how we can better
> > > > integrate with the various database vendors.  Many of us
> > > > committers have our own "favorite" databases due to our
> > > > employers' needs.  But, what about the MySQL, or Postgres, or SQL
> > > > Server, or pick your favorite databases?  I know we have had some
> > > > interest from these database vendors on our users and dev forums,
> > > > but I'm looking for ways to get these vendors more involved.
> > > > When they produce a new version of their database, it would be
> > > > great to announce OpenJPA support.  And, if they have new
> > > > features to take advantage of, that would be even better.
> > > >
> > > > Everybody's development and tests teams are limited.  I understand
> > > > that. But, I'm looking for ideas on how we can work together to
> > > > accomplish this task.  I'm going to cross post on both users and
> > > > dev forums to see if there any lurkers that might have some ideas.
> > > >
> > > > Just to provide a real world example...  I was just pinged about
> > > > MS SQL Server 2008 support.  Our OpenJPA manual only documents SQL
> > > > Server 2005 support.  I don't have experience with SQL Server.
> > > > So, it made me think how we could improve this aspect of our
> > > > OpenJPA database support.
> > > >
> > > > Any thoughts?
> > > >
> > > > Kevin
> > >
> > >
>
>

Re: How to encrypt DB password in persistence.xml

[Kevin Sutter]

Thanks for the insights, Donald.  And, thanks for posting this info to the
JIRA Issue (openjpa-1089) as well.

Kevin

On Fri, May 15, 2009 at 10:25 AM, Donald Woods  wrote:

> We have a similar feature in Apache Geronimo for our config.xml and
> deployment plans.  The only downside of adding this to OpenJPA, is we would
> then have to follow the ASF Cryptography release guidelines at -
>   http://www.apache.org/dev/crypto.html
> since we would be using encryption/decryption (even if provided by the
> JVM).  Not a biggie, but adds a few steps to the release process...
>
>
> -Donald
>
>
>
> Kevin Sutter wrote:
>
>> Hi Yu Wang,
>> Or, you could develop an answer for OpenJPA and contribute it back to the
>> project...  :-)  Providing an encryption capability for persistence.xml
>> password values would be a nice feature.  But, this would probably only
>> apply to our openjpa.* properties...
>>
>> In your particular case where you are passing in all of the parameters to
>> dbcp, I don't see how OpenJPA could help in this case.  The URL is just
>> passed through to dbcp, so any decryption of a password field would need
>> to
>> be provided by dbcp.
>>
>> I did a quick search on this topic and found a few hits related to
>> encrypting passwords used for dbcp.  One link [1] indicated that using
>> Tomcat 6.0 makes this a bit easier, but there were other instructions on
>> extending the BasicDataSource.  This link was specific to Tomcat's
>> server.xml, but the idea could probably be extended to the
>> persistence.xml.
>>
>> Let us know what you come up with.
>>
>> Thanks,
>> Kevin
>>
>> [1]
>>
>> http://stackoverflow.com/questions/129160/how-to-avoid-storing-passwords-in-the-clear-for-tomcats-server-xml-resource-defi
>>
>>
>>
>> On Fri, May 15, 2009 at 2:33 AM, wang yu  wrote:
>>
>>  Hi Kevin,
>>> Thank you. You had real good solutions but unfortunately neither of
>>> them is feasible for our project.
>>> We use Apache dbcp datasource to leverage DB connection pool and
>>> tomcat 5.5 as app server.
>>> Following is a fragment of our persistence.xml:
>>>   >> value="org.apache.commons.dbcp.BasicDataSource" />
>>>
>>>   >>
>>>  value="driverClassName=org.apache.derby.jdbc.ClientDriver,
>>> url=jdbc:derby://localhost:1527/TSAM;create=true, username=app,
>>> password=app, maxActive=30, maxWait=1,
>>> poolPreparedStatements=true" />
>>>
>>> How to encrypt password under  this situation? Or should I adopt
>>> alternative connection pool implementation to make password encryption
>>> easier?
>>>
>>> if no better solution, I guess I only have two choices
>>> 1. Give up apache dbcp.
>>> 2. Modify source code of apache dbcp.
>>>
>>> Regards,
>>> Yu Wang
>>>
>>>
>>>
>>>
>>> On Thu, May 14, 2009 at 10:54 PM, Kevin Sutter 
>>> wrote:
>>>
 Hi,
 JPA does not define this functionality.  You could pass in the password

>>> via
>>>
 the application instead of hard-coding it in a persistence.xml.  Or, if

>>> you
>>>
 are in an app server environment, you should use a jndi lookup of a
 datasource.  This would be the most secure.

 Kevin

 On Tue, May 12, 2009 at 4:31 AM, wang yu  wrote:

  As title.
>
> Regards,
> Yu Wang
>
>
>>

Re: correct way to load persistent metadata at startup

[Kevin Sutter]

Hi Heather,
Interesting use of the OpenJPA metadata processing.  Just from your brief
description, I would be careful on depending on an implementation versus
defined interfaces.  Even if we could get this initialization done earlier
for you, unless there was some defined mechanism to force this (ie. the
openjpa.InitializeEagerly property), I wouldn't count on it.  In this
particular case, the metadata repository is meant for OpenJPA processing.

I know with OpenJPA the lines may not be crystal clear between public API's,
provider SPI's, or internal classes.  Of course, since this is an
open-source project, you are welcome to peruse the complete contents of the
code base and see if a solution is doable or not.  I would just be careful
on being too dependent on a specific implementation.

Kevin

On Fri, May 15, 2009 at 9:30 AM, Heather Sterling  wrote:

> Thanks Kevin.
>
> Our scenario is that we have added product-specific annotations to the
> persistent classes. In particular, we have some annotations that we need in
> our perPersist entity listener to generate unique identifiers before the
> object is persisted. We're currently initializing all of the metadata at the
> beginning. We essentially iterate through the persistent classes and create
> maps that hold this extra information. I guess it's possible for us to
> lazily load this data in the entity listener if it hasn't been loaded for a
> particular class. I also looked to see if there was another hook we could
> potentially use, but didn't see any that seemed to fit the problem.
>
>
> Heather Sterling
> Systems Management Development
> Phone: 919-254-7163 T/L: 444-7163
> Cell: 919-423-3143
> Email: hst...@us.ibm.com
>
>
> [image: Inactive hide details for Kevin Sutter ---05/12/2009 12:53:30
> PM---Heather,]
> Kevin Sutter ---05/12/2009 12:53:30 PM---Heather,
>
>
>
>
> *Kevin Sutter *
>
> 05/12/2009 12:48 PM
> Please respond to users
>
>
>
>  To: users@openjpa.apache.org
>  cc:
>  Subject: Re: correct way to load persistent metadata at startup
>
>
> Heather,
> Good question...  :-)  This topic has come up recently due to some
> potential
> locking issues (serialized access) when reading the metadata repository in
> a
> multi-threaded environment.  At this point, there is not a clear cut answer
> for forcing the initialization of the metadata repository.  The code for
> the
> new openjpa.InitializeEagerly property was committed to trunk last August
> (after the 1.2.0 release was created), but we've since determined that it
> may not be complete for all cases.  You are welcome to try it out from
> either the 1.3.x or trunk branches and see if it helps in your particular
> situation.
>
> Let us know what you find out.  Also, can you explain your need for getting
> this data eagerly vs letting the lazy loading process play out?  Thanks!
>
> Kevin
>
>
>
> On Mon, May 11, 2009 at 2:40 PM, Heather Sterling 
> wrote:
>
> >
> >
> > I am attempting to load all the persistent class metadata eagerly.  I
> > realize this isn't great performance-wise, but I need to do it for the
> > time-being.   I had wanted to call:
> >
> >ClassMetaData[] classMetaDatas =
> > conf.getMetaDataRepositoryInstance().getMetaDatas();
> >
> > but realized the data was loaded lazily when nothing came back.  I
> switched
> > to using:);
> >
> > Collection c = conf.getMetaDataRepositoryInstance().loadPersistentTypes(.
> > true, null);
> >
> > which returned the classes to me, but getMetaDatas() still returned
> > nothing.  Finally, I resorted to iterating through the class names, which
> > seemed to work.
> >
> >Set names = conf.getMetaDataRepositoryInstance
> > ().getPersistentTypeNames(false, null);
> >if (names != null) {
> >for (Iterator it = names.iterator(); it.hasNext();) {
> >String persistentClassname = (String)it.next();
> >System.out.println("Pre-loading metadata for: " +
> > persistentClassname);
> >try {
> >ClassMetaData cc = conf.getMetaDataRepositoryInstance
> > ().getMetaData(Class.forName(persistentClassname), null, true);
> >} catch (ClassNotFoundException e) {
> >// TODO Auto-generated catch block
> >e.printStackTrace();
> >}
> >
> >}
> >}
> >
> > I found a link regarding a potential openjpa property called
> > openjpa.InitializeEagerly (
> > https://issues.apache.org/jira/browse/OPENJPA-620) but it was never
> > checked
> > into a release.
> >
> > Given all these options, what is the correct way to load the metadata on
> > startup?
> >
> >
> > Heather Sterling
> > Systems Management Development
> > Phone:  919-254-7163 T/L: 444-7163
> > Cell: 919-423-3143
> > Email: hst...@us.ibm.com
>

Re: How to encrypt DB password in persistence.xml

[Donald Woods]

We have a similar feature in Apache Geronimo for our config.xml and 
deployment plans.  The only downside of adding this to OpenJPA, is we 
would then have to follow the ASF Cryptography release guidelines at -

   http://www.apache.org/dev/crypto.html
since we would be using encryption/decryption (even if provided by the 
JVM).  Not a biggie, but adds a few steps to the release process...



-Donald


Kevin Sutter wrote:

Hi Yu Wang,
Or, you could develop an answer for OpenJPA and contribute it back to the
project...  :-)  Providing an encryption capability for persistence.xml
password values would be a nice feature.  But, this would probably only
apply to our openjpa.* properties...

In your particular case where you are passing in all of the parameters to
dbcp, I don't see how OpenJPA could help in this case.  The URL is just
passed through to dbcp, so any decryption of a password field would need to
be provided by dbcp.

I did a quick search on this topic and found a few hits related to
encrypting passwords used for dbcp.  One link [1] indicated that using
Tomcat 6.0 makes this a bit easier, but there were other instructions on
extending the BasicDataSource.  This link was specific to Tomcat's
server.xml, but the idea could probably be extended to the persistence.xml.

Let us know what you come up with.

Thanks,
Kevin

[1]
http://stackoverflow.com/questions/129160/how-to-avoid-storing-passwords-in-the-clear-for-tomcats-server-xml-resource-defi



On Fri, May 15, 2009 at 2:33 AM, wang yu  wrote:


Hi Kevin,
Thank you. You had real good solutions but unfortunately neither of
them is feasible for our project.
We use Apache dbcp datasource to leverage DB connection pool and
tomcat 5.5 as app server.
Following is a fragment of our persistence.xml:
   

   

How to encrypt password under  this situation? Or should I adopt
alternative connection pool implementation to make password encryption
easier?

if no better solution, I guess I only have two choices
1. Give up apache dbcp.
2. Modify source code of apache dbcp.

Regards,
Yu Wang




On Thu, May 14, 2009 at 10:54 PM, Kevin Sutter  wrote:

Hi,
JPA does not define this functionality.  You could pass in the password

via

the application instead of hard-coding it in a persistence.xml.  Or, if

you

are in an app server environment, you should use a jndi lookup of a
datasource.  This would be the most secure.

Kevin

On Tue, May 12, 2009 at 4:31 AM, wang yu  wrote:


As title.

Regards,
Yu Wang

Re: Creating nodes with parents

[Morten O. Hansen]

Hi again

Im still getting the same kind of error, here is some more code (maybe it's
not related to recursion?)

My nodes are created using:
tm.addNode("test1", "test1");
tm.addNode("test2", "test2", tm.getNodeIdFromPath("test1"));
tm.addNode("test3", "test3", tm.getNodeIdFromPath("test1.test2"));
tm.addNode("test4", "test4",
tm.getNodeIdFromPath("test1.test2.test3"));

And tm.addNode is:
@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
public long addNode(String name, String displayName, long parentId) {
Node node = new Node();
node.setName(name.toLowerCase());
node.setDisplayName(displayName);
node.setParent( getNode(parentId) );

em.persist(node);
em.flush();

return node.getId();
}

tm.getNodeIdFromPath works fine (it fetches the correct id).

Node.parent is now defined as:
@ManyToOne(fetch=FetchType.LAZY, cascade=CascadeType.ALL)
@JoinColumn(name="parent")
protected Node parent;

The problem here is, adding the three first nodes works correct, but test4
does not (tm.getNodeIdFromPath works on test1.test2.test3).

A snippet from the error log:
DEBUG - [openjpa.jdbc.SQL]  executing prepstmnt 15317735
SELECT t1.id, t1.nodeType, t1.displayName, t1.name, t1.courseCode,
t1.endDate, t1.startDate FROM NODE t0 INNER JOIN NODE t1 ON t0.parent =
t1.id WHERE t0.id = ? [params=(long) 23]
DEBUG - [openjpa.jdbc.SQL]  [0 ms] spent
DEBUG - [openjpa.jdbc.JDBC]  [0 ms] close
DEBUG - [OpenEJB] The bean instance business method encountered a system
exception: null

org.apache.openjpa.persistence.PersistenceException: null
at org.apache.openjpa.kernel.BrokerImpl.persist(BrokerImpl.java:2459)
at org.apache.openjpa.kernel.BrokerImpl.persist(BrokerImpl.java:2277)
at
org.apache.openjpa.kernel.DelegatingBroker.persist(DelegatingBroker.java:1021)
at
org.apache.openjpa.persistence.EntityManagerImpl.persist(EntityManagerImpl.java:645)
at
org.apache.openejb.persistence.JtaEntityManager.persist(JtaEntityManager.java:97)

This error does not occur when i try to only create 3 nodes. I thought this
was because of recursion depth, but now i'm thinking its not (the log
confirms that depth is -1).

Do I need to update my parent node when the get pointed to by a child?

I use openejb if that makes a differense (openjpa 1.1.0), and also use
inheritance (but that part seems to work fine). I have also added the
openjpa enhancer (the maven plugin had already enabled runtime enhancing).

Any tips would be greatly appreciated.

//Morten

On Fri, May 15, 2009 at 15:34, Morten O. Hansen  wrote:

> Ok, thank you. Hopefully i can get it to work :)
>
> //Morten
>
>
> On Fri, May 15, 2009 at 15:32,  wrote:
>
>> Hi,
>>
>> best, you have a look at the documentation:
>>
>>
>> http://people.apache.org/~mprudhom/openjpa/site/openjpa-project/manual/ref_guide_pc_enhance.html
>>
>> OpenJPA classes need to be enhanced to provide lazy fetching. Else there
>> will always been used eager fetching, which could be the cause of your
>> problem.
>>
>>  Original-Nachricht 
>> > Datum: Fri, 15 May 2009 15:26:43 +0200
>> > Von: "Morten O. Hansen" 
>> > An: users@openjpa.apache.org
>> > Betreff: Re: Creating nodes with parents
>>
>> > Hi
>> >
>> > Thank for your quick response :) Sorry for my ignorance, but what do you
>> > mean by enhancing the classes?
>> >
>> > //Morten
>> >
>> > On Fri, May 15, 2009 at 15:21,  wrote:
>> >
>> > > Hi,
>> > >
>> > > as far as I know, TopLink has a maximum fetching depth of 2 by default
>> > and
>> > > OpenJPA has an infinite fetching depth, which could lead to recursions
>> > in
>> > > the worst case if you use eager fetching.
>> > > I am wondering why this also happens with lazy fetching - did you
>> forget
>> > to
>> > > enhance your classes?
>> > >
>> > > You can set the maximum fetching depth in your persistence.xml by
>> > setting
>> > > the following property:
>> > >
>> > > 
>> > >
>> > > I hope this helps :)
>> > >
>> > >  Original-Nachricht 
>> > > > Datum: Fri, 15 May 2009 14:58:03 +0200
>> > > > Von: "Morten O. Hansen" 
>> > > > An: users@openjpa.apache.org
>> > > > Betreff: Creating nodes with parents
>> > >
>> > > > Hi all
>> > > >
>> > > > I'm trying to create a Node class, where every Node has a pointer to
>> a
>> > > > parent Node (or null if there is none).
>> > > >
>> > > > A simplified view of the Node-class looks like this:
>> > > >
>> > > > @Entity
>> > > > public class Node {
>> > > >   @Id protected long id;
>> > > >   @ManyToOne(fetch=LAZY)
>> > > >   protected Node parent;
>> > > >   protected String name;
>> > > >   protected String displayName;
>> > > >
>> > > > // setters / getters..
>> > > > }
>> > > >
>> > > > And this was working correctly in TopLink (I think they just do
>> > infinite
>> > > > recursion depth), but in OpenJPA i get so

Re: Inheritance: Subclasses are not recognised

[Jasmin Riemer]

Hi Mike,

yes, I have.
This was also my first thought about that problem ;)
Maybe other configurations in persistence.xml that may cause problems?










-Jasmin

 Original-Nachricht 
> Datum: Fri, 15 May 2009 09:25:54 -0500
> Von: Michael Dick 
> An: users@openjpa.apache.org
> Betreff: Re: Inheritance: Subclasses are not recognised

> Hi Jasmin,
> 
> Do you have all your entities listed in persistence.xml?
> 
> -mike
> 
> On Fri, May 15, 2009 at 7:08 AM, Jasmin Riemer 
> wrote:
> 
> > Hello everybody,
> >
> > currently, I am working with OpenJPA in the Spring framework and try to
> > implement the following:
> >
> > I inherit certain subclasses from a mainclass. All these classes should
> be
> > mapped to a single table, so I use InheritanceType.SINGLE_TABLE and add
> a
> > discriminator value to each subclass.
> >
> > Simplified, it looks like this:
> >
> > @Entity
> > @Inheritance(strategy=InheritanceType.SINGLE_TABLE)
> > @DiscriminatorColumn(name="doc_type",
> > discriminatorType=DiscriminatorType.STRING)
> > public abstract class Document {
> >
> > // ...
> >
> > }
> >
> > @Entity
> > @DiscriminatorValue(value="Magazine")
> > public class Magazine extends Document {
> >
> > // ...
> >
> > }
> >
> > @Entity
> > @DiscriminatorValue(value="Book")
> > public class Book extends Document {
> >
> > // ...
> >
> > }
> >
> > Unfortunately, I get the following error message when I try to load data
> > from the database:
> >
> > Exception in thread "main"
> > org.springframework.dao.InvalidDataAccessApiUsageE xception: Could not
> map
> > discriminator value "Book" to any known subclasses of the requested
> class
> > "project.entities.Document" (known discriminator values: [Document,
> > Magazine]).; nested exception is  user
> > error> org.apache.openjpa.persistence.ArgumentException: Could not map
> > discriminator value "Book" to any known subclasses of the requested
> class
> > "project.entities.Document" (known discriminator values: [Document,
> > Magazine]).
> >
> > It seems that there are only known the main class and the subclass
> > "Magazine", but there is a problem with "Book" (and some other classes
> > inherited from "Document").
> >
> > I do not have much experience with OpenJPA and Spring and thus I have no
> > clue how to solve this problem. Anybody out there who has an idea or
> maybe
> > had a similar problem?
> > Is there maybe something special I could have used accidentally for
> > "Magazine", but not for the other classes?
> > --
> > Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate +
> > Telefonanschluss für nur 17,95 Euro/mtl.!*
> > http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a
> >

-- 
Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss 
für nur 17,95 Euro/mtl.!* 
http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a

Re: correct way to load persistent metadata at startup

[Heather Sterling]

Thanks Kevin.

Our scenario is that we have added product-specific annotations to the
persistent classes.  In particular, we have some annotations that we need
in our perPersist entity listener to generate unique identifiers before the
object is persisted.  We're currently initializing all of the metadata at
the beginning.  We essentially iterate through the persistent classes and
create maps that hold this extra information.  I guess it's possible for us
to lazily load this data in the entity listener if it hasn't been loaded
for a particular class.  I also looked to see if there was another hook we
could potentially use, but didn't see any that seemed to fit the problem.

Heather Sterling
Systems Management Development
Phone:  919-254-7163 T/L: 444-7163
Cell: 919-423-3143
Email: hst...@us.ibm.com



|-+>
| |   Kevin Sutter |
| | |
| ||
| |   05/12/2009 12:48 |
| |   PM   |
| |   Please respond to|
| |   users|
|-+>
  
>--|
  | 
 |
  |   To:   users@openjpa.apache.org
 |
  |   cc:   
 |
  |   Subject:  Re: correct way to load persistent metadata at startup  
 |
  
>--|




Heather,
Good question...  :-)  This topic has come up recently due to some
potential
locking issues (serialized access) when reading the metadata repository in
a
multi-threaded environment.  At this point, there is not a clear cut answer
for forcing the initialization of the metadata repository.  The code for
the
new openjpa.InitializeEagerly property was committed to trunk last August
(after the 1.2.0 release was created), but we've since determined that it
may not be complete for all cases.  You are welcome to try it out from
either the 1.3.x or trunk branches and see if it helps in your particular
situation.

Let us know what you find out.  Also, can you explain your need for getting
this data eagerly vs letting the lazy loading process play out?  Thanks!

Kevin



On Mon, May 11, 2009 at 2:40 PM, Heather Sterling 
wrote:

>
>
> I am attempting to load all the persistent class metadata eagerly.  I
> realize this isn't great performance-wise, but I need to do it for the
> time-being.   I had wanted to call:
>
>ClassMetaData[] classMetaDatas =
> conf.getMetaDataRepositoryInstance().getMetaDatas();
>
> but realized the data was loaded lazily when nothing came back.  I
switched
> to using:);
>
> Collection c = conf.getMetaDataRepositoryInstance().loadPersistentTypes(.
> true, null);
>
> which returned the classes to me, but getMetaDatas() still returned
> nothing.  Finally, I resorted to iterating through the class names, which
> seemed to work.
>
>Set names = conf.getMetaDataRepositoryInstance
> ().getPersistentTypeNames(false, null);
>if (names != null) {
>for (Iterator it = names.iterator(); it.hasNext();) {
>String persistentClassname = (String)it.next();
>System.out.println("Pre-loading metadata for: " +
> persistentClassname);
>try {
>ClassMetaData cc = conf.getMetaDataRepositoryInstance
> ().getMetaData(Class.forName(persistentClassname), null, true);
>} catch (ClassNotFoundException e) {
>// TODO Auto-generated catch block
>e.printStackTrace();
>}
>
>}
>}
>
> I found a link regarding a potential openjpa property called
> openjpa.InitializeEagerly (
> https://issues.apache.org/jira/browse/OPENJPA-620) but it was never
> checked
> into a release.
>
> Given all these options, what is the correct way to load the metadata on
> startup?
>
>
> Heather Sterling
> Systems Management Development
> Phone:  919-254-7163 T/L: 444-7163
> Cell: 919-423-3143
> Email: hst...@us.ibm.com

Re: Inheritance: Subclasses are not recognised

[Michael Dick]

Hi Jasmin,

Do you have all your entities listed in persistence.xml?

-mike

On Fri, May 15, 2009 at 7:08 AM, Jasmin Riemer  wrote:

> Hello everybody,
>
> currently, I am working with OpenJPA in the Spring framework and try to
> implement the following:
>
> I inherit certain subclasses from a mainclass. All these classes should be
> mapped to a single table, so I use InheritanceType.SINGLE_TABLE and add a
> discriminator value to each subclass.
>
> Simplified, it looks like this:
>
> @Entity
> @Inheritance(strategy=InheritanceType.SINGLE_TABLE)
> @DiscriminatorColumn(name="doc_type",
> discriminatorType=DiscriminatorType.STRING)
> public abstract class Document {
>
> // ...
>
> }
>
> @Entity
> @DiscriminatorValue(value="Magazine")
> public class Magazine extends Document {
>
> // ...
>
> }
>
> @Entity
> @DiscriminatorValue(value="Book")
> public class Book extends Document {
>
> // ...
>
> }
>
> Unfortunately, I get the following error message when I try to load data
> from the database:
>
> Exception in thread "main"
> org.springframework.dao.InvalidDataAccessApiUsageE xception: Could not map
> discriminator value "Book" to any known subclasses of the requested class
> "project.entities.Document" (known discriminator values: [Document,
> Magazine]).; nested exception is  error> org.apache.openjpa.persistence.ArgumentException: Could not map
> discriminator value "Book" to any known subclasses of the requested class
> "project.entities.Document" (known discriminator values: [Document,
> Magazine]).
>
> It seems that there are only known the main class and the subclass
> "Magazine", but there is a problem with "Book" (and some other classes
> inherited from "Document").
>
> I do not have much experience with OpenJPA and Spring and thus I have no
> clue how to solve this problem. Anybody out there who has an idea or maybe
> had a similar problem?
> Is there maybe something special I could have used accidentally for
> "Magazine", but not for the other classes?
> --
> Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate +
> Telefonanschluss für nur 17,95 Euro/mtl.!*
> http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a
>

Re: How to encrypt DB password in persistence.xml

[Kevin Sutter]

Hi Yu Wang,
Or, you could develop an answer for OpenJPA and contribute it back to the
project...  :-)  Providing an encryption capability for persistence.xml
password values would be a nice feature.  But, this would probably only
apply to our openjpa.* properties...

In your particular case where you are passing in all of the parameters to
dbcp, I don't see how OpenJPA could help in this case.  The URL is just
passed through to dbcp, so any decryption of a password field would need to
be provided by dbcp.

I did a quick search on this topic and found a few hits related to
encrypting passwords used for dbcp.  One link [1] indicated that using
Tomcat 6.0 makes this a bit easier, but there were other instructions on
extending the BasicDataSource.  This link was specific to Tomcat's
server.xml, but the idea could probably be extended to the persistence.xml.

Let us know what you come up with.

Thanks,
Kevin

[1]
http://stackoverflow.com/questions/129160/how-to-avoid-storing-passwords-in-the-clear-for-tomcats-server-xml-resource-defi



On Fri, May 15, 2009 at 2:33 AM, wang yu  wrote:

> Hi Kevin,
> Thank you. You had real good solutions but unfortunately neither of
> them is feasible for our project.
> We use Apache dbcp datasource to leverage DB connection pool and
> tomcat 5.5 as app server.
> Following is a fragment of our persistence.xml:
> value="org.apache.commons.dbcp.BasicDataSource" />
>
>
>  value="driverClassName=org.apache.derby.jdbc.ClientDriver,
> url=jdbc:derby://localhost:1527/TSAM;create=true, username=app,
> password=app, maxActive=30, maxWait=1,
> poolPreparedStatements=true" />
>
> How to encrypt password under  this situation? Or should I adopt
> alternative connection pool implementation to make password encryption
> easier?
>
> if no better solution, I guess I only have two choices
> 1. Give up apache dbcp.
> 2. Modify source code of apache dbcp.
>
> Regards,
> Yu Wang
>
>
>
>
> On Thu, May 14, 2009 at 10:54 PM, Kevin Sutter  wrote:
> > Hi,
> > JPA does not define this functionality.  You could pass in the password
> via
> > the application instead of hard-coding it in a persistence.xml.  Or, if
> you
> > are in an app server environment, you should use a jndi lookup of a
> > datasource.  This would be the most secure.
> >
> > Kevin
> >
> > On Tue, May 12, 2009 at 4:31 AM, wang yu  wrote:
> >
> >> As title.
> >>
> >> Regards,
> >> Yu Wang
> >>
> >
>

Re: Creating nodes with parents

[Morten O. Hansen]

Ok, thank you. Hopefully i can get it to work :)

//Morten

On Fri, May 15, 2009 at 15:32,  wrote:

> Hi,
>
> best, you have a look at the documentation:
>
>
> http://people.apache.org/~mprudhom/openjpa/site/openjpa-project/manual/ref_guide_pc_enhance.html
>
> OpenJPA classes need to be enhanced to provide lazy fetching. Else there
> will always been used eager fetching, which could be the cause of your
> problem.
>
>  Original-Nachricht 
> > Datum: Fri, 15 May 2009 15:26:43 +0200
> > Von: "Morten O. Hansen" 
> > An: users@openjpa.apache.org
> > Betreff: Re: Creating nodes with parents
>
> > Hi
> >
> > Thank for your quick response :) Sorry for my ignorance, but what do you
> > mean by enhancing the classes?
> >
> > //Morten
> >
> > On Fri, May 15, 2009 at 15:21,  wrote:
> >
> > > Hi,
> > >
> > > as far as I know, TopLink has a maximum fetching depth of 2 by default
> > and
> > > OpenJPA has an infinite fetching depth, which could lead to recursions
> > in
> > > the worst case if you use eager fetching.
> > > I am wondering why this also happens with lazy fetching - did you
> forget
> > to
> > > enhance your classes?
> > >
> > > You can set the maximum fetching depth in your persistence.xml by
> > setting
> > > the following property:
> > >
> > > 
> > >
> > > I hope this helps :)
> > >
> > >  Original-Nachricht 
> > > > Datum: Fri, 15 May 2009 14:58:03 +0200
> > > > Von: "Morten O. Hansen" 
> > > > An: users@openjpa.apache.org
> > > > Betreff: Creating nodes with parents
> > >
> > > > Hi all
> > > >
> > > > I'm trying to create a Node class, where every Node has a pointer to
> a
> > > > parent Node (or null if there is none).
> > > >
> > > > A simplified view of the Node-class looks like this:
> > > >
> > > > @Entity
> > > > public class Node {
> > > >   @Id protected long id;
> > > >   @ManyToOne(fetch=LAZY)
> > > >   protected Node parent;
> > > >   protected String name;
> > > >   protected String displayName;
> > > >
> > > > // setters / getters..
> > > > }
> > > >
> > > > And this was working correctly in TopLink (I think they just do
> > infinite
> > > > recursion depth), but in OpenJPA i get something that looks like
> > > recursion
> > > > errors.
> > > >
> > > > Is there a better way of doing this? I have implemented a hack just
> > using
> > > > long parentId instead, but that kinda sucks when you are deleting and
> > > > updating nodes.
> > > >
> > > > I know there is something called FetchGroups in OpenJPA, but i
> > couldn't
> > > > really get them to work and I want to have entities that hopefully
> > isn't
> > > > tied down to OpenJPA.
> > > >
> > > > --
> > > > Morten
> > >
> > > --
> > > Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate +
> > > Telefonanschluss für nur 17,95 Euro/mtl.!*
> > > http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a
> > >
>
> --
> Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate +
> Telefonanschluss für nur 17,95 Euro/mtl.!*
> http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a
>

Re: Creating nodes with parents

[Naomi-san]

Hi,

best, you have a look at the documentation:

http://people.apache.org/~mprudhom/openjpa/site/openjpa-project/manual/ref_guide_pc_enhance.html

OpenJPA classes need to be enhanced to provide lazy fetching. Else there will 
always been used eager fetching, which could be the cause of your problem.

 Original-Nachricht 
> Datum: Fri, 15 May 2009 15:26:43 +0200
> Von: "Morten O. Hansen" 
> An: users@openjpa.apache.org
> Betreff: Re: Creating nodes with parents

> Hi
> 
> Thank for your quick response :) Sorry for my ignorance, but what do you
> mean by enhancing the classes?
> 
> //Morten
> 
> On Fri, May 15, 2009 at 15:21,  wrote:
> 
> > Hi,
> >
> > as far as I know, TopLink has a maximum fetching depth of 2 by default
> and
> > OpenJPA has an infinite fetching depth, which could lead to recursions
> in
> > the worst case if you use eager fetching.
> > I am wondering why this also happens with lazy fetching - did you forget
> to
> > enhance your classes?
> >
> > You can set the maximum fetching depth in your persistence.xml by
> setting
> > the following property:
> >
> > 
> >
> > I hope this helps :)
> >
> >  Original-Nachricht 
> > > Datum: Fri, 15 May 2009 14:58:03 +0200
> > > Von: "Morten O. Hansen" 
> > > An: users@openjpa.apache.org
> > > Betreff: Creating nodes with parents
> >
> > > Hi all
> > >
> > > I'm trying to create a Node class, where every Node has a pointer to a
> > > parent Node (or null if there is none).
> > >
> > > A simplified view of the Node-class looks like this:
> > >
> > > @Entity
> > > public class Node {
> > >   @Id protected long id;
> > >   @ManyToOne(fetch=LAZY)
> > >   protected Node parent;
> > >   protected String name;
> > >   protected String displayName;
> > >
> > > // setters / getters..
> > > }
> > >
> > > And this was working correctly in TopLink (I think they just do
> infinite
> > > recursion depth), but in OpenJPA i get something that looks like
> > recursion
> > > errors.
> > >
> > > Is there a better way of doing this? I have implemented a hack just
> using
> > > long parentId instead, but that kinda sucks when you are deleting and
> > > updating nodes.
> > >
> > > I know there is something called FetchGroups in OpenJPA, but i
> couldn't
> > > really get them to work and I want to have entities that hopefully
> isn't
> > > tied down to OpenJPA.
> > >
> > > --
> > > Morten
> >
> > --
> > Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate +
> > Telefonanschluss für nur 17,95 Euro/mtl.!*
> > http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a
> >

-- 
Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss 
für nur 17,95 Euro/mtl.!* 
http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a

Re: Creating nodes with parents

[Morten O. Hansen]

Hi

Thank for your quick response :) Sorry for my ignorance, but what do you
mean by enhancing the classes?

//Morten

On Fri, May 15, 2009 at 15:21,  wrote:

> Hi,
>
> as far as I know, TopLink has a maximum fetching depth of 2 by default and
> OpenJPA has an infinite fetching depth, which could lead to recursions in
> the worst case if you use eager fetching.
> I am wondering why this also happens with lazy fetching - did you forget to
> enhance your classes?
>
> You can set the maximum fetching depth in your persistence.xml by setting
> the following property:
>
> 
>
> I hope this helps :)
>
>  Original-Nachricht 
> > Datum: Fri, 15 May 2009 14:58:03 +0200
> > Von: "Morten O. Hansen" 
> > An: users@openjpa.apache.org
> > Betreff: Creating nodes with parents
>
> > Hi all
> >
> > I'm trying to create a Node class, where every Node has a pointer to a
> > parent Node (or null if there is none).
> >
> > A simplified view of the Node-class looks like this:
> >
> > @Entity
> > public class Node {
> >   @Id protected long id;
> >   @ManyToOne(fetch=LAZY)
> >   protected Node parent;
> >   protected String name;
> >   protected String displayName;
> >
> > // setters / getters..
> > }
> >
> > And this was working correctly in TopLink (I think they just do infinite
> > recursion depth), but in OpenJPA i get something that looks like
> recursion
> > errors.
> >
> > Is there a better way of doing this? I have implemented a hack just using
> > long parentId instead, but that kinda sucks when you are deleting and
> > updating nodes.
> >
> > I know there is something called FetchGroups in OpenJPA, but i couldn't
> > really get them to work and I want to have entities that hopefully isn't
> > tied down to OpenJPA.
> >
> > --
> > Morten
>
> --
> Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate +
> Telefonanschluss für nur 17,95 Euro/mtl.!*
> http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a
>

Re: Creating nodes with parents

[Naomi-san]

Hi,

as far as I know, TopLink has a maximum fetching depth of 2 by default and 
OpenJPA has an infinite fetching depth, which could lead to recursions in the 
worst case if you use eager fetching.
I am wondering why this also happens with lazy fetching - did you forget to 
enhance your classes?

You can set the maximum fetching depth in your persistence.xml by setting the 
following property:



I hope this helps :)

 Original-Nachricht 
> Datum: Fri, 15 May 2009 14:58:03 +0200
> Von: "Morten O. Hansen" 
> An: users@openjpa.apache.org
> Betreff: Creating nodes with parents

> Hi all
> 
> I'm trying to create a Node class, where every Node has a pointer to a
> parent Node (or null if there is none).
> 
> A simplified view of the Node-class looks like this:
> 
> @Entity
> public class Node {
>   @Id protected long id;
>   @ManyToOne(fetch=LAZY)
>   protected Node parent;
>   protected String name;
>   protected String displayName;
> 
> // setters / getters..
> }
> 
> And this was working correctly in TopLink (I think they just do infinite
> recursion depth), but in OpenJPA i get something that looks like recursion
> errors.
> 
> Is there a better way of doing this? I have implemented a hack just using
> long parentId instead, but that kinda sucks when you are deleting and
> updating nodes.
> 
> I know there is something called FetchGroups in OpenJPA, but i couldn't
> really get them to work and I want to have entities that hopefully isn't
> tied down to OpenJPA.
> 
> --
> Morten

-- 
Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss 
für nur 17,95 Euro/mtl.!* 
http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a

Creating nodes with parents

[Morten O. Hansen]

Hi all

I'm trying to create a Node class, where every Node has a pointer to a
parent Node (or null if there is none).

A simplified view of the Node-class looks like this:

@Entity
public class Node {
  @Id protected long id;
  @ManyToOne(fetch=LAZY)
  protected Node parent;
  protected String name;
  protected String displayName;

// setters / getters..
}

And this was working correctly in TopLink (I think they just do infinite
recursion depth), but in OpenJPA i get something that looks like recursion
errors.

Is there a better way of doing this? I have implemented a hack just using
long parentId instead, but that kinda sucks when you are deleting and
updating nodes.

I know there is something called FetchGroups in OpenJPA, but i couldn't
really get them to work and I want to have entities that hopefully isn't
tied down to OpenJPA.

--
Morten

Inheritance: Subclasses are not recognised

[Jasmin Riemer]

Hello everybody,

currently, I am working with OpenJPA in the Spring framework and try to 
implement the following:

I inherit certain subclasses from a mainclass. All these classes should be 
mapped to a single table, so I use InheritanceType.SINGLE_TABLE and add a 
discriminator value to each subclass.

Simplified, it looks like this:

@Entity
@Inheritance(strategy=InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn(name="doc_type", 
discriminatorType=DiscriminatorType.STRING)
public abstract class Document {
 
// ...
 
}
 
@Entity
@DiscriminatorValue(value="Magazine")
public class Magazine extends Document {
 
// ...
 
}
 
@Entity
@DiscriminatorValue(value="Book")
public class Book extends Document {
 
// ...
 
}

Unfortunately, I get the following error message when I try to load data from 
the database: 

Exception in thread "main" org.springframework.dao.InvalidDataAccessApiUsageE 
xception: Could not map discriminator value "Book" to any known subclasses of 
the requested class "project.entities.Document" (known discriminator values: 
[Document, Magazine]).; nested exception is  org.apache.openjpa.persistence.ArgumentException: Could 
not map discriminator value "Book" to any known subclasses of the requested 
class "project.entities.Document" (known discriminator values: [Document, 
Magazine]).

It seems that there are only known the main class and the subclass "Magazine", 
but there is a problem with "Book" (and some other classes inherited from 
"Document").

I do not have much experience with OpenJPA and Spring and thus I have no clue 
how to solve this problem. Anybody out there who has an idea or maybe had a 
similar problem?
Is there maybe something special I could have used accidentally for "Magazine", 
but not for the other classes?
-- 
Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss 
für nur 17,95 Euro/mtl.!* 
http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a

Re: OpenJPA for Content Servers

[Michael Dick]

Hi Sriram,

It largely depends on how you communicate with docbase. JPA (typically)
interacts with JDBC, if there's a JDBC interface to the docbase you're using
then it will be fairly straightforward to use a JPA provider to do the
interactions.

If there isn't a JDBC driver for docbase then it's more difficult. OpenJPA
supports different back ends, but you'd have to write a fair bit of code to
talk to docbase's interface.

hope this helps,
-mike

On Thu, May 14, 2009 at 5:26 PM, shriram  wrote:

> Kevin,
>
> Actually this is how it works
>
> client ==>docbase(Content Server) ===> database.
>(DFC-libraries)
>
> DFC==>Documentum Foundation Classes.
>
> If we are using a docbase from Documentum , is it possible for the client
> to connect with docbase using JPA.
>
> like
>
> client ===>JPA===>docbase==>database
>
> docbase just stores meta data, whereas the actual data is still stored in
> database.
>
> Thanks
> sriram
>
>
>
>
>
>
> 
> From: Kevin Sutter 
> To: users@openjpa.apache.org
> Sent: Thursday, May 14, 2009 4:53:38 PM
> Subject: Re: OpenJPA for Content Servers
>
> Sure.  Most Content Servers still require some type of database to
> persistently store the "content", right?  So, the implementation of a
> Content Server could easily use Entities to define their data model and use
> generic JPA constructs to persist the data.  Independent from any
> particular
> database implementation (ie. not dependent on specific JDBC or SQL
> dialects).  Sounds like a good fit, from my personal perspective.  :-)
>
> Kevin
>
> On Thu, May 14, 2009 at 12:14 PM, shriram  wrote:
>
> > Hi,
> >
> > I work for a Documentum Based product development company. Is there any
> way
> > OpenJPA applied for Content Servers.
> >
> > Thanks
> > sriram
> >
> >
> >
> >
>
>
>
>
>

Re: How to encrypt DB password in persistence.xml

[wang yu]

Hi Kevin,
Thank you. You had real good solutions but unfortunately neither of
them is feasible for our project.
We use Apache dbcp datasource to leverage DB connection pool and
tomcat 5.5 as app server.
Following is a fragment of our persistence.xml:




How to encrypt password under  this situation? Or should I adopt
alternative connection pool implementation to make password encryption
easier?

if no better solution, I guess I only have two choices
1. Give up apache dbcp.
2. Modify source code of apache dbcp.

Regards,
Yu Wang




On Thu, May 14, 2009 at 10:54 PM, Kevin Sutter  wrote:
> Hi,
> JPA does not define this functionality.  You could pass in the password via
> the application instead of hard-coding it in a persistence.xml.  Or, if you
> are in an app server environment, you should use a jndi lookup of a
> datasource.  This would be the most secure.
>
> Kevin
>
> On Tue, May 12, 2009 at 4:31 AM, wang yu  wrote:
>
>> As title.
>>
>> Regards,
>> Yu Wang
>>
>