Hi,
regarding on how to attach the patch, once you've logged into jira, go to
https://issues.apache.org/jira/browse/JSPWIKI-813 and, under the "More"
dropdown button, there should be displayed an "Attach Files" option. I
recall older versions of JIRA having this option on a more visible place,
but this should be enough
thanks for your efforts on providing the patch! :-)
br,
juan pablo
On Thu, Jan 23, 2014 at 8:15 PM, Brian Burch <br...@pingtoo.com> wrote:
> On 23/01/14 17:24, Juan Pablo Santos Rodríguez wrote:
>
>> Hi Brian,
>>
>> just seen you've already filed a JIRA.
>>
>
> Yes. I am fine-tuning the code at this moment, so please wait until I
> attach my proposed change. You can then review it and modify it as you feel
> best.
>
>
> If you want to attach a patch in
>> there,
>>
>
> Attaching a patch file is trivial under bugzilla. I can't find out how to
> do it with a JIRA, but I have stumbled over a recipe on some other
> project's mailing list. Surely a search on JIRA for "how do I attach a
> patch to a JIRA" should come up with an FAQ or wiki page recipe as the
> FIRST hit, rather than a bug against Atlassian from 2006?
>
>
> I'd go for adding TestEngine.emptyWorkDir(null); at setUp().
>>
>
> Yes, that is essential. I thought it was more logical done in tearDown(),
> given that it is a class method which works from the current "combined"
> properties, but that didn't do the job.
>
>
> Also, I
>> would modify TestEngine.emptyWorkDir(Properties props) to check if cache
>> is
>> enabled and, in that case, call CacheManager.getInstance().removalAll();
>>
>
> OK, I think I understand. I assumed that caching would always be enabled
> given the choice of properties taken by the suite, but perhaps your
> suggestion would make the test more bullet-proof?
>
>
> Regarding the page renaming, it was to confirm that those pages
>> specifically where causing the tests failures. Mi idea was to look into
>> other tests for those page name references in order to locate the tests
>> which are not properly cleaning up after execution. However, there are
>> +100
>> occurrences of those pages under src/test/java, so it doesn't seem as
>> something straightforward..
>>
>
> I agree. In the short term it is better to isolate this suite from that
> kind of pollution. We can chase down other cases as they arise.
>
> Oh yes, I have reverted those file name changes. I have also coded a more
> general way to delete all pages in the wiki directory. I think it is better
> placed in the TestEngine class, rather than in
> ReferenceManagerTest.tearDown.
>
> It did occur to me that, rather than each suite sharing the same (or
> nearly) properties, which include explicit directory paths, we ought to
> consider changing the way the suites set themselves up. Probably by
> generating system-unique paths for each test subdirectory.
>
> I just stopped my debugger during setup and looked inside
> jspwiki-war/target/test-classes/. As well as testrepository/ and
> testworkdir/, there are several other directories e.g.
> testrepository1390499022308/ and testworkdir1390499022308/, so some of the
> suites are already doing the kind of "unique runtime environment" trick I
> had in mind. It should be done EVERYWHERE.
>
> Let's just fix this particular bug for now, though.
>
> Look out for my svn patch tomorrow, I hope.
>
> Thanks,
>
> Brian
>
> br,
>> juan pablo
>>
>>
>>
>> On Tue, Jan 21, 2014 at 8:25 PM, Brian Burch <br...@pingtoo.com> wrote:
>>
>> On 21/01/14 17:37, Brian Burch wrote:
>>>
>>> On 21/01/14 16:51, Brian Burch wrote:
>>>>
>>>> On 20/01/14 20:50, Juan Pablo Santos Rodríguez wrote:
>>>>>
>>>>> Hi Brian,
>>>>>>
>>>>>> would mind performing a couple of changes to see if they solve your
>>>>>> build
>>>>>> issue:
>>>>>>
>>>>>> 1) substitute lines 50-63 on setUp at ReferenceManagerTest, with the
>>>>>> following lines:
>>>>>> TestEngine.emptyWorkDir(null);
>>>>>> CacheManager.getInstance().removalAll();
>>>>>>
>>>>>> and then mvn clean install
>>>>>>
>>>>>> 2) change all references to TestPage to another name i.e. replace all
>>>>>> "TestPage" occurences on ReferenceManagerTest with anything else,
>>>>>> like, for
>>>>>> example "RMTestPage". Same for "FooBar" (for example to "RMFooBar"),
>>>>>> and
>>>>>> then mvn clean install. I suspect those two pages are created by other
>>>>>> tests, leaving unwanted data. This doesn't have to be done after first
>>>>>> point, but rather as another independent test, to see if those pages
>>>>>> are
>>>>>> causing the issue by being created and not cleaned up on another test
>>>>>> case
>>>>>>
>>>>>>
>>>>> I have started the second change and it has gone haywire! I'm trying to
>>>>> debug the reason why half the tests are failing.
>>>>>
>>>>> ReferenceManager.findReferrers() uses a null return to signal that it
>>>>> did not find any matching pages.
>>>>>
>>>>> Would you please commit a change to ReferenceManagerTest where EVERY
>>>>> call to findReferrers which expects a non-null value is followed by:
>>>>>
>>>>> assertNotNull("referrers expected", c);
>>>>>
>>>>> I appreciate that these tests would normally have a non-null value
>>>>> assigned to c, but in my broken case the resultant NPE's within jUnit's
>>>>> assertTrue are untidy and a bit confusing.
>>>>>
>>>>> Meanwhile, I will return to figure out what I have done wrong.
>>>>>
>>>>>
>>>> My fault! I didn't realise the pagenames had to be capitalised in this
>>>> test, so I was using things like bbFooBar and they were getting
>>>> capitalised by the engine to BbFooBar.
>>>>
>>>> I am working my way through each test case and adding lots of comments
>>>> as well as the assertNotNull tests. I'll submit a patch file soon.
>>>>
>>>>
>>> OK, Juan Pablo, the second suggestion resolves the failures too. You were
>>> correct in suspecting the rogue files were being left by another test
>>> suite, but I don't know which one.
>>>
>>> The fact that my laptop always failed from a command prompt or under
>>> netbeans, while both cases worked on my desktop, suggests it is a timing
>>> and/or parallelism bug. The desktop is dual-core, while the failing
>>> laptop
>>> is quad-core. The individual processor speeds are about the same.
>>>
>>> I have added a LOT of comments to the test class and tidied-up the
>>> assertions. I think these changes should be committed, but am unsure
>>> about
>>> the best approach.
>>>
>>> 1. Do you think the best solution is 1 or 2 of your suggestions? I think
>>> the cleanest is number 1, because it guarantees the (dirty) page
>>> directory
>>> is emptied out before each test case. Option 2 leaves the clash exposed,
>>> but avoids it for now by using less common page names.
>>>
>>> 2. Should I open a JIRA for the bug and then append my patch? I'm a
>>> little
>>> confused after working on tomcat, where the bugs/enhancements are managed
>>> via apache bugzilla.
>>>
>>> Regards,
>>>
>>> Brian
>>>
>>>
>>> Thanks,
>>>
>>>>
>>>>> Brian
>>>>>
>>>>> thx + br,
>>>>>
>>>>>> juan pablo
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sat, Jan 18, 2014 at 5:32 PM, Craig L Russell
>>>>>> <craig.russ...@oracle.com>wrote:
>>>>>>
>>>>>>
>>>>>> On Jan 18, 2014, at 3:31 AM, Brian Burch wrote:
>>>>>>>
>>>>>>> On 18/01/14 10:32, Harry Metske wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> Brian,
>>>>>>>>>
>>>>>>>>> there is a small mvn cheatsheet in the root of the project (I ask
>>>>>>>>> myself
>>>>>>>>> this same question too every time) :
>>>>>>>>>
>>>>>>>>> http://svn.apache.org/viewvc/jspwiki/trunk/mvn_cheat-sheet.
>>>>>>>>>
>>>>>>>> txt?view=markup
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> So this would be the mvn equivalent: mvn test
>>>>>>>>> -Dtest=org.apache.wiki.ReferenceManagerTest
>>>>>>>>>
>>>>>>>>>
>>>>>>>> In my experience, there's no need to qualify the name of the test.
>>>>>>> Maven
>>>>>>> does a match on the name given, regardless of its fully qualified
>>>>>>> name. So
>>>>>>> the above should be -Dtest=ReferenceManagerTest and should work
>>>>>>> whatever
>>>>>>> the current directory.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Craig
>>>>>>>
>>>>>>>
>>>>>>>> Thanks for your suggestion Harry.
>>>>>>>>
>>>>>>>> 1. It failed "no test found" when I ran it under the highest
>>>>>>>> project. I
>>>>>>>>
>>>>>>>> guessed right that it would work once I cd'ed into the jspwiki-war
>>>>>>> subdirectory.
>>>>>>>
>>>>>>>
>>>>>>>> 2. I set the compiler parameter in front of the "test" goal (I was
>>>>>>>>
>>>>>>>> happier with ant style), rather than after as you suggested. That
>>>>>>> worked
>>>>>>> for me.
>>>>>>>
>>>>>>>
>>>>>>>> 3. The single test suite runs ok under maven from a linux command
>>>>>>>> prompt
>>>>>>>>
>>>>>>>> - all 18 cases successful.
>>>>>>>
>>>>>>>
>>>>>>>> Hmmm. Useful diagnostic information in a negative sort of way.
>>>>>>>>
>>>>>>>> Looks like I need some help choosing break points. Pity I will be
>>>>>>>> forced
>>>>>>>>
>>>>>>>> to run the entire project test suite under netbeans to reproduce
>>>>>>> the
>>>>>>> failure!!!
>>>>>>>
>>>>>>>
>>>>>>>> Brian
>>>>>>>>
>>>>>>>> kind regards,
>>>>>>>>
>>>>>>>>> Harry
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 18 January 2014 11:26, Brian Burch <br...@pingtoo.com> wrote:
>>>>>>>>>
>>>>>>>>> On 18/01/14 01:03, Juan Pablo Santos Rodríguez wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> (changed thread subject in order to not pollute the vote thread)
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Hi Brian,
>>>>>>>>>>>
>>>>>>>>>>> a couple of questions:
>>>>>>>>>>>
>>>>>>>>>>> did you an "mvn install" or "mvn clean install"? if the first,
>>>>>>>>>>> did
>>>>>>>>>>>
>>>>>>>>>>> you do
>>>>>>>>>>
>>>>>>>>>
>>>>>>> it on a fresh copy or over a working copy?
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Clean checkout, then "mvn install".
>>>>>>>>>>
>>>>>>>>>> Just to be paranoid, I have now done "svn update" (nothing
>>>>>>>>>> changed),
>>>>>>>>>>
>>>>>>>>>> "mvn
>>>>>>>>>
>>>>>>>>
>>>>>>> clean install". The same 2 tests fail, although everything else
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> succeeds.
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>> can you run those tests individually on your IDE? maybe there
>>>>>>>>>> is an
>>>>>>>>>>
>>>>>>>>>> issue
>>>>>>>>>
>>>>>>>>
>>>>>>> related to tests execution order
>>>>>>>>
>>>>>>>>> (https://builds.apache.org/job/JSPWiki/does the build fine, as
>>>>>>>>>>> https://analysis.apache.org/jenkins/job/jspwiki/, and I cannot
>>>>>>>>>>>
>>>>>>>>>>> reproduce
>>>>>>>>>>
>>>>>>>>>
>>>>>>> on
>>>>>>>>
>>>>>>>>> my local environment)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I just opened rc2 as a new project under netbeans and ran the
>>>>>>>>>> suite
>>>>>>>>>> org.apache.wiki.ReferenceManagerTest. ALL 18 tests pass.
>>>>>>>>>>
>>>>>>>>>> In my experience, it is less likely to be a suite execution order
>>>>>>>>>>
>>>>>>>>>> problem.
>>>>>>>>>
>>>>>>>>
>>>>>>> Much more likely there is a test case exec order problem.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> I mostly work with ant projects. Can you save me time by telling
>>>>>>>>>> me the
>>>>>>>>>> maven equivalent of the following:
>>>>>>>>>>
>>>>>>>>>> ant -Dtest.entry=org.apache.wiki.ReferenceManagerTest test
>>>>>>>>>>
>>>>>>>>>> so I can see what happens to the test when it is executed on its
>>>>>>>>>> own
>>>>>>>>>> outside my ide?
>>>>>>>>>>
>>>>>>>>>> could you verify you have an
>>>>>>>>>>
>>>>>>>>>> $WORKSPACE/jspwiki-war/target/test-classes/testworkdir/
>>>>>>>>>>> refmgr.ser
>>>>>>>>>>> file
>>>>>>>>>>> when
>>>>>>>>>>> the tests fail?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> That file still exists after the "mvn install" has failed. It is
>>>>>>>>>>
>>>>>>>>>> binary -
>>>>>>>>>
>>>>>>>>
>>>>>>> is there any point looking inside it?
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>>
>>>>>>>>>> Brian
>>>>>>>>>>
>>>>>>>>>> br,
>>>>>>>>>>
>>>>>>>>>> juan pablo
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Jan 17, 2014 at 10:54 AM, Brian Burch <br...@pingtoo.com
>>>>>>>>>>> >
>>>>>>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>> On 15/01/14 20:48, Harry Metske wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> +1
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> kind regards,
>>>>>>>>>>>>> Harry
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I only started working on 2.10 this week, so I don't want to
>>>>>>>>>>>>> spoil
>>>>>>>>>>>>>
>>>>>>>>>>>>> the
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> party!
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>> I checked out the trunk at r1557110 on my main dev machine and
>>>>>>>>>>>> it
>>>>>>>>>>>>
>>>>>>>>>>>> built
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>> and tested perfectly.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>> Yesterday, while preparing for a trip, I checked out the trunk
>>>>>>>>>>>> at
>>>>>>>>>>>> r1559044
>>>>>>>>>>>> on my laptop. mvn install fails two tests.
>>>>>>>>>>>>
>>>>>>>>>>>> Rather than mess around with the evolving trunk, I have just
>>>>>>>>>>>> checked
>>>>>>>>>>>>
>>>>>>>>>>>> out
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>> RC2 on my laptop. The two tests fail in the same way as the trunk.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>> The
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>> following report is taken from RC2:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>> ------------------------------------------------------------
>>>>>>>>>>>> -------------------
>>>>>>>>>>>> Test set: org.apache.wiki.ReferenceManagerTest
>>>>>>>>>>>> ------------------------------------------------------------
>>>>>>>>>>>> -------------------
>>>>>>>>>>>> Tests run: 18, Failures: 0, Errors: 2, Skipped: 0, Time elapsed:
>>>>>>>>>>>>
>>>>>>>>>>>> 0.95 sec
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>> <<< FAILURE! - in org.apache.wiki.ReferenceManagerTest
>>>>>>>>
>>>>>>>>> testUpdateBothExist(org.apache.wiki.ReferenceManagerTest) Time
>>>>>>>>>>>>
>>>>>>>>>>>> elapsed:
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>> 0.063 sec <<< ERROR!
>>>>>>>>
>>>>>>>>> java.lang.NullPointerException: null
>>>>>>>>>>>> at org.apache.wiki.providers.
>>>>>>>>>>>> BasicAttachmentProvider.
>>>>>>>>>>>> deleteAttachment(BasicAttachmentProvider.java:692)
>>>>>>>>>>>> at org.apache.wiki.providers.
>>>>>>>>>>>> CachingAttachmentProvider.
>>>>>>>>>>>> deleteAttachment(CachingAttachmentProvider.java:327)
>>>>>>>>>>>> at org.apache.wiki.attachment.AttachmentManager.
>>>>>>>>>>>> deleteAttachment(
>>>>>>>>>>>> AttachmentManager.java:605)
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>>>>>>>>>> org.apache.wiki.WikiEngine.deletePage(WikiEngine.java:2188)
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>> at org.apache.wiki.ReferenceManagerTest.tearDown(
>>>>>>>>
>>>>>>>>> ReferenceManagerTest.java:76)
>>>>>>>>>>>>
>>>>>>>>>>>> testSelf(org.apache.wiki.ReferenceManagerTest) Time elapsed:
>>>>>>>>>>>> 0.045
>>>>>>>>>>>>
>>>>>>>>>>>> sec
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>> <<< ERROR!
>>>>>>>>
>>>>>>>>> org.apache.wiki.InternalWikiException: Refmgr out of sync: page
>>>>>>>>>>>>
>>>>>>>>>>>> Foobar
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>> refers to Foobars, which has null referrers.
>>>>>>>>
>>>>>>>>> at org.apache.wiki.ReferenceManager.pageRemoved(
>>>>>>>>>>>> ReferenceManager.java:625)
>>>>>>>>>>>> at org.apache.wiki.ReferenceManager.actionPerformed(
>>>>>>>>>>>> ReferenceManager.java:1177)
>>>>>>>>>>>> at org.apache.wiki.event.WikiEventManager$
>>>>>>>>>>>> WikiEventDelegate.fireEvent(WikiEventManager.java:562)
>>>>>>>>>>>> at org.apache.wiki.event.WikiEventManager.fireEvent(
>>>>>>>>>>>> WikiEventManager.java:344)
>>>>>>>>>>>> at
>>>>>>>>>>>>
>>>>>>>>>>>> org.apache.wiki.PageManager.fireEvent(PageManager.java:701)
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>> at
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>> org.apache.wiki.PageManager.deletePage(PageManager.java:548)
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>> at
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>> org.apache.wiki.WikiEngine.deletePage(WikiEngine.java:2191)
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>> at org.apache.wiki.ReferenceManagerTest.tearDown(
>>>>>>>>
>>>>>>>>> ReferenceManagerTest.java:77)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Both systems run ubuntu 13.10 and are fairly similar - the
>>>>>>>>>>>> laptop
>>>>>>>>>>>>
>>>>>>>>>>>> has the
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>> low latency kernel and the desktop uses generic. Both run 32 bit
>>>>>>>>
>>>>>>>>> 3.11.0-15
>>>>>>>>>>>> kernels. I don't think this is a relevant factor.
>>>>>>>>>>>>
>>>>>>>>>>>> Both systems run the same default jdk:
>>>>>>>>>>>> java version "1.7.0_25"
>>>>>>>>>>>> OpenJDK Runtime Environment (IcedTea 2.3.12)
>>>>>>>>>>>> (7u25-2.3.12-4ubuntu3)
>>>>>>>>>>>> OpenJDK Server VM (build 23.7-b01, mixed mode)
>>>>>>>>>>>>
>>>>>>>>>>>> I haven't yet checked out RC2 on my desktop, but I expect it
>>>>>>>>>>>> would
>>>>>>>>>>>>
>>>>>>>>>>>> work.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>
>>>>>>>> Is this a known problem? If not, what can I do to help diagnose it
>>>>>>>>>>>> further?
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>>
>>>>>>>>>>>> Brian
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 14 January 2014 23:08, Juan Pablo Santos Rodríguez <
>>>>>>>>>>>>
>>>>>>>>>>>> juanpablo.san...@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> This is a release vote for Apache JSPWiki, version 2.10.0.
>>>>>>>>>>>>> The
>>>>>>>>>>>>>
>>>>>>>>>>>>> vote
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> will
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>> be
>>>>>>>>>>>>>
>>>>>>>>>>>>>> open for at least 72 hours from now.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It fixes the following issues:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
>>>>>>>>>>>>>> projectId=12310732&version=12323941
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Note that we are voting upon the source (tag), binaries are
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> provided
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>> for
>>>>>>>>
>>>>>>>>> convenience.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Everybody is encouraged to vote.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Source and binary files:
>>>>>>>>>>>>>> http://people.apache.org/~juanpablo/releases/2.10.0-rc2
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Nexus staging repo:
>>>>>>>>>>>>>> https://repository.apache.org/content/repositories/
>>>>>>>>>>>>>> orgapachejspwiki-1000/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The tag to be voted upon:
>>>>>>>>>>>>>> http://svn.apache.org/repos/asf/jspwiki/tags/jspwiki_2_10_
>>>>>>>>>>>>>> 0_rc2
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> JSPWiki's KEYS file containing PGP keys we use to sign the
>>>>>>>>>>>>>> release:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> http://svn.apache.org/repos/asf/jspwiki/tags/jspwiki_2_10_
>>>>>>>>>>>>>>
>>>>>>>>>>>>> 0_rc2/KEYS
>>>>>>>
>>>>>>>
>>>>>>>> *** Please download, test and vote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> [ ] +1 Approve the release
>>>>>>>>>>>>>> [ ] 0 Don't mind
>>>>>>>>>>>>>> [ ] -1 Disapprove the release (please provide specific
>>>>>>>>>>>>>> comments)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> br,
>>>>>>>>>>>>>> juan pablo
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>> Craig L Russell
>>>>>>> Architect, Oracle
>>>>>>> http://db.apache.org/jdo
>>>>>>> 408 276-5638 mailto:craig.russ...@oracle.com
>>>>>>> P.S. A good JDO? O, Gasp!
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>
>>
>
