Glen, It builds OK now.
I have updated to the trunk but the test is still showing its not refreshing the association. Are we on hibernate or EclipseLink? Cheers Greg On 31 July 2013 13:14, Glen Mazza <glen.ma...@gmail.com> wrote: > Just one failure as a result of the update (mvn clean install worked > before it). And some typos. :) > > BTW, the new database script you created, would you mind moving it to > test/resources/sql folder? (like we have main/resources/sql already?) > > Also, I'm usually on the #roller IRC so you might want to join if you have > any quick questions. > > Thanks, > Glen > > testUserAttributeCRUD(org.**apache.roller.weblogger.**business.UserAttributeTest) > Time elapsed: 0.11 sec <<< ERROR! > java.lang.NullPointerException > at org.apache.roller.weblogger.**business.jpa.** > JPAUserManagerImpl.removeUser(**JPAUserManagerImpl.java:75) > at org.apache.roller.weblogger.**TestUtils.teardownUser(** > TestUtils.java:227) > at org.apache.roller.weblogger.**business.UserAttributeTest.** > testUserAttributeCRUD(**UserAttributeTest.java:75) > at sun.reflect.**NativeMethodAccessorImpl.**invoke0(Native Method) > at sun.reflect.**NativeMethodAccessorImpl.**invoke(** > NativeMethodAccessorImpl.java:**57) > at sun.reflect.**DelegatingMethodAccessorImpl.**invoke(** > DelegatingMethodAccessorImpl.**java:43) > at java.lang.reflect.Method.**invoke(Method.java:601) > at junit.framework.TestCase.**runTest(TestCase.java:176) > at junit.framework.TestCase.**runBare(TestCase.java:141) > at junit.framework.TestResult$1.**protect(TestResult.java:122) > at junit.framework.TestResult.**runProtected(TestResult.java:**142) > at junit.framework.TestResult.**run(TestResult.java:125) > at junit.framework.TestCase.run(**TestCase.java:129) > at junit.framework.TestSuite.**runTest(TestSuite.java:255) > at junit.framework.TestSuite.run(**TestSuite.java:250) > at org.junit.internal.runners.**JUnit38ClassRunner.run(** > JUnit38ClassRunner.java:84) > at org.apache.maven.surefire.**junit4.JUnit4Provider.execute(** > JUnit4Provider.java:252) > at org.apache.maven.surefire.**junit4.JUnit4Provider.** > executeTestSet(JUnit4Provider.**java:141) > at org.apache.maven.surefire.**junit4.JUnit4Provider.invoke(** > JUnit4Provider.java:112) > at sun.reflect.**NativeMethodAccessorImpl.**invoke0(Native Method) > at sun.reflect.**NativeMethodAccessorImpl.**invoke(** > NativeMethodAccessorImpl.java:**57) > at sun.reflect.**DelegatingMethodAccessorImpl.**invoke(** > DelegatingMethodAccessorImpl.**java:43) > at java.lang.reflect.Method.**invoke(Method.java:601) > at org.apache.maven.surefire.**util.ReflectionUtils.** > invokeMethodWithArray(**ReflectionUtils.java:189) > at org.apache.maven.surefire.**booter.ProviderFactory$** > ProviderProxy.invoke(**ProviderFactory.java:165) > at org.apache.maven.surefire.**booter.ProviderFactory.** > invokeProvider(**ProviderFactory.java:85) > at org.apache.maven.surefire.**booter.ForkedBooter.** > runSuitesInProcess(**ForkedBooter.java:115) > at org.apache.maven.surefire.**booter.ForkedBooter.main(** > ForkedBooter.java:75) > > > > On 07/31/2013 08:03 AM, Greg Huber wrote: > >> Glen, >> >> I have made some changes to enable local testing and after updating from >> the trunk nothing is working. >> >> http://repo1.maven.org/ says 501. Why does it not ignore this? :( >> >> Can you see if the tests still work? >> >> Also, I have done the test on the directory and will check this later when >> its back working. >> >> >> Cheers Greg. >> >> On 30 July 2013 21:36, Glen Mazza <glen.ma...@gmail.com> wrote: >> >> Fixed the Eclipselink issue in a way that the code will still work with >>> Hibernate. We'll keep the Hibernate for awhile to see if it has any >>> issues. >>> >>> When we delete a media folder, Eclipselink does indeed remove it from the >>> database (the Flush Mode COMMIT/AUTO had nothing to do with the problem.) >>> The issue is that Eclipselink does not refresh the media folder's >>> parent >>> to remove that deleted media folder from its child directories list. So >>> even though its removed from the database the application would still >>> show >>> the deleted folder whenever you list a parent folder's (for us, "/") >>> children. For the change, I just manually removed the deleted folder >>> from >>> its parent's subfolder list, which Hibernate is fine with. >>> >>> I may want to create a bare-bones example of this on StackOverflow >>> sometime and ask which JPA stack has it right, the losing stack gets a >>> JIRA >>> issue. >>> >>> Glen >>> >>> >>> On 07/30/2013 07:06 AM, Greg Huber wrote: >>> >>> Glen, >>>> >>>> OK, can you make the changes to the trunk so i can switch to hibernate. >>>> >>>> On 30 July 2013 11:47, Glen Mazza <glen.ma...@gmail.com> wrote: >>>> >>>> Much appreciated. I was thinking it may be good for us to run on >>>> >>>>> Hibernate for a few weeks anyway, even if EclipseLink were running >>>>> perfectly, just to see if there are any kinks with it where our code >>>>> needs >>>>> to be tightened up. I can fix EclipseLink's problem in the interim so >>>>> if/when *Hibernate* has a kink, we know we can always immediately flip >>>>> back >>>>> to EclipseLink while fixing the Hibernate issue. >>>>> >>>>> Glen >>>>> >>>>> On 07/30/2013 06:39 AM, Greg Huber wrote: >>>>> >>>>> Glen, >>>>> >>>>>> I was trying to add the usecase but ran into the howto debug issue. I >>>>>> will >>>>>> sort the test if I manage to get the debug working. >>>>>> >>>>>> Cheers Greg >>>>>> >>>>>> On 30 July 2013 11:05, Glen Mazza <glen.ma...@gmail.com> wrote: >>>>>> >>>>>> Let me play with it today before throwing in the towel and going >>>>>> with >>>>>> >>>>>> Hibernate. Even if we jump to Hibernate I still need to figure out >>>>>>> the >>>>>>> EclipseLink matter so our coding is not dependent on one JPA >>>>>>> framework >>>>>>> alone, we should be able to work with both or have a JIRA ticket with >>>>>>> EclipseLink. I'd like to add in a JUnit test case that would have >>>>>>> caught >>>>>>> this regression. >>>>>>> >>>>>>> Glen >>>>>>> >>>>>>> On 07/30/2013 03:31 AM, Greg Huber wrote: >>>>>>> >>>>>>> Glen, >>>>>>> >>>>>>> Commenting out the FlushModeType.COMMIT makes no difference, >>>>>>>> (assumes >>>>>>>> it >>>>>>>> switches to auto). Would have thought that createNamedQuery or >>>>>>>> createQuery >>>>>>>> would behave the same way as they both follow the same logic in >>>>>>>> roller. >>>>>>>> Where one works and one does not, maybe an EclipseLink issue. I am >>>>>>>> no >>>>>>>> expert but with hibernate this does not happen. >>>>>>>> >>>>>>>> For me, eclipse does not have a good track record wrt QA, and with >>>>>>>> orm >>>>>>>> there is just no workaround. It would simpler if we can switch to >>>>>>>> something that works without all this pain. >>>>>>>> >>>>>>>> Cheers Greg >>>>>>>> >>>>>>>> >>>>>>>> On 29 July 2013 14:27, Glen Mazza <glen.ma...@gmail.com> wrote: >>>>>>>> >>>>>>>> This page: >>>>>>>> http://docs.oracle.com/javaee/******<http://docs.oracle.com/javaee/****> >>>>>>>> <http://docs.oracle.com/**javaee/**<http://docs.oracle.com/javaee/**> >>>>>>>> > >>>>>>>> ****6/api/javax/persistence/******<http://docs.oracle.com/** >>>>>>>> javaee/****6/api/javax/****persistence/**<http://docs.** >>>>>>>> oracle.com/javaee/****6/api/**javax/persistence/**<http://docs.oracle.com/javaee/****6/api/javax/persistence/**> >>>>>>>> > >>>>>>>> **<http://docs.oracle.com/******javaee/**6/api/javax/****** >>>>>>>> persistence/**<http://docs.oracle.com/****javaee/**6/api/javax/****persistence/**> >>>>>>>> <http://docs.**oracle.com/**javaee/**6/api/**javax/**persistence/**<http://docs.oracle.com/**javaee/**6/api/javax/**persistence/**> >>>>>>>> > >>>>>>>> <http://docs.**oracle.com/**javaee/**6/api/**javax/**persistence/**<http://oracle.com/javaee/**6/api/**javax/persistence/**> >>>>>>>> <http://docs.**oracle.com/javaee/**6/api/**javax/persistence/**<http://docs.oracle.com/javaee/**6/api/javax/persistence/**> >>>>>>>> > >>>>>>>> >>>>>>>>> FlushModeType.html<http://******do**cs.oracle.com/javaee/6/**** >>>>>>>>> api/** <http://cs.oracle.com/javaee/6/**api/**>< >>>>>>>>> http://cs.oracle.com/**javaee/6/api/**<http://cs.oracle.com/javaee/6/api/**> >>>>>>>>> > >>>>>>>>> <http://docs.oracle.com/****javaee/6/api/**<http://docs.oracle.com/**javaee/6/api/**> >>>>>>>>> <http://docs.**oracle.com/javaee/6/api/**<http://docs.oracle.com/javaee/6/api/**> >>>>>>>>> > >>>>>>>>> javax/persistence/********FlushModeType.html<http://** >>>>>>>>> docs.oracle.com/javaee/6/api/******javax/persistence/****<http://docs.oracle.com/javaee/6/api/****javax/persistence/****> >>>>>>>>> FlushModeType.html<http://**docs.oracle.com/javaee/6/api/*** >>>>>>>>> *javax/persistence/****FlushModeType.html<http://docs.oracle.com/javaee/6/api/**javax/persistence/**FlushModeType.html> >>>>>>>>> > >>>>>>>>> <http://**docs.oracle.com/**javaee/6/api/**javax/**persistence/**<http://docs.oracle.com/javaee/6/api/**javax/persistence/**> >>>>>>>>> FlushModeType.html<http://**docs.oracle.com/javaee/6/api/** >>>>>>>>> javax/persistence/**FlushModeType.html<http://docs.oracle.com/javaee/6/api/javax/persistence/FlushModeType.html> >>>>>>>>> > >>>>>>>>> >>>>>>>>>> says >>>>>>>>>> "If |FlushModeType.COMMIT| is set, the effect of updates made to >>>>>>>>>> >>>>>>>>> entities in the persistence context upon queries is unspecified", >>>>>>>>> which >>>>>>>>> is >>>>>>>>> different from the definition of COMMIT below (where it *only* >>>>>>>>> occurs >>>>>>>>> at >>>>>>>>> a >>>>>>>>> transaction commit.) If I understand that correctly, that would >>>>>>>>> mean >>>>>>>>> Roller can't rely on a flush having occurred or not with COMMIT, >>>>>>>>> and >>>>>>>>> EclipseLink and any other JPA implementation is welcome to go >>>>>>>>> either >>>>>>>>> way, >>>>>>>>> and can indeed behave differently between named and dynamic >>>>>>>>> queries, >>>>>>>>> as >>>>>>>>> EclipseLink does. >>>>>>>>> >>>>>>>>> Might the problem be with our code? We're relying on unspecified >>>>>>>>> functionality when we set FlushModeType to COMMIT, and we've been >>>>>>>>> lucky >>>>>>>>> so >>>>>>>>> far that OpenJPA and Hibernate just so happen to flush data (as >>>>>>>>> it's >>>>>>>>> allowed to do per the spec) while EclipseLink is choosing not to. >>>>>>>>> I >>>>>>>>> wonder >>>>>>>>> if we should have new versions of NamedQuery and DynamicQuery that >>>>>>>>> *don't* >>>>>>>>> set it to COMMIT (assuming the default of AUTO is being used >>>>>>>>> otherwise, >>>>>>>>> as >>>>>>>>> specified here: http://www.eclipse.org/**** >>>>>>>>> eclipselink/documentation/2.5/**********<http://www.eclipse.** >>>>>>>>> org/****** <http://www.eclipse.org/******><http://www.eclipse.** >>>>>>>>> org/**** <http://www.eclipse.org/****>> >>>>>>>>> eclipselink/documentation/2.5/********<http://www.eclipse.org/** >>>>>>>>> **** <http://www.eclipse.org/****> >>>>>>>>> eclipselink/documentation/2.5/******<http://www.eclipse.org/**** >>>>>>>>> eclipselink/documentation/2.5/****<http://www.eclipse.org/**eclipselink/documentation/2.5/**> >>>>>>>>> > >>>>>>>>> jpa/extensions/p_persistence_**********context_flushmode.htm)-** >>>>>>>>> -******* >>>>>>>>> *something< >>>>>>>>> http://www.eclipse.**org/******eclipselink/documentation/** >>>>>>>>> 2.5/jpa/extensions/p_********persistence_context_flushmode.****** >>>>>>>>> **htm)--something<http://www.******eclipse.org/eclipselink/** >>>>>>>>> documentation/2.5/jpa/******extensions/p_persistence_** >>>>>>>>> context_flushmode.htm)--******something<http://www.eclipse.**** >>>>>>>>> org/eclipselink/documentation/****2.5/jpa/extensions/p_** >>>>>>>>> persistence_context_flushmode.****htm)--something<http://www.** >>>>>>>>> eclipse.org/eclipselink/**documentation/2.5/jpa/** >>>>>>>>> extensions/p_persistence_**context_flushmode.htm)--**something<http://www.eclipse.org/eclipselink/documentation/2.5/jpa/extensions/p_persistence_context_flushmode.htm)--something> >>>>>>>>> > >>>>>>>>> >>>>>>>>>> that >>>>>>>>>> the Media File stuff could apparently use here. >>>>>>>>>> >>>>>>>>> Glen >>>>>>>>> >>>>>>>>> >>>>>>>>> On 07/29/2013 08:32 AM, Greg Huber wrote: >>>>>>>>> >>>>>>>>> Glen, >>>>>>>>> >>>>>>>>> I think its only on the named queries as if I delete a weblog >>>>>>>>> entry >>>>>>>>> >>>>>>>>>> it >>>>>>>>>> updates correctly, and uses a dynamic query. >>>>>>>>>> >>>>>>>>>> EntityManager em = getEntityManager(false); >>>>>>>>>> Query q = em.createNamedQuery(queryName)**********; >>>>>>>>>> // Never flush for queries. Roller code assumes this behavior >>>>>>>>>> q.setFlushMode(FlushModeType.**********COMMIT); >>>>>>>>>> return q; >>>>>>>>>> >>>>>>>>>> EntityManager em = getEntityManager(false); >>>>>>>>>> Query q = em.createQuery(queryString); >>>>>>>>>> // Never flush for queries. Roller code assumes this >>>>>>>>>> behavior >>>>>>>>>> q.setFlushMode(FlushModeType.**********COMMIT); >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Cheers Greg >>>>>>>>>> >>>>>>>>>> On 29 July 2013 13:14, Glen Mazza <glen.ma...@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>> OK, we can switch to Hibernate for the time being, and it >>>>>>>>>> works >>>>>>>>>> fine >>>>>>>>>> >>>>>>>>>> there, it's as simple a matter as commenting-out the >>>>>>>>>> EclipseLink >>>>>>>>>> >>>>>>>>>> dependency >>>>>>>>>>> and uncommenting the Hibernate one in the app/pom.xml and doing >>>>>>>>>>> an >>>>>>>>>>> mvn >>>>>>>>>>> clean install to get a new WAR. Still, I'd like to fix this >>>>>>>>>>> EclipseLink >>>>>>>>>>> issue, maybe there's some simple setting causing it not to work. >>>>>>>>>>> Note >>>>>>>>>>> our >>>>>>>>>>> EclipseLink is JPA 2.1 vs. Hibernate's (and the OpenJPA's) 2.0, >>>>>>>>>>> that >>>>>>>>>>> might >>>>>>>>>>> be part of the story. >>>>>>>>>>> >>>>>>>>>>> Glen >>>>>>>>>>> >>>>>>>>>>> On 07/29/2013 07:34 AM, Greg Huber wrote: >>>>>>>>>>> >>>>>>>>>>> From google: >>>>>>>>>>> >>>>>>>>>>> "By default, the database flush mode is set to AUTO. This >>>>>>>>>>> means >>>>>>>>>>> that >>>>>>>>>>> >>>>>>>>>>> the >>>>>>>>>>>> Entity-Manager performs a flush operation automatically as >>>>>>>>>>>> needed. >>>>>>>>>>>> In >>>>>>>>>>>> general, this occurs at the end of a transaction for >>>>>>>>>>>> transaction-scoped >>>>>>>>>>>> EntityManagers and when the persistence context is closed for >>>>>>>>>>>> application-managed or extendedscope EntityManagers. In >>>>>>>>>>>> addition, >>>>>>>>>>>> if >>>>>>>>>>>> entities with pending changes are used in a query, the >>>>>>>>>>>> persistence >>>>>>>>>>>> provider >>>>>>>>>>>> will flush changes to the database before executing the query.If >>>>>>>>>>>> the >>>>>>>>>>>> flush >>>>>>>>>>>> mode is set to COMMIT, the persistence provider will only >>>>>>>>>>>> synchronize >>>>>>>>>>>> with >>>>>>>>>>>> the database when the transaction commits.However, you should be >>>>>>>>>>>> careful >>>>>>>>>>>> with this, as it will be your responsibility to synchronize >>>>>>>>>>>> entity >>>>>>>>>>>> state >>>>>>>>>>>> with the database before executing a query. If you don’t do this >>>>>>>>>>>> and >>>>>>>>>>>> an >>>>>>>>>>>> EntityManager<http://docs.**********or**acle.com/javaee/6/api/* >>>>>>>>>>>> ***** <http://acle.com/javaee/6/api/****> >>>>>>>>>>>> ** >>>>>>>>>>>> <http://acle.com/javaee/6/api/******<http://acle.com/javaee/6/api/****> >>>>>>>>>>>> > >>>>>>>>>>>> javax/** >>>>>>>>>>>> <http://acle.com/javaee/6/api/******javax/**<http://acle.com/javaee/6/api/****javax/**> >>>>>>>>>>>> <http://acle.com/**javaee/6/api/**javax/**<http://acle.com/javaee/6/api/**javax/**> >>>>>>>>>>>> > >>>>>>>>>>>> >>>>>>>>>>>>> <http://acle.com/ >>>>>>>>>>>>> >>>>>>>>>>>> **javaee/6/api/javax/** <http://acle.com/javaee/6/api/** >>>>>>>>>>>> **javax/** <http://acle.com/javaee/6/api/**javax/**>< >>>>>>>>>>>> http://acle.com/**javaee/6/api/javax/**<http://acle.com/javaee/6/api/javax/**> >>>>>>>>>>>> > >>>>>>>>>>>> <http://oracle.com/**javaee/6/******api/javax/**<http://oracle.com/**javaee/6/****api/javax/**> >>>>>>>>>>>> <http://**oracle.com/**javaee/6/**api/**javax/**<http://oracle.com/**javaee/6/**api/javax/**> >>>>>>>>>>>> > >>>>>>>>>>>> <http://oracle.**com/**javaee/**6/api/javax/**<http://oracle.** >>>>>>>>>>>> com/**javaee/6/api/javax/**<http://oracle.com/**javaee/6/api/javax/**> >>>>>>>>>>>> > >>>>>>>>>>>> <http://oracle.**com/javaee/6/****api/javax/**<http://oracle.** >>>>>>>>>>>> ** >>>>>>>>>>>> com/javaee/6/api/javax/**<http**://oracle.com/javaee/6/api/** >>>>>>>>>>>> javax/** <http://oracle.com/javaee/6/api/javax/**>> >>>>>>>>>>>> persistence/EntityManager.**********html<http://docs.oracle.** >>>>>>>>>>>> com/** <http://docs.oracle.com/**> >>>>>>>>>>>> ** <http://docs.oracle.com/**> >>>>>>>>>>>> javaee/6/api/javax/**********persistence/EntityManager.****** >>>>>>>>>>>> **html< >>>>>>>>>>>> http://docs.oracle.com/********javaee/6/api/javax/**<http://docs.oracle.com/******javaee/6/api/javax/**> >>>>>>>>>>>> <http://**docs.oracle.com/****javaee/6/**api/javax/**<http://docs.oracle.com/****javaee/6/api/javax/**> >>>>>>>>>>>> > >>>>>>>>>>>> <http://**docs.oracle.com/****javaee/6/**api/javax/**<http://docs.oracle.com/**javaee/6/**api/javax/**> >>>>>>>>>>>> <http:/**/docs.oracle.com/**javaee/6/**api/javax/**<http://docs.oracle.com/**javaee/6/api/javax/**> >>>>>>>>>>>> > >>>>>>>>>>>> persistence/EntityManager.******html<http://docs.oracle.com/** >>>>>>>>>>>> javaee/6/api/javax/******persistence/EntityManager.****html< >>>>>>>>>>>> http://docs.oracle.com/****javaee/6/api/javax/**<http://docs.oracle.com/**javaee/6/api/javax/**> >>>>>>>>>>>> persistence/EntityManager.**html<http://docs.oracle.com/** >>>>>>>>>>>> javaee/6/api/javax/**persistence/EntityManager.html<http://docs.oracle.com/javaee/6/api/javax/persistence/EntityManager.html> >>>>>>>>>>>> **> >>>>>>>>>>>> **> >>>>>>>>>>>> **> >>>>>>>>>>>> **> >>>>>>>>>>>> **> >>>>>>>>>>>> **>query >>>>>>>>>>>> returns stale entities from the database, the application can >>>>>>>>>>>> wind >>>>>>>>>>>> up >>>>>>>>>>>> in an inconsistent state." >>>>>>>>>>>> >>>>>>>>>>>> Did try to change it to auto but made no difference. >>>>>>>>>>>> >>>>>>>>>>>> On 29 July 2013 12:25, Glen Mazza <glen.ma...@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>> OK, I'll check, but what happens if you go to the Roller >>>>>>>>>>>> maintenance >>>>>>>>>>>> tab >>>>>>>>>>>> >>>>>>>>>>>> and click on "Flush blog" (that will normally empty out the >>>>>>>>>>>> cache) -- >>>>>>>>>>>> >>>>>>>>>>>> problem solved then? >>>>>>>>>>>> >>>>>>>>>>>>> Note I had to bring back your changes after the move to fewer >>>>>>>>>>>>> modules, >>>>>>>>>>>>> I >>>>>>>>>>>>> might have missed something. >>>>>>>>>>>>> >>>>>>>>>>>>> Glen >>>>>>>>>>>>> >>>>>>>>>>>>> On 07/29/2013 07:20 AM, Greg Huber wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Glen, >>>>>>>>>>>>> >>>>>>>>>>>>> Can you test whether you can delete a media file folder? >>>>>>>>>>>>> ie >>>>>>>>>>>>> add >>>>>>>>>>>>> a >>>>>>>>>>>>> >>>>>>>>>>>>> folder >>>>>>>>>>>>> >>>>>>>>>>>>>> and then try and delete it. For me it seems to delete it OK >>>>>>>>>>>>>> but >>>>>>>>>>>>>> when >>>>>>>>>>>>>> you >>>>>>>>>>>>>> refresh the media file folder view it is still there. If I >>>>>>>>>>>>>> then >>>>>>>>>>>>>> shut >>>>>>>>>>>>>> down >>>>>>>>>>>>>> tomcat and restart it is gone. It seems something to do with >>>>>>>>>>>>>> its >>>>>>>>>>>>>> cache? >>>>>>>>>>>>>> >>>>>>>>>>>>>> checking: >>>>>>>>>>>>>> >>>>>>>>>>>>>> public Query getNamedQuery(String queryName) >>>>>>>>>>>>>> .... >>>>>>>>>>>>>> q.setFlushMode(FlushModeType.**************COMMIT); >>>>>>>>>>>>>> >>>>>>>>>>>>>> it sets the query to flush on commit, which should in theory >>>>>>>>>>>>>> flush >>>>>>>>>>>>>> the >>>>>>>>>>>>>> query cache when the transaction is committed. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Is there some callback method we need to call to get it to >>>>>>>>>>>>>> flush? >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Cheers Greg >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >
