RE: More questions on runtime schema generation
> > 2. It looks like the best strategy for geronimo to follow > is to figure > > out which jars in an ee app can possibly have persistent classes in > > them and supply a list of those jars to the > PersistenceUnitInfo. IIUC > > scanning those jars is already implemented. > > IIRC the spec limited the scope of a persistence unit to the > jar that contains the persistence.xml file, so we shouldn't > have to do deep scanning. ... but the developer can list additional jars in locations relative to the deployed jar, and the container is responsible for providing resolvable URLs for those jars via PUInfo. -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > -Original Message- > From: Dain Sundstrom [mailto:[EMAIL PROTECTED] > Sent: Friday, April 27, 2007 9:22 AM > To: open-jpa-dev@incubator.apache.org > Subject: Re: More questions on runtime schema generation > > On Apr 26, 2007, at 1:49 PM, David Jencks wrote: > > > Thanks for all the comments, I've learned a lot. > > > > 1. I have a classloader scanning strategy written and apparently > > working, however it is rather slow at least in geronimo. Is anyone > > interested in it, seeing as how its not an appropriate > approach in a > > app server according to Patrick's comment below? I think it might > > still be useful as a "last resort" strategy. > > > > 2. It looks like the best strategy for geronimo to follow > is to figure > > out which jars in an ee app can possibly have persistent classes in > > them and supply a list of those jars to the > PersistenceUnitInfo. IIUC > > scanning those jars is already implemented. > > IIRC the spec limited the scope of a persistence unit to the > jar that contains the persistence.xml file, so we shouldn't > have to do deep scanning. > > > 3. I can't get running ddl on a connection from an XADataSource in > > a simulated "RequiresNew" transaction to work reliably with > derby. > > The ddl appears to work fine but attempts to read data from the > > created sequence table hang until the tx times out and > derby does not > > report any deadlocks. Based on Craig's comments I've added a > > non-jta-datasource and this seems to be working much better. Has > > anyone seen problems like this? (seems unlikely in this > context since > > i had to modify a bunch of stuff to get to this problem :-) > > If the outer transaction has previously read from that table, > you have created a self deadlock. Have you checked the sql > to make sure that there isn't a query that referenced the > sequence table? > > -dain > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: More questions on runtime schema generation
On Apr 26, 2007, at 1:49 PM, David Jencks wrote: Thanks for all the comments, I've learned a lot. 1. I have a classloader scanning strategy written and apparently working, however it is rather slow at least in geronimo. Is anyone interested in it, seeing as how its not an appropriate approach in a app server according to Patrick's comment below? I think it might still be useful as a "last resort" strategy. 2. It looks like the best strategy for geronimo to follow is to figure out which jars in an ee app can possibly have persistent classes in them and supply a list of those jars to the PersistenceUnitInfo. IIUC scanning those jars is already implemented. IIRC the spec limited the scope of a persistence unit to the jar that contains the persistence.xml file, so we shouldn't have to do deep scanning. 3. I can't get running ddl on a connection from an XADataSource in a simulated "RequiresNew" transaction to work reliably with derby. The ddl appears to work fine but attempts to read data from the created sequence table hang until the tx times out and derby does not report any deadlocks. Based on Craig's comments I've added a non-jta-datasource and this seems to be working much better. Has anyone seen problems like this? (seems unlikely in this context since i had to modify a bunch of stuff to get to this problem :-) If the outer transaction has previously read from that table, you have created a self deadlock. Have you checked the sql to make sure that there isn't a query that referenced the sequence table? -dain
RE: More questions on runtime schema generation
> 1. I have a classloader scanning strategy written and > apparently working, however it is rather slow at least in > geronimo. Is anyone interested in it, seeing as how its not > an appropriate approach in a app server according to > Patrick's comment below? I think it might still be useful as > a "last resort" strategy. Can you describe it in more detail? > 2. It looks like the best strategy for geronimo to follow is > to figure out which jars in an ee app can possibly have > persistent classes in them and supply a list of those jars to > the PersistenceUnitInfo. IIUC scanning those jars is already > implemented. Yes. The easy way to do this is to just include all the jars in the scope of a given PU (all the jars in the EAR for EAR-scoped; all the jars in the WAR or EJB-JAR otherwise) in the PUInfo. -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > -Original Message- > From: David Jencks [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 26, 2007 1:50 PM > To: open-jpa-dev@incubator.apache.org > Subject: Re: More questions on runtime schema generation > > Thanks for all the comments, I've learned a lot. > > 1. I have a classloader scanning strategy written and > apparently working, however it is rather slow at least in > geronimo. Is anyone interested in it, seeing as how its not > an appropriate approach in a app server according to > Patrick's comment below? I think it might still be useful as > a "last resort" strategy. > > 2. It looks like the best strategy for geronimo to follow is > to figure out which jars in an ee app can possibly have > persistent classes in them and supply a list of those jars to > the PersistenceUnitInfo. IIUC scanning those jars is already > implemented. > > 3. I can't get running ddl on a connection from an > XADataSource in a simulated "RequiresNew" transaction to work > reliably with derby. The ddl appears to work fine but > attempts to read data from the created sequence table hang > until the tx times out and derby does not report any > deadlocks. Based on Craig's comments I've added a non-jta- > datasource and this seems to be working much better. Has > anyone seen problems like this? (seems unlikely in this > context since i had to modify a bunch of stuff to get to this > problem :-) > > many thanks > david jencks > > On Apr 25, 2007, at 3:56 PM, Patrick Linskey wrote: > > > Inside an appserver, there are parts of the PersistenceUnitInfo > > interface that are designed for the appserver to > communicate jars to > > scan to the persistence provider. > > > > -Patrick > > > > -- > > Patrick Linskey > > BEA Systems, Inc. > > > __ > > _ > > Notice: This email message, together with any attachments, may > > contain > > information of BEA Systems, Inc., its subsidiaries and > > affiliated > > entities, that may be confidential, proprietary, copyrighted > > and/or > > legally privileged, and is intended solely for the use of the > > individual or entity named in this message. If you are not the > > intended recipient, and have received this message in error, please > > immediately return this by email and then delete it. > > > >> -Original Message- > >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > >> Sent: Wednesday, April 25, 2007 3:55 PM > >> To: open-jpa-dev@incubator.apache.org > >> Subject: Re: More questions on runtime schema generation > >> > >> The general solution to this problem lies in a crisper > definition of > >> classloader domains in the app server. IIUC, each app > server has its > >> own policies in terms of where various components get loaded and > >> when. > >> > >> I think we need to engage the server spec team on this, > otherwise we > >> will end up chasing multiple incompatible class loader strategies, > >> all of which turn out to be spec compliant. > >> > >> And
Re: More questions on runtime schema generation
Thanks for all the comments, I've learned a lot. 1. I have a classloader scanning strategy written and apparently working, however it is rather slow at least in geronimo. Is anyone interested in it, seeing as how its not an appropriate approach in a app server according to Patrick's comment below? I think it might still be useful as a "last resort" strategy. 2. It looks like the best strategy for geronimo to follow is to figure out which jars in an ee app can possibly have persistent classes in them and supply a list of those jars to the PersistenceUnitInfo. IIUC scanning those jars is already implemented. 3. I can't get running ddl on a connection from an XADataSource in a simulated "RequiresNew" transaction to work reliably with derby. The ddl appears to work fine but attempts to read data from the created sequence table hang until the tx times out and derby does not report any deadlocks. Based on Craig's comments I've added a non-jta- datasource and this seems to be working much better. Has anyone seen problems like this? (seems unlikely in this context since i had to modify a bunch of stuff to get to this problem :-) many thanks david jencks On Apr 25, 2007, at 3:56 PM, Patrick Linskey wrote: Inside an appserver, there are parts of the PersistenceUnitInfo interface that are designed for the appserver to communicate jars to scan to the persistence provider. -Patrick -- Patrick Linskey BEA Systems, Inc. __ _ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 25, 2007 3:55 PM To: open-jpa-dev@incubator.apache.org Subject: Re: More questions on runtime schema generation The general solution to this problem lies in a crisper definition of classloader domains in the app server. IIUC, each app server has its own policies in terms of where various components get loaded and when. I think we need to engage the server spec team on this, otherwise we will end up chasing multiple incompatible class loader strategies, all of which turn out to be spec compliant. And for a first cut at "reasonable" we might ask the Spring folks how they handle this. Craig On Apr 25, 2007, at 12:26 PM, Patrick Linskey wrote: However IIUC this dissects the system property java.class.path and only parses stuff on that. This might be reasonable for a command line tool (although I have some doubts) but it seems to me that for any other situation a scan of the provided classloader would be more appropriate. Is this reasonable? It is. Of course, there is no standard way to scan classloaders. The best I know of is to do: cls.getProtectionDomain().getCodeSource().getLocation() and then scan from that URL. Of course, this assumes that a) you have a class (not a ClassLoader), b) you have security privileges to get the protection domain, and b) the location is parsable and accessible. Is there some other way that you know of to scan a ClassLoader? Also, I would like to suggest a flag in the openjpa.jdbc.SynchronizeMappings=buildSchema(...) stuff to turn on this eager scanning I'm trying to implement. Does this seem reasonable? It does. -- Patrick Linskey BEA Systems, Inc. _ _ _ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 25, 2007 12:18 PM To: open-jpa-dev@incubator.apache.org Subject: More questions on runtime schema generation I'm working on modifications so that ddl can operate in a separate transaction on a connection from the jta ds and I would like to have a complete scan and enhancement as soon as possible when the EMF is first accessed. I have this working when the classes are listed explicitly in the persistence.xml but not when they aren't. It looks like the relevant code is AbstractCFMetaDataFactory getPersistentTypeNames
RE: More questions on runtime schema generation
Inside an appserver, there are parts of the PersistenceUnitInfo interface that are designed for the appserver to communicate jars to scan to the persistence provider. -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 25, 2007 3:55 PM > To: open-jpa-dev@incubator.apache.org > Subject: Re: More questions on runtime schema generation > > The general solution to this problem lies in a crisper > definition of classloader domains in the app server. IIUC, > each app server has its own policies in terms of where > various components get loaded and when. > > I think we need to engage the server spec team on this, > otherwise we will end up chasing multiple incompatible class > loader strategies, all of which turn out to be spec compliant. > > And for a first cut at "reasonable" we might ask the Spring > folks how they handle this. > > Craig > > On Apr 25, 2007, at 12:26 PM, Patrick Linskey wrote: > > >> However IIUC this dissects the system property java.class.path and > >> only parses stuff on that. This might be reasonable for a command > >> line tool (although I have some > >> doubts) but it seems to me that for any other situation a > scan of the > >> provided classloader would be more appropriate. > >> Is this reasonable? > > > > It is. Of course, there is no standard way to scan > classloaders. The > > best I know of is to do: > > > > cls.getProtectionDomain().getCodeSource().getLocation() > > > > and then scan from that URL. > > > > Of course, this assumes that a) you have a class (not a > ClassLoader), > > b) you have security privileges to get the protection > domain, and b) > > the location is parsable and accessible. > > > > Is there some other way that you know of to scan a ClassLoader? > > > >> Also, I would like to suggest a flag in the > >> openjpa.jdbc.SynchronizeMappings=buildSchema(...) stuff to turn on > >> this eager scanning I'm trying to implement. Does this seem > >> reasonable? > > > > It does. > > > > -- > > Patrick Linskey > > BEA Systems, Inc. > > > __ > > _ > > Notice: This email message, together with any attachments, may > > contain > > information of BEA Systems, Inc., its subsidiaries and > > affiliated > > entities, that may be confidential, proprietary, copyrighted > > and/or > > legally privileged, and is intended solely for the use of the > > individual or entity named in this message. If you are not the > > intended recipient, and have received this message in error, please > > immediately return this by email and then delete it. > > > >> -Original Message- > >> From: David Jencks [mailto:[EMAIL PROTECTED] > >> Sent: Wednesday, April 25, 2007 12:18 PM > >> To: open-jpa-dev@incubator.apache.org > >> Subject: More questions on runtime schema generation > >> > >> I'm working on modifications so that ddl can operate in a separate > >> transaction on a connection from the jta ds and I would > like to have > >> a complete scan and enhancement as soon as possible when > the EMF is > >> first accessed. I have this working when the classes are listed > >> explicitly in the persistence.xml but not when they aren't. > >> > >> It looks like the relevant code is AbstractCFMetaDataFactory > >> getPersistentTypeNames > >> > >> if (names.isEmpty() && devpath) > >> scan(new ClasspathMetaDataIterator(null, > >> newMetaDataFilter()), > >> newClassArgParser(), names, false, null); > >> > >> > >> However IIUC this dissects the system property java.class.path and > >> only parses stuff on that. This might be reasonable for a command > >> line tool (although I hav
Re: More questions on runtime schema generation
The general solution to this problem lies in a crisper definition of classloader domains in the app server. IIUC, each app server has its own policies in terms of where various components get loaded and when. I think we need to engage the server spec team on this, otherwise we will end up chasing multiple incompatible class loader strategies, all of which turn out to be spec compliant. And for a first cut at "reasonable" we might ask the Spring folks how they handle this. Craig On Apr 25, 2007, at 12:26 PM, Patrick Linskey wrote: However IIUC this dissects the system property java.class.path and only parses stuff on that. This might be reasonable for a command line tool (although I have some doubts) but it seems to me that for any other situation a scan of the provided classloader would be more appropriate. Is this reasonable? It is. Of course, there is no standard way to scan classloaders. The best I know of is to do: cls.getProtectionDomain().getCodeSource().getLocation() and then scan from that URL. Of course, this assumes that a) you have a class (not a ClassLoader), b) you have security privileges to get the protection domain, and b) the location is parsable and accessible. Is there some other way that you know of to scan a ClassLoader? Also, I would like to suggest a flag in the openjpa.jdbc.SynchronizeMappings=buildSchema(...) stuff to turn on this eager scanning I'm trying to implement. Does this seem reasonable? It does. -- Patrick Linskey BEA Systems, Inc. __ _ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 25, 2007 12:18 PM To: open-jpa-dev@incubator.apache.org Subject: More questions on runtime schema generation I'm working on modifications so that ddl can operate in a separate transaction on a connection from the jta ds and I would like to have a complete scan and enhancement as soon as possible when the EMF is first accessed. I have this working when the classes are listed explicitly in the persistence.xml but not when they aren't. It looks like the relevant code is AbstractCFMetaDataFactory getPersistentTypeNames if (names.isEmpty() && devpath) scan(new ClasspathMetaDataIterator(null, newMetaDataFilter()), newClassArgParser(), names, false, null); However IIUC this dissects the system property java.class.path and only parses stuff on that. This might be reasonable for a command line tool (although I have some doubts) but it seems to me that for any other situation a scan of the provided classloader would be more appropriate. Is this reasonable? Also, I would like to suggest a flag in the openjpa.jdbc.SynchronizeMappings=buildSchema(...) stuff to turn on this eager scanning I'm trying to implement. Does this seem reasonable? thanks david jencks Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
RE: More questions on runtime schema generation
OpenJPA actually already has jar-scanning code. Try the following: openjpa.jdbc.SynchronizeMappings: buildSchema(files=path/to/file.jar;path/to/another-file.jar) You can also specify 'resources' or 'URLs'. These algorithms use org.apache.openjpa.lib.meta.ClassAnnotationMetaDataFilter, which scans bytes for specified annotations. IIRC, we looked at some Apache code when implementing it; I can't remember if it was xbean code or not. -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > -Original Message- > From: David Jencks [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 25, 2007 12:42 PM > To: open-jpa-dev@incubator.apache.org > Subject: Re: More questions on runtime schema generation > > > On Apr 25, 2007, at 12:26 PM, Patrick Linskey wrote: > > >> However IIUC this dissects the system property java.class.path and > >> only parses stuff on that. This might be reasonable for a command > >> line tool (although I have some > >> doubts) but it seems to me that for any other situation a > scan of the > >> provided classloader would be more appropriate. > >> Is this reasonable? > > > > It is. Of course, there is no standard way to scan > classloaders. The > > best I know of is to do: > > > > cls.getProtectionDomain().getCodeSource().getLocation() > > > > and then scan from that URL. > > > > Of course, this assumes that a) you have a class (not a > ClassLoader), > > b) you have security privileges to get the protection > domain, and b) > > the location is parsable and accessible. > > > > Is there some other way that you know of to scan a ClassLoader? > > I was going to steal code from xbean ClassFinder > > https://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-finder/ > src/main/java/org/apache/xbean/finder/ClassFinder.java > > which works for jar files, which is all I'm interested in. > It locates the jar or directory or an exploded jar by looking > for all the META-INF resources in the classloader. This > isn't exactly scanning a classloader but will be adequate for me. > > I don't suppose openjpa would be interested in using the > xbean-finder jar directly? It only has 3 classes in it :-) > In particular ClassFinder is good at locating all the classes > with an annotation in a classloader. > > thanks > david jencks > > > > > >> Also, I would like to suggest a flag in the > >> openjpa.jdbc.SynchronizeMappings=buildSchema(...) stuff to turn on > >> this eager scanning I'm trying to implement. Does this seem > >> reasonable? > > > > It does. > > > > -- > > Patrick Linskey > > BEA Systems, Inc. > > > __ > > _ > > Notice: This email message, together with any attachments, may > > contain > > information of BEA Systems, Inc., its subsidiaries and > > affiliated > > entities, that may be confidential, proprietary, copyrighted > > and/or > > legally privileged, and is intended solely for the use of the > > individual or entity named in this message. If you are not the > > intended recipient, and have received this message in error, please > > immediately return this by email and then delete it. > > > >> -Original Message- > >> From: David Jencks [mailto:[EMAIL PROTECTED] > >> Sent: Wednesday, April 25, 2007 12:18 PM > >> To: open-jpa-dev@incubator.apache.org > >> Subject: More questions on runtime schema generation > >> > >> I'm working on modifications so that ddl can operate in a separate > >> transaction on a connection from the jta ds and I would > like to have > >> a complete scan and enhancement as soon as possible when > the EMF is > >> first accessed. I have this working when the classes are listed > >> explicitly in the persistence.xml but not when they aren't. > >> > >> It looks like the relevant code is AbstractCFMetaDataFactory > >> getPersistentTypeNames &
Re: More questions on runtime schema generation
On Apr 25, 2007, at 12:26 PM, Patrick Linskey wrote: However IIUC this dissects the system property java.class.path and only parses stuff on that. This might be reasonable for a command line tool (although I have some doubts) but it seems to me that for any other situation a scan of the provided classloader would be more appropriate. Is this reasonable? It is. Of course, there is no standard way to scan classloaders. The best I know of is to do: cls.getProtectionDomain().getCodeSource().getLocation() and then scan from that URL. Of course, this assumes that a) you have a class (not a ClassLoader), b) you have security privileges to get the protection domain, and b) the location is parsable and accessible. Is there some other way that you know of to scan a ClassLoader? I was going to steal code from xbean ClassFinder https://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-finder/ src/main/java/org/apache/xbean/finder/ClassFinder.java which works for jar files, which is all I'm interested in. It locates the jar or directory or an exploded jar by looking for all the META-INF resources in the classloader. This isn't exactly scanning a classloader but will be adequate for me. I don't suppose openjpa would be interested in using the xbean-finder jar directly? It only has 3 classes in it :-) In particular ClassFinder is good at locating all the classes with an annotation in a classloader. thanks david jencks Also, I would like to suggest a flag in the openjpa.jdbc.SynchronizeMappings=buildSchema(...) stuff to turn on this eager scanning I'm trying to implement. Does this seem reasonable? It does. -- Patrick Linskey BEA Systems, Inc. __ _ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 25, 2007 12:18 PM To: open-jpa-dev@incubator.apache.org Subject: More questions on runtime schema generation I'm working on modifications so that ddl can operate in a separate transaction on a connection from the jta ds and I would like to have a complete scan and enhancement as soon as possible when the EMF is first accessed. I have this working when the classes are listed explicitly in the persistence.xml but not when they aren't. It looks like the relevant code is AbstractCFMetaDataFactory getPersistentTypeNames if (names.isEmpty() && devpath) scan(new ClasspathMetaDataIterator(null, newMetaDataFilter()), newClassArgParser(), names, false, null); However IIUC this dissects the system property java.class.path and only parses stuff on that. This might be reasonable for a command line tool (although I have some doubts) but it seems to me that for any other situation a scan of the provided classloader would be more appropriate. Is this reasonable? Also, I would like to suggest a flag in the openjpa.jdbc.SynchronizeMappings=buildSchema(...) stuff to turn on this eager scanning I'm trying to implement. Does this seem reasonable? thanks david jencks Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
RE: More questions on runtime schema generation
> However IIUC this dissects the system property > java.class.path and only parses stuff on that. This might be > reasonable for a command line tool (although I have some > doubts) but it seems to me that for any other situation a > scan of the provided classloader would be more appropriate. > Is this reasonable? It is. Of course, there is no standard way to scan classloaders. The best I know of is to do: cls.getProtectionDomain().getCodeSource().getLocation() and then scan from that URL. Of course, this assumes that a) you have a class (not a ClassLoader), b) you have security privileges to get the protection domain, and b) the location is parsable and accessible. Is there some other way that you know of to scan a ClassLoader? > Also, I would like to suggest a flag in the > openjpa.jdbc.SynchronizeMappings=buildSchema(...) stuff to > turn on this eager scanning I'm trying to implement. Does > this seem reasonable? It does. -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > -Original Message- > From: David Jencks [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 25, 2007 12:18 PM > To: open-jpa-dev@incubator.apache.org > Subject: More questions on runtime schema generation > > I'm working on modifications so that ddl can operate in a > separate transaction on a connection from the jta ds and I > would like to have a complete scan and enhancement as soon as > possible when the EMF is first accessed. I have this working > when the classes are listed explicitly in the persistence.xml > but not when they aren't. > > It looks like the relevant code is AbstractCFMetaDataFactory > getPersistentTypeNames > > if (names.isEmpty() && devpath) > scan(new ClasspathMetaDataIterator(null, > newMetaDataFilter()), > newClassArgParser(), names, false, null); > > > However IIUC this dissects the system property > java.class.path and only parses stuff on that. This might be > reasonable for a command line tool (although I have some > doubts) but it seems to me that for any other situation a > scan of the provided classloader would be more appropriate. > Is this reasonable? > > Also, I would like to suggest a flag in the > openjpa.jdbc.SynchronizeMappings=buildSchema(...) stuff to > turn on this eager scanning I'm trying to implement. Does > this seem reasonable? > > thanks > david jencks > > > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
