Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jdo-dev@db.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Date: Thu, 14 Apr 2005 20:57:33 -0700
From: Craig Russell <Craig.Russell@Sun.COM>
Subject: Re: Apache JDO 2.0
In-reply-to: <425E7FAD.4060102@codehaus.org>
To: jdo-dev@db.apache.org
Message-id: <e91c077e346521eec338a24d26e8309d@Sun.COM>
MIME-version: 1.0
Content-type: multipart/signed; protocol="application/pkcs7-signature";
 boundary=Apple-Mail-52--61216157; micalg=sha1
References: <42548850.7020403@codehaus.org>
 <dfc869daf2a6cb69eb0ae757462fdf2f@Sun.COM> <4254CA80.4030502@codehaus.org>
 <b9e092d35c2a4b3d9ae7121fb1ce4c91@Sun.COM> <425E7FAD.4060102@codehaus.org>

--Apple-Mail-52--61216157
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed

Hi Brian,

Perhaps we can discuss this at tomorow's TCK meeting.

Craig

On Apr 14, 2005, at 7:35 AM, Brian Topping wrote:

> Hi Craig,
>
> Craig Russell wrote:
>
>> Hi Brian,
>>
>> On Apr 6, 2005, at 10:52 PM, Brian Topping wrote:
>>
>>> Craig Russell wrote:
>>>
>>> J5 is the reason I was bringing this up really.  We know that they 
>>> are going to keep moving forward with support for future JDK 
>>> classfile formats, and with different features as well.  I haven't 
>>> gotten too deep with the enhancer code yet, but know a few things 
>>> about the two bytecode libraries (was ready to get into it for my 
>>> MOF project).  ASM is good if you just want to generate bytecode but 
>>> want something that is a little higher level than pushing bytes out 
>>> to a ByteArrayStream.  OTOH, CGLib is much more OO, but since it 
>>> uses ASM, the two can be used together if you don't mind coding with 
>>> compatible semantics to CGLib.  From the very cursory look at the 
>>> output of other enhancers, I believe CGLib can probably to 
>>> everything we need in about 20% of the time, and we could go back 
>>> and hand-optimize what constructions we don't like after getting 
>>> some experience with the code.
>>
>>
>> I agree that the motivator here is J5. We *must* upgrade the enhancer 
>> to work with that platform. I think the work needs to be done first 
>> in ri11 and then migrated to JDO 2 project where we need to add 
>> features.
>>
>> I've discussed our options with the author of the ri11 enhancer and 
>> will try to document our discussion, but you can appreciate it's a 
>> bit tough not least because the author isn't officially working on 
>> our project.
>
> I'd like to take this work on, but need to segue it with 1)  the 
> existing work that I am signed up for on the XML Schema stuff (which 
> will take very little time and just needs to close out the questions 
> that I had on it) and 2) whether the results are going to be usable 
> from a project that I am currently developing.  I'll probably regret 
> saying this, but I don't think it's that difficult a problem with 
> CGLib, it just remains to be seen whether the problem and solution 
> domains overlap properly.
>
>>> FWIW, use of TQL doesn't really provide integration with Geronimo, 
>>> it only means that we would be sharing code (as a shared library 
>>> when used together).  It makes a lot of sense because both projects 
>>> can leverage each other's work on query tokenization and 
>>> transformation.  The great thing about TQL is we can substantially 
>>> increase the number of databases we support out of the box, although 
>>> it doesn't provide any kind of query executive or optimizer, so it 
>>> would not replace the manner by which the b-tree code is currently 
>>> used for file storage.  (But as you can imagine, the b-tree code 
>>> would need to be refactored or mated with a TQL transform to be 
>>> modularly used.)  As Gianny pointed out, it makes a lot of sense to 
>>> use it, and it is easy to use once you are moving with it.
>>
>>
>> Yeah, I didn't clearly communicate my understanding of the 
>> relationship between TQL, JDO, and Geronimo.
>>
>> I have to say, though, that I would not reuse the query tree 
>> walk/evaluator or the fostore b-tree implementation with TQL. 
>> Instead, I'd implement a different tree walker to generate SQL trees 
>> and implement a completely different StoreManager to talk SQL to a 
>> back end. That's where I'd use TQL.
>
> Hmm, I hadn't ever considered why this would be advantageous.  Could 
> you elaborate?  From my perspective, using the existing TQL AST code 
> gives us query compatibility with more databases as they are supported 
> by TQL, something we have to write ourselves if we don't use their 
> code.
>
>>
>> I'd like to use TQL not least in order to share the cache of objects 
>> between CMP, EJB3, and JDO. To the extent possible, I'd like to allow 
>> users to choose among these technologies for each piece of an 
>> application instead of choosing at a very high level. So adding some 
>> EJB3 entities to an existing CMP application should not be 
>> impossible. Likewise, enhancing an EJB3 application to use some JDO 
>> should be easy.
>
> Last I looked, TQL was not architected with personalities as loadable 
> libraries.  But it strikes me that these personalities could be made 
> into IoC components themselves, thus enabling the functionality you 
> speak of.  This would be the first time this has been done though.  Is 
> it something that is a high priority for the implementation?  I would 
> vote for this as a 2.1 or 3.0.
>
>>> Yes, but my reference was just in the context of JDORI, we do have 
>>> permission to use that code when it fits our needs, correct?  
>>> Regarding other projects, it's a very different story.  Apologies if 
>>> I gave you a shudder with the wrong impression on using code from 
>>> other projects.
>>
>>
>> We are free to exploit everything in the xxx11 projects to use in our 
>> yyy20 projects. I've actually been thinking about splitting out the 
>> ri11 into several yyy20 projects: enhancer, query, runtime, model, a 
>> few others. I don't think that ri11 is granular enough to e.g. add 
>> TQL as the back end, or use a mapping model from other open source 
>> implementations.
>
> That being said, is it worth adding J5 enhancement capability to ri11 
> first?  I would assert that CGLib is the way to go here, and if so, we 
> are fundamentally changing the way we enhance and it would be better 
> to include this as a part of a rewrite, not mash it into existing code 
> and port it.
>
> This leaves me wanting to get the 2.0 project started this week if 
> possible.  What am I missing?
>
> -b
>
>
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!

--Apple-Mail-52--61216157
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGHjCCAtcw
ggJAoAMCAQICAw3FWTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh
d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt
YWlsIElzc3VpbmcgQ0EwHhcNMDUwMTEwMDA0MTA5WhcNMDYwMTEwMDA0MTA5WjBHMR8wHQYDVQQD
ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSQwIgYJKoZIhvcNAQkBFhVDcmFpZy5SdXNzZWxsQFN1
bi5DT00wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDti7ZE4rO6oXKbLM02AG9WY55t
udmBVL53fb3V3X5S1kvcJOk1NEMIYT/T7Ww+/hE955zvHT29+mIoNe8AW/yj1WUH8uGG2HxhwCHI
UQTHmN/ioVJgjwUaYbtNMKbL/NRpnL0QWewdMJS+6IFzFyX7ADFW5cJ+UWNLvNeWAQtN0mtLildn
vdOgh50i8YPvACNkCHoomGjXx0azcXbe1X3c5AgRI6e2CZe5k2lRFQFUMqkjdoMtQPoNqJ1BxH9l
i4cnabl8mcTwHHl44hrvb8ThqwRf2pfJh2vVuwmgK6z4IWjOk4RQM+0ODsRdq67mBdimJYmPMK1p
RMBHzrUsfKxNAgMBAAGjMjAwMCAGA1UdEQQZMBeBFUNyYWlnLlJ1c3NlbGxAU3VuLkNPTTAMBgNV
HRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAIj86LzxCHedStDLMEeqHLy+UFG7zIRHfChSIV42
+MvXicydXEBh8v0Ry1V2d/lY4jS78G5yW5R9fKt1U5nlRBCOVzdhomvSolnNRIT71wPVVDrAIVlA
YpXKxSmVBq7+4hV+3ZLHDeq3qZnNmiJR0sTEUD16xZX1RJs9dRYPCHoRMIIDPzCCAqigAwIBAgIB
DTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTES
MBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMf
Q2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFs
IEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29t
MB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT
HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG
cmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK
mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbL
rzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZ
cmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0
cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQD
AgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0B
AQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3h
YWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1
TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNV
BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBJc3N1aW5nIENBAgMNxVkwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsG
CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwNDE1MDM1NzMzWjAjBgkqhkiG9w0BCQQxFgQU
z9SC6S9SdRNMV4bv/bEyB0588L4weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMG
A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv
bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw3FWTB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro
YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMNxVkwDQYJKoZIhvcNAQEBBQAEggEA
4HlRSfUGOQUpAe5wBRGvqt8Za16beGcHgl3jKyn2SdG9D2T/20jiRCkbdxnTmFpM2AZgUR9Za+oS
HQWChb0lNDaPGZ26/Ig1FCeD/o+OP9rUVoiEWnTGx29/zaGB3KnN5kIyRWG8Gze6Qp7is28E1nER
6S3lI38XcpwfceNRr8OD6N3Tpo8V5gHkPdpfMf263ADH24Pv22+th231ZKPPBnkzhjNUtzbtHYzf
5zlcvqlKG9HyZxqK1dGWGqKYNvYkZpfMHmrhZjscgWEVUVzLqhQPn3EsXcA4h537XBii5HFxtRQz
xJ4MgdYjyl16zDHR35fYBph1nD5ePvg2Q0jDrgAAAAAAAA==

--Apple-Mail-52--61216157--