Whether or not an EMF needs to be serializable, we still need to decide if a BrokerFactory needs to be serializable.
For example, currently, you can serialize a Broker, but it will only deserialize if the VM it's deserializing into has the same BrokerFactory already deployed. -Patrick On Feb 6, 2008 9:19 AM, Craig L Russell <[EMAIL PROTECTED]> wrote: > I think we should ask the JPA EG to resolve whether EMF should be > serializable. > > When a session bean is passivated of saved for failover, it is > serialized. When serializing the state of a session bean, the fields > of the bean need to be serialized. If the EMF is stored in a field, > then it needs to be restored when the session is restored. It would be > nice if the semantics of passivation and save for failover of an EMF > were standardized. > > Craig > > > On Feb 5, 2008, at 5:01 PM, David Ezzio wrote: > > > Hi Patrick, > > > > The build was fragile because a couple of test cases were fragile > > (one did not clean out data before checking whether only the data it > > added was present, and the other did not ensure that time passed > > between updates when using a timestamp version check), and because > > the testing framework itself was fragile in that it attempted to > > delete data using a new entity manager when transactions might > > remain open (due to test failures), resulting in deadlock in the > > database. I've fixed these issues. > > > > Since there is no present resolution of the question whether to > > serialize or not the EMF, I have put in my change once again > > together with the updated test case. I expect that TeamCity will > > now be happy due to the aforementioned fixes of the testing > > framework, etc. > > > > Of course, we can always revisit the issue of whether to allow the > > EMF to be serialized, but since it currently is serializable, I put > > in the fix to actually allow it to serialize successfully. > > > > David > > > > Patrick Linskey wrote: > >> Yes, I agree that if we make serialization not work, we should make > >> the BF not implement Serializable. That is my preferred approach: > >> even > >> if Kodo needs to serialize a PMF for JNDI purposes or something, we > >> could do that in the PMF impl, instead of in the BF. > >> IMO, the build is fragile because it runs multiple unrelated tests in > >> the same VM with no strong isolation between tests. This leads to > >> unexpected side effects sometimes. This can be frustrating, but the > >> benefits are considerable: faster test run time, plus we get to find > >> out about weird unintended side effects. > >> -Patrick > >> On 2/1/08, David Ezzio <[EMAIL PROTECTED]> wrote: > >>> Hi, > >>> > >>> As to testing that the EMF objects are useful after serialization, > >>> this > >>> is a reasonable expectation of any object that is an instance of the > >>> Serializable interface. > >>> > >>> If it turns out that we don't want to support serializing useful EMF > >>> objects, then we should take care to remove the Serializable > >>> interface > >>> from their implementation. > >>> > >>> As I understand it, it is this latter issue that is currently under > >>> discussion. > >>> > >>> An important, but only tangentially related, issue is why the > >>> build is > >>> so fragile. > >>> > >>> David > >>> > >>> Pinaki Poddar wrote: > >>>> Hi, > >>>> Serializablity requirement on EMF is arising out of necessity > >>>> rather > >>>> than by JPA specifcation. > >>>> JNDI, too, does not mandate bound objects to be Serializable. > >>>> But JNDI providers often place that restriction. > >>>> Non-serializable objects can be bound to JNDI by implementing > >>>> javax.naming.Referenceable. > >>>> Kodo's JDO product derivation based on OpenJPA is following this > >>>> Referenceable route. > >>>> > >>>> But I do not see this in openjpa EntityManagerFactory > >>>> implementation. > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: Kevin Sutter [mailto:[EMAIL PROTECTED] > >>>> Sent: Friday, February 01, 2008 11:11 AM > >>>> To: [email protected] > >>>> Subject: Re: Failures in TeamCity Derby build and svn commit: > >>>> r616972 > >>>> > >>>> On Feb 1, 2008 10:17 AM, Pinaki Poddar <[EMAIL PROTECTED]> wrote: > >>>> > >>>>> Factories needs to be Serializable as they are often placed in > >>>>> JNDI. > >>>> > >>>> The JNDI lookup needs to work for the Factory definition, but it > >>>> doesn't > >>>> require that the actual Factory be present in JNDI. And, since > >>>> the JNDI > >>>> lookup is meant for the EE (Container) environment, I would guess > >>>> that > >>>> most implementations provide a wrapper object in JNDI for the > >>>> actual > >>>> Factory. > >>>> > >>>> Granted, this wrapper approach is not a requirement. But, I > >>>> can't find > >>>> the requirement in the spec that the EMF has to be Serializable > >>>> either... :-) > >>>> > >>>> Kevin > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Patrick Linskey [mailto:[EMAIL PROTECTED] > >>>>> Sent: Thursday, January 31, 2008 7:57 PM > >>>>> To: [email protected] > >>>>> Subject: Re: Failures in TeamCity Derby build and svn commit: > >>>>> r616972 > >>>>> > >>>>> To be honest, I don't really understand why a BrokerFactory > >>>>> needs to > >>>>> be serializable, so I think probably it'd be good to make sure > >>>>> that > >>>>> there is good reason for that before going too deep into this > >>>>> debugging exercise. > >>>>> > >>>>> -Patrick > >>>>> > >>>>> On Jan 31, 2008 5:52 PM, Patrick Linskey <[EMAIL PROTECTED]> > >>>>> wrote: > >>>>>>> If the hangup is intolerable, let me know, and I'll back out my > >>>>>>> change tomorrow. > >>>>>> Personally, I'd rather have the TeamCity build be clean while you > >>>>>> investigate. As you noted, the error-reporting from surefire is > >>>>>> frustratingly inaccurate, and this really erodes the benefit of > >>>>>> continuous integration. > >>>>>> > >>>>>>> It would be handy if I knew a few things. How to pass in VM > >>>>>>> debug > >>>>>>> args to Maven for its test runs, where to set the OpenJPA > >>>>>>> logging > >>>>>>> when Maven runs the tests, and how to pass in the appropriate > >>>>>>> parameters when running the test case outside of Maven. Any > >>>>>>> insights on these questions will be appreciated. > >>>>>> I usually just add log configuration to the test cases > >>>>>> themselves, > >>>>>> in the setUp(...) method: > >>>>>> > >>>>>> setUp(Class.class, Class2.class, ..., "openjpa.Log", > >>>>>> "SQL=TRACE"); > >>>>>> > >>>>>> I believe that it is also possible to set this at the command > >>>>>> line > >>>>>> via > >>>>>> -Dopenjpa.Log=SQL=TRACE types of clauses. > >>>>>> > >>>>>> -Patrick > >>>>>> > >>>>>> > >>>>>> On Jan 31, 2008 4:08 PM, David Ezzio <[EMAIL PROTECTED]> wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> Progress has been slow on the test failures apparently > >>>>>>> introduced > >>>>>>> by > >>>>>>> 616972. I have made progress in reproducing the results. > >>>>>>> > >>>>>>> The miscounting in TeamCity is gross. Although it lists 33 > >>>>>>> failing tests complete with a credible stack trace for each, in > >>>>>>> fact, there is only one failing test. > >>>>>>> > >>>>>>> Meanwhile, I believe now, that change 616658 is no longer a > >>>> suspect. > >>>>>>> I get very erratic results here, but they seem to vary more by > >>>>>>> whether I run "mvn test" after "mvn clean" or "mvn install" > >>>>>>> after > >>>>>>> "mvn clean". By doing just what TeamCity does, "mvn clean > >>>>>>> compile > >>>>>>> test", I can finally reproduce the results locally that TeamCity > >>>>>>> reports in its Compile-Derby build for this change (395, I > >>>>>>> think). > >>>>>>> In spite of this, if I run "mvn > >>>>>>> -Dtest=TestCaseInsensitiveKeywordsInJPQL clean compile test" the > >>>>> test passes. > >>>>>>> It would be handy if I knew a few things. How to pass in VM > >>>>>>> debug > >>>>>>> args to Maven for its test runs, where to set the OpenJPA > >>>>>>> logging > >>>>>>> when Maven runs the tests, and how to pass in the appropriate > >>>>>>> parameters when running the test case outside of Maven. Any > >>>>>>> insights on these questions will be appreciated. > >>>>>>> > >>>>>>> But at least at this point, I can reproduce locally what > >>>>>>> TeamCity > >>>>>>> reports, and although it happened only once out of one try, I am > >>>>>>> optimistic that it is reproducible. I will continue working > >>>>>>> this > >>>>>>> tomorrow. > >>>>>>> > >>>>>>> If the hangup is intolerable, let me know, and I'll back out my > >>>>>>> change tomorrow. > >>>>>>> > >>>>>>> David Ezzio > >>>>>>> > >>>>>>> > >>>>>>> David Ezzio wrote: > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> I am convinced that change 616658 (small change to > >>>>>>>> DBDictionary.java) is the source of the two intermittent > >>>>>>>> failures > >>>>> that I am seeing locally. > >>>>>>>> One of those intermittent failures is the failure in > >>>>>>>> TestCaseInsensitiveKeywordsInJPQL.testCaseInsensitiveBooleans > >>>>>>>> which is one of the 33 related failures currently seen in > >>>>>>>> TeamCity > >>>>> Derby builds. > >>>>>>>> The other intermittent failure is > >>>>>>>> TestVersion.testVersionTimestamp > >>>>>>>> which I reported earlier as occurring locally with change > >>>> 616658. > >>>>>>>> When I revert change 616658 locally, both of these issues go > >>>>>>>> away even with the changes that I submitted to > >>>>>>>> AbstractBrokerFactory in > >>>>>>>> change 616972. > >>>>>>>> > >>>>>>>> I have a question: is it possible to run a build in TeamCity > >>>>>>>> without submitting the change (or conditionally submitting the > >>>>> change) to SVN? > >>>>>>>> I'd like to find out if reverting 616658 will fix the issue. > >>>>>>>> If > >>>>>>>> so, then I can try to figure out why it's a problem. > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> > >>>>>>>> David > >>>>>>>> > >>>>>>>> David Ezzio wrote: > >>>>>>>>> No, but I'm taking a look since my changes appear to be the > >>>>> cause. > >>>>>>>>> Patrick Linskey wrote: > >>>>>>>>>> 5. The tests are now failing in the automated build; any idea > >>>>>>>>>> why this might be? > >>>>>>>>>> > >>>>>>>>>> -Patrick > >>>>>>>>>> > >>>>>>>>>> On Jan 30, 2008 6:11 PM, Patrick Linskey <[EMAIL PROTECTED]> > >>>>> wrote: > >>>>>>>>>>> Hi, > >>>>>>>>>>> > >>>>>>>>>>> A few questions: > >>>>>>>>>>> > >>>>>>>>>>> 1. Were you seeing this cause problems somewhere? I.e., when > >>>>>>>>>>> do > >>>>>>>>>>> we serialize BrokerFactory instances? > >>>>>>>>>>> > >>>>>>>>>>> 2. Why not just move the initialization code to the > >>>>>>>>>>> declaration > >>>>>>>>>>> line (instead of the constructor)? > >>>>>>>>>>> > >>>>>>>>>>> 3. It looks like there are other transactional structures > >>>>>>>>>>> that might not be properly handled in serialization / > >>>>>>>>>>> deserialization (lifecycle listeners, for example). Should > >>>>>>>>>>> we > >>>>> be making more changes there? > >>>>>>>>>>> -Patrick > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> On Jan 30, 2008 4:59 PM, <[EMAIL PROTECTED]> wrote: > >>>>>>>>>>>> Author: dezzio > >>>>>>>>>>>> Date: Wed Jan 30 16:59:02 2008 New Revision: 616972 > >>>>>>>>>>>> > >>>>>>>>>>>> URL: http://svn.apache.org/viewvc?rev=616972&view=rev > >>>>>>>>>>>> Log: > >>>>>>>>>>>> Allow EntityManagerFactory objects to be serialized and > >>>>>>>>>>>> deserialized successfully. > >>>>>>>>>>>> > >>>>>>>>>>>> Added: > >>>>>>>>>>>> > >>>>>>>>>>>> openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/ > >>>>>>>>>>>> apa > >>>>>>>>>>>> ch e/openjpa/persistence/simple/TestSerializedFactory.java > >>>>>>>>>>>> (with props) > >>>>>>>>>>>> Modified: > >>>>>>>>>>>> > >>>>>>>>>>>> openjpa/trunk/openjpa-kernel/src/main/java/org/apache/ > >>>>>>>>>>>> openjp > >>>>>>>>>>>> a/ kernel/AbstractBrokerFactory.java > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Modified: > >>>>>>>>>>>> openjpa/trunk/openjpa-kernel/src/main/java/org/apache/ > >>>>>>>>>>>> openjp > >>>>>>>>>>>> a/ kernel/AbstractBrokerFactory.java > >>>>>>>>>>>> > >>>>>>>>>>>> URL: > >>>>>>>>>>>> http://svn.apache.org/viewvc/openjpa/trunk/openjpa-kernel/ > >>>>>>>>>>>> sr > >>>>>>>>>>>> c/ > >>>>>>>>>>>> main/java/org/apache/openjpa/kernel/ > >>>>>>>>>>>> AbstractBrokerFactory.ja > >>>>>>>>>>>> va ?rev=616972&r1=616971&r2=616972&view=diff > >>>>>>>>>>>> > >>>>>>>>>>>> = > >>>>>>>>>>>> =========================================================== > >>>>>>>>>>>> == > >>>>>>>>>>>> ================ > >>>>>>>>>>>> > >>>>>>>>>>>> --- > >>>>>>>>>>>> openjpa/trunk/openjpa-kernel/src/main/java/org/apache/ > >>>>>>>>>>>> openjp > >>>>>>>>>>>> a/ kernel/AbstractBrokerFactory.java > >>>>>>>>>>>> (original) > >>>>>>>>>>>> +++ > >>>>>>>>>>>> openjpa/trunk/openjpa-kernel/src/main/java/org/apache/ > >>>>>>>>>>>> openjp > >>>>>>>>>>>> a/ kernel/AbstractBrokerFactory.java Wed Jan 30 16:59:02 > >>>>>>>>>>>> 2008 @@ -147,8 +147,7 @@ > >>>>>>>>>>>> */ > >>>>>>>>>>>> protected AbstractBrokerFactory(OpenJPAConfiguration > >>>>> config) { > >>>>>>>>>>>> _conf = config; > >>>>>>>>>>>> - _pcClassLoaders = new ConcurrentReferenceHashSet( > >>>>>>>>>>>> - ConcurrentReferenceHashSet.WEAK); > >>>>>>>>>>>> + getPcClassLoaders(); > >>>>>>>>>>>> } > >>>>>>>>>>>> > >>>>>>>>>>>> /** > >>>>>>>>>>>> @@ -287,13 +286,13 @@ > >>>>>>>>>>>> if (needsSub(cls)) > >>>>>>>>>>>> toRedefine.add(cls); > >>>>>>>>>>>> } > >>>>>>>>>>>> - _pcClassLoaders.add(loader); > >>>>>>>>>>>> + getPcClassLoaders().add(loader); > >>>>>>>>>>>> _pcClassNames = c; > >>>>>>>>>>>> } > >>>>>>>>>>>> _persistentTypesLoaded = true; > >>>>>>>>>>>> } else { > >>>>>>>>>>>> // reload with this loader > >>>>>>>>>>>> - if (_pcClassLoaders.add(loader)) { > >>>>>>>>>>>> + if (getPcClassLoaders().add(loader)) { > >>>>>>>>>>>> for (Iterator itr = > >>>>>>>>>>>> _pcClassNames.iterator(); > >>>>>>>>>>>> itr.hasNext();) { > >>>>>>>>>>>> try { > >>>>>>>>>>>> Class cls = @@ -818,4 +817,15 @@ > >>>>>>>>>>>> _transactional.remove (_trans); > >>>>>>>>>>>> } > >>>>>>>>>>>> } > >>>>>>>>>>>> + > >>>>>>>>>>>> + /** > >>>>>>>>>>>> + * Method insures that deserialized EMF has this > >>>>>>>>>>>> + reference > >>>>>>>>>>>> re-instantiated > >>>>>>>>>>>> + */ > >>>>>>>>>>>> + private Collection getPcClassLoaders() { > >>>>>>>>>>>> + if (_pcClassLoaders == null) > >>>>>>>>>>>> + _pcClassLoaders = new ConcurrentReferenceHashSet( > >>>>>>>>>>>> + ConcurrentReferenceHashSet.WEAK); > >>>>>>>>>>>> + > >>>>>>>>>>>> + return _pcClassLoaders; > >>>>>>>>>>>> + } > >>>>>>>>>>>> } > >>>>>>>>>>>> > >>>>>>>>>>>> Added: > >>>>>>>>>>>> openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/ > >>>>>>>>>>>> apa > >>>>>>>>>>>> ch e/openjpa/persistence/simple/TestSerializedFactory.java > >>>>>>>>>>>> > >>>>>>>>>>>> URL: > >>>>>>>>>>>> http://svn.apache.org/viewvc/openjpa/trunk/openjpa- > >>>>>>>>>>>> persisten > >>>>>>>>>>>> ce > >>>>>>>>>>>> -jdbc/src/test/java/org/apache/openjpa/persistence/simple/ > >>>>>>>>>>>> Te > >>>>>>>>>>>> st SerializedFactory.java?rev=616972&view=auto > >>>>>>>>>>>> > >>>>>>>>>>>> = > >>>>>>>>>>>> =========================================================== > >>>>>>>>>>>> == > >>>>>>>>>>>> ================ > >>>>>>>>>>>> > >>>>>>>>>>>> --- > >>>>>>>>>>>> openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/ > >>>>>>>>>>>> apa > >>>>>>>>>>>> ch e/openjpa/persistence/simple/TestSerializedFactory.java > >>>>>>>>>>>> (added) > >>>>>>>>>>>> +++ > >>>>>>>>>>>> openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/ > >>>>>>>>>>>> apa > >>>>>>>>>>>> ch e/openjpa/persistence/simple/TestSerializedFactory.java > >>>>>>>>>>>> Wed Jan 30 16:59:02 2008 > >>>>>>>>>>>> @@ -0,0 +1,74 @@ > >>>>>>>>>>>> +/* > >>>>>>>>>>>> + * Licensed to the Apache Software Foundation (ASF) under > >>>>>>>>>>>> +one > >>>>>>>>>>>> + * or more contributor license agreements. See the NOTICE > >>>>>>>>>>>> +file > >>>>>>>>>>>> + * distributed with this work for additional information > >>>>>>>>>>>> + * regarding copyright ownership. The ASF licenses this > >>>>>>>>>>>> +file > >>>>>>>>>>>> + * to you under the Apache License, Version 2.0 (the > >>>>>>>>>>>> + * "License"); you may not use this file except in > >>>>>>>>>>>> +compliance > >>>>>>>>>>>> + * with the License. You may obtain a copy of the License > >>>>>>>>>>>> +at > >>>>>>>>>>>> + * > >>>>>>>>>>>> + * http://www.apache.org/licenses/LICENSE-2.0 > >>>>>>>>>>>> + * > >>>>>>>>>>>> + * Unless required by applicable law or agreed to in > >>>>>>>>>>>> +writing, > >>>>>>>>>>>> + * software distributed under the License is distributed > >>>>>>>>>>>> on > >>>>>>>>>>>> +an > >>>>>>>>>>>> + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY > >>>>>>>>>>>> + * KIND, either express or implied. See the License for > >>>>>>>>>>>> +the > >>>>>>>>>>>> + * specific language governing permissions and limitations > >>>>>>>>>>>> + * under the License. > >>>>>>>>>>>> + */ > >>>>>>>>>>>> +package org.apache.openjpa.persistence.simple; > >>>>>>>>>>>> + > >>>>>>>>>>>> +import java.io.*; > >>>>>>>>>>>> + > >>>>>>>>>>>> +import javax.persistence.EntityManager; import > >>>>>>>>>>>> +javax.persistence.EntityManagerFactory; > >>>>>>>>>>>> +import javax.persistence.EntityTransaction; > >>>>>>>>>>>> + > >>>>>>>>>>>> +import junit.textui.TestRunner; import > >>>>>>>>>>>> +org.apache.openjpa.persistence.OpenJPAEntityManager; > >>>>>>>>>>>> +import > >>>>>>>>>>>> +org.apache.openjpa.persistence.test.SingleEMFTestCase; > >>>>>>>>>>>> + > >>>>>>>>>>>> +/** > >>>>>>>>>>>> + * Tests that a EntityManagerFactory can be used after > >>>>> serialization. > >>>>>>>>>>>> + * > >>>>>>>>>>>> + * @author David Ezzio > >>>>>>>>>>>> + */ > >>>>>>>>>>>> +public class TestSerializedFactory > >>>>>>>>>>>> + extends SingleEMFTestCase { > >>>>>>>>>>>> + > >>>>>>>>>>>> + public void setUp() { > >>>>>>>>>>>> + setUp(AllFieldTypes.class); > >>>>>>>>>>>> + } > >>>>>>>>>>>> + > >>>>>>>>>>>> + public void testSerializedEntityManagerFactory() > >>>>>>>>>>>> throws > >>>>>>>>>>>> Exception { > >>>>>>>>>>>> + // serialize and deserialize the entity manager > >>>>> factory > >>>>>>>>>>>> + ByteArrayOutputStream baos = new > >>>>> ByteArrayOutputStream(); > >>>>>>>>>>>> + ObjectOutputStream oos = new > >>>>> ObjectOutputStream(baos); > >>>>>>>>>>>> + oos.writeObject(emf); > >>>>>>>>>>>> + EntityManagerFactory emf2 = > >>>>>>>>>>>> + (EntityManagerFactory) new ObjectInputStream( > >>>>>>>>>>>> + new > >>>>>>>>>>>> ByteArrayInputStream(baos.toByteArray())).readObject(); > >>>>>>>>>>>> + > >>>>>>>>>>>> + // use the deserialized entity manager factory > >>>>>>>>>>>> + assertTrue("The deserialized entity manager > >>>>>>>>>>>> factory > >>>>>>>>>>>> + is not > >>>>>>>>>>>> open", > >>>>>>>>>>>> + emf2.isOpen()); > >>>>>>>>>>>> + EntityManager em = emf2.createEntityManager(); > >>>>>>>>>>>> + assertTrue("The newly created entity manager is > >>>>>>>>>>>> not > >>>>>>>>>>>> + open", > >>>>>>>>>>>> em.isOpen()); > >>>>>>>>>>>> + > >>>>>>>>>>>> + // exercise the entity manager produced from the > >>>>>>>>>>>> deserialized EMF > >>>>>>>>>>>> + em.getTransaction().begin(); > >>>>>>>>>>>> + em.persist(new AllFieldTypes()); > >>>>>>>>>>>> + em.getTransaction().commit(); > >>>>>>>>>>>> + > >>>>>>>>>>>> + // close the extra resources > >>>>>>>>>>>> + em.close(); > >>>>>>>>>>>> + assertFalse("The entity manager is not closed", > >>>>> em.isOpen()); > >>>>>>>>>>>> + emf2.close(); > >>>>>>>>>>>> + assertFalse("The entity manager factory is not > >>>>>>>>>>>> + closed", > >>>>>>>>>>>> emf2.isOpen()); > >>>>>>>>>>>> + } > >>>>>>>>>>>> + > >>>>>>>>>>>> + public static void main(String[] args) { > >>>>>>>>>>>> + TestRunner.run(TestSerializedFactory.class); > >>>>>>>>>>>> + } > >>>>>>>>>>>> +} > >>>>>>>>>>>> + > >>>>>>>>>>>> > >>>>>>>>>>>> Propchange: > >>>>>>>>>>>> openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/ > >>>>>>>>>>>> apa > >>>>>>>>>>>> ch e/openjpa/persistence/simple/TestSerializedFactory.java > >>>>>>>>>>>> > >>>>>>>>>>>> ------------------------------------------------------------ > >>>>>>>>>>>> -- > >>>>>>>>>>>> ---------------- > >>>>>>>>>>>> > >>>>>>>>>>>> svn:eol-style = native > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> -- > >>>>>>>>>>> Patrick Linskey > >>>>>>>>>>> 202 669 5907 > >>>>>>>>>>> > >>>>>>>>>> > >>>>>> > >>>>>> -- > >>>>>> Patrick Linskey > >>>>>> 202 669 5907 > >>>>>> > >>>>> > >>>>> -- > >>>>> Patrick Linskey > >>>>> 202 669 5907 > >>>>> > >>>>> 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. > > 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! > > -- Patrick Linskey 202 669 5907
