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 Thu, 26 Apr 2007 20:49:37 GMT
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: Craig.Russell@Sun.COM [mailto:Craig.Russell@Sun.COM]
>> 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: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.
>>
>> Craig Russell
>> Architect, Sun Java Enterprise System http://java.sun.com/products/ 
>> jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com P.S. A good JDO? O, Gasp!
>>
>>
>
> 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