[Building Sakai] [cle-release-team] Kernel with OpenJDK 7
Aaron Zeckoski
azeckoski at unicon.net
Thu Mar 14 09:38:11 PDT 2013
In the case mentioned, I think the solution is actually to merge those
2 test methods into one. They seem to actually depend on each other.
-AZ
On Thu, Mar 14, 2013 at 12:33 PM, Earle Nietzel <earle.nietzel at gmail.com> wrote:
> 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"
>
>
>
> _______________________________________________
> cle-release-team mailing list
> cle-release-team at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
>
--
Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
More information about the sakai-dev
mailing list