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.
