-----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 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!
