[Building Sakai] [cle-release-team] Kernel with OpenJDK 7
Earle Nietzel
earle.nietzel at gmail.com
Thu Mar 14 09:33:28 PDT 2013
Hi Ray,
You are correct, tests should not depend on the order in which test methods
are declared. (the order is not guaranteed, and its not good practice)
Changes to reflection in JDK 7 made this more random where JDK <= 6 methods
were returned in the order they were declared.
JUnit has always had the stance that a test should "Stand on its Own", and
is a good practice.
I think the best way to proceed is to make each test independent i.e. where
you can execute each test independently.
Earle
On Sat, Jan 26, 2013 at 9:22 PM, Raymond Naseef <raymond.naseef at gmail.com>wrote:
> I checked Sakai 2.9.0 (trunk) and found cause of the error in this thread
> (from February 22, 2012): dependencies among test methods in 1 class!!!
> The problem is intermittent as the problem is based on what order each of
> the test class's methods are run [i.e., start -> testA() -> testB() OK,
> start -> testB() -> testA() FAILS]. I believe such dependency is
> considered improper for Sakai Project, correct?
>
> DETAILS:
> The failing test method:
> ContentHostingServiceTest#testUtfFolders
> (error on line 198 in trunk -- 2.9.0).
> The need:
> ContentHostingService#addCollection(<utfId>)
> This works after running test method:
> ContentHostingServiceTest#testSaveRetriveFolder()
>
> I recommend the following fix. Please let me know if you would like me to
> do some or all of these.
>
> 1. Change ID of collection in testUtfFolders()
> 2. Calling ContentHostingService.addCollection() in testUtfFolders() to
> create its collection
> <optional> 3. Remove collection from the cache at end of testUtfFolders()
> <optional> 4. Changing ContentHostingServiceTest#testDeleteResource() to
> not log the expected "IdUnusedException"
>
> ERROR DETAILS:
> Sakai CLE 2.9.0 sakai-src-trunk downloaded 2013-01-25:
>
> org.sakaiproject.exception.IdUnusedException id: /admin/??????????/
> at
> org.sakaiproject.content.impl.BaseContentService.checkCollection(BaseContentService.java:2121)
> at
> org.sakaiproject.content.impl.BaseContentService.addResource(BaseContentService.java:3257)
> at
> org.sakaiproject.content.impl.test.ContentHostingServiceTest.testUtfFolders(ContentHostingServiceTest.java:198)
>
>
> All the best,
> Ray
>
>
> >There's also the thorny issue that the use of threadloacal in a service
> >is less than ideal and can lead to memory leaks (and the CHS ones have
> >in the past)
> >
> >D
> >
> On 02/23/2012 04:59 AM, Noah Botimer wrote:
> >> I would say that this thread is sufficiently technical that it belongs
> on the dev list. But to be on topic...
> >>
> >> I've just been looking at caching and was noticing the ThreadLocals
> dropping (it seemed, at least) values with no special characters. The puts
> were issued and subsequent gets in the same thread were falling through. An
> example is in a simple getUserByEid() call for admin. The Ehcache set up
> through the MemoryService (second layer; maybe the first is unneeded in
> this case) was catching all gets in the "call cache".
> >>
> >> This is unrelated to OpenJDK or JDK7, as I am using sun-java6-jdk on
> Ubuntu 11.10. So, there may be a couple of things to pull apart here:
> general ThreadLocal behavior on standard infrastructure and JDK7 effect on
> ThreadLocal behavior / UTF8 strings / queries.
> >>
> >> Thanks,
> >> -Noah
> >>
> >> On Feb 22, 2012, at 9:43 PM, Earle Nietzel wrote:
> >>
> >>> Sam,
> >>>
> >>> I now understand why this test is failing but I am not sure how to fix
> it:
> >>>
> >>> It is all related to this method in BaseContentService:
> >>>
> >>> protected ContentCollection findCollection(String id) throws
> TypeException
> >>> {
> >>> ContentCollection collection = null;
> >>> try
> >>> {
> >>> collection = (ContentCollection)
> >>> threadLocalManager.get("findCollection@" + id);
> >>>
> >>> This returns null since it doesn't find the key in
> >>> ThreadLocalComponent bindings map.
> >>> WARN ThreadLocalComponent:183 - get: key not found:
> >>> findCollection@/admin/??????????/
> >>>
> >>> }
> >>> catch(ClassCastException e)
> >>> {
> >>> throw new TypeException(id);
> >>> }
> >>>
> >>> if(collection == null)
> >>> {
> >>> collection = m_storage.getCollection(id);
> >>>
> >>> Then it tries to perform a lookup from storage but this also fails
> >>> because ThreadLocalComponent does not contain the following key.
> >>> WARN ThreadLocalComponent:183 - get: key not found:
> >>> sqlService:transaction_connection
> >>>
> >>> if(collection != null)
> >>> {
> >>> threadLocalManager.set("findCollection@" + id, collection); // new
> >>> BaseCollectionEdit(collection));
> >>> }
> >>> }
> >>> else
> >>> {
> >>> collection = new BaseCollectionEdit(collection);
> >>> }
> >>>
> >>> return collection;
> >>>
> >>> } // findCollection
> >>>
> >>> Then the following exception occurs:
> >>> org.sakaiproject.exception.IdUnusedException id=/admin/??????????/
> >>> at
> org.sakaiproject.content.impl.BaseContentService.checkCollection(BaseContentService.java:2230)
> >>>
> >>> To me it looks as though ThreadLocalComponent did not get setup
> properly.
> >>>
> >>> Funny part about all of this is I cannot reproduce this in the
> >>> debugger remotely connected to maven surefire
> >>>
> >>> mvn test -Dtest=ContentHostingServiceTest -DfailIfNoTests=false
> >>> -Dmaven.surefire.debug
> >>>
> >>> but when running without debugging it happens almost every time:
> >>>
> >>> mvn test -Dtest=ContentHostingServiceTest -DfailIfNoTests=false
> >>>
> >>> Suggestions?
> >>>
> >>> Earle
> >>>
> >>> On Wed, Feb 22, 2012 at 12:27 AM, Earle Nietzel <earle.nietzel at
> gmail.com> wrote:
> >>>> Hey Sam,
> >>>>
> >>>> I was able to get 2/3 tests fixed. The last one is taking a little
> >>>> longer since I can't even reproduce in eclipse.
> >>>>
> >>>> Only happens when building from the console.
> >>>>
> >>>> Here is the failing test from kernel-impl:
> >>>> ContentHostingServiceTest.testUtfFolders
> >>>>
> >>>> You can run it with:
> >>>> mvn test -Dtest=ContentHostingServiceTest -DfailIfNoTests=false
> >>>>
> >>>> I will continue to look at it,
> >>>> Earle
> >>>>
> >>>> On Tue, Feb 21, 2012 at 4:51 PM, Sam Ottenhoff <ottenhoff at
> longsight.com> wrote:
> >>>>> Cool, thanks.
> >>>>>
> >>>>> --Sam
> >>>>>
> >>>>>
> >>>>> On Tue, Feb 21, 2012 at 4:49 PM, Earle Nietzel <earle.nietzel at
> gmail.com>
> >>>>> wrote:
> >>>>>> I will investigate, thanks for pointing it out.
> >>>>>>
> >>>>>> Earle
> >>>>>>
> >>>>>> On Tue, Feb 21, 2012 at 3:38 PM, Sam Ottenhoff <ottenhoff at
> longsight.com>
> >>>>>> wrote:
> >>>>>>> What about tests on the kernel? My local Jenkins is reporting a
> test
> >>>>>>> failure in org.sakaiproject.kernel:sakai-kernel-impl
> >>>>>>>
> >>>>>>>
> >>>>>>> On Tue, Feb 21, 2012 at 2:46 PM, Earle Nietzel <earle.nietzel at
> gmail.com>
> >>>>>>> wrote:
> >>>>>>>> Yes everything is compiling as expected by changing the version
> in bot
> >>>>>>>> the master and kernel poms. I will add some more notes to the
> JIRA.
> >>>>>>>>
> >>>>>>>> Tested with OpenJDK 6 and 7.
> >>>>>>>>
> >>>>>>>> Earle
> >>>>>>>>
> >>>>>>>> On Tue, Feb 21, 2012 at 2:12 PM, Sam Ottenhoff
> >>>>>>>> <ottenhoff at longsight.com>
> >>>>>>>> wrote:
> >>>>>>>>> Hey Earle,
> >>>>>>>>>
> >>>>>>>>> Thanks for all of your work on compilation issues. It's much
> >>>>>>>>> appreciated.
> >>>>>>>>> Have you been able to compile the kernel against OpenJDK 7?
> >>>>>>>>>
> >>>>>>>>> Thanks,
> >>>>>>>>> Sam
> >>>>>>>
> >>>>>
> >>> _______________________________________________
> >>> cle-release-team mailing list
> >>> cle-release-team at collab.sakaiproject.org
> >>> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
> >> _______________________________________________
> >> cle-release-team mailing list
> >> cle-release-team at collab.sakaiproject.org
> >> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
>
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to
> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
> "unsubscribe"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20130314/1362d689/attachment.html
More information about the sakai-dev
mailing list