openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: More questions on runtime schema generation
Date Wed, 25 Apr 2007 19:42:15 GMT

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:david_jencks@yahoo.com]
>> 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.


Mime
View raw message