openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey" <plins...@bea.com>
Subject RE: More questions on runtime schema generation
Date Wed, 25 Apr 2007 19:55:58 GMT
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:david_jencks@yahoo.com] 
> 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: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.
> 
> 

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