Hi Dan, 

I am working on same project with Dharmesh.

Regarding point number 1, 

I have removed the "final" from the method signature to make the code set 
working(as quick workaround)

I am glad to know what impact Isis testing framework brings when we add final 
in method signature

Kind Regards,
Prasad.

> On Mar 3, 2014, at 15:24, Dan Haywood <[email protected]> wrote:
> 
> ah well, so long as it's all now working for you, let's leave it at that.
> 
> Dan
> 
> 
>> On 3 March 2014 15:22, Chohan, Dharmesh <[email protected]> wrote:
>> 
>> Hi Dan
>> 
>> 1. I am not sure what has changed apart from the method is now defined as,
>> public List<Card> listAll() {
>>        return container.allInstances(Card.class);
>>    }
>> 
>> 2. The problem is fixed, I only see single statement in console output.
>> 
>> Regards
>> Dharmesh
>> 
>> -----Original Message-----
>> From: Dan Haywood [mailto:[email protected]]
>> Sent: Monday, March 03, 2014 12:26 PM
>> To: users
>> Subject: Re: Integration testing
>> 
>>> On 3 March 2014 12:09, Chohan, Dharmesh <[email protected]> wrote:
>>> 
>>> Hi Dan
>>> 
>>> 1. The issue has been solved, there was a change in the file.
>> 
>> I'm keen to know a bit more about your fix, cos I'm puzzled what happened
>> here originally  Can you provide more info?
>> 
>> 
>> 
>> 2. I have modified the logging.properties but the console ouput is still
>>> the same.
>> I forgot to say explicitly... there are actually two logging.properties
>> files.  There's the one in WEB-INF (as used by the app), and there's the
>> one in the root directory of the integtest module.
>> 
>> Did you change both?
>> 
>> Dan
>> 
>> 
>> 
>>> Thanks
>>> Dharmesh
>>> 
>>> -----Original Message-----
>>> From: Dan Haywood [mailto:[email protected]]
>>> Sent: Monday, March 03, 2014 11:17 AM
>>> To: users
>>> Subject: Re: Integration testing
>>> 
>>>> On 3 March 2014 10:49, Chohan, Dharmesh <[email protected]>
>>> wrote:
>>> 
>>>> Hi
>>>> 
>>>> I am running some integration test and I have noticed some behaviour
>>>> that I do not understand.
>>>> 
>>>> 1.      The following is the output from running the "mvn clean
>> install"
>>>> command.  The test seems to pass but then I am getting the following
>>> error.
>>>> This is the method called from the test,
>>>> 
>>>>   public final List<Card> listAll() {
>>>>           return allInstances(Card.class);
>>>>       }
>>>> 
>>>>   8 Scenarios (8 passed)
>>>>   24 Steps (24 passed)
>>>>   0m5.731s
>>>> 
>>>>   Tests run: 32, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>>>> 10.852 sec
>>>>   Running integration.tests.smoke.EnterTopUpDetailsTest
>>>>   Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
>>>> 0.14 sec <<< FAILURE!
>>>> 
>>>>   Results :
>>>> 
>>>>   Tests in error:
>>>>     listAll(integration.tests.smoke.EnterTopUpDetailsTest): Method
>>>> 'allInstances' being invoked does not correspond to any of the
>>>> object's fields or actions.
>>> Hmm, I can explain that message, but I'm not exactly sure how it came
>>> to be called.
>>> 
>>> The message is thrown by the wrapped object, so I'm guessing that the
>>> repository being called is wrapped.  The "listAll" method is called on
>>> the wrapping proxy object that then delegates down to the underlying
>>> wrapped domain object.
>>> 
>>> What then seems to be happening is that the domain object is somehow
>>> (and I can't quite see how) calling allInstances() back on the wrapping
>> proxy.
>>> 
>>> Now allInstances is a protected method inherited from
>>> AbstractContainedObject, and protected methods are not recognized as
>>> actions (they must be public).  The proxy is therefore complaining
>>> that it can't find this action.
>>> 
>>> The workaround would be to override allInstances in your repository
>>> and make it public, or - as you do below - to delegate to the DOC.
>>> But - as I say - I can't quite see how the wrapped domain object ends
>>> up calling back on the wrapping proxy.
>>> 
>>> 
>>> 
>>> 
>>>> 
>>>> In the same class file I am injecting the DomainObjectContainer
>>>> object with name container.  If I modify the return statement to the
>>>> following, then I get a different error.
>>>> 
>>>> public final List<Card> listAll() {
>>>>        return container.allInstances(Card.class);
>>>>    }
>>>> 
>>>> 8 Scenarios (1 failed, 7 passed)
>>>> 24 Steps (1 failed, 2 skipped, 21 passed) 0m5.221s
>>>> 
>>>> java.lang.NullPointerException
>>>>        at
>>> net.atos.tfgm.services.CardService.listAll(CardService.java:88)
>>>>        at
>>> integration.glue.simple.EnterTopUpDetailsGlue$1.<init>(EnterTopUpDetai
>>> lsGlue.java:74)
>>>>        at
>>> integration.glue.simple.EnterTopUpDetailsGlue.There_are_initially_Smar
>>> tis_cards(EnterTopUpDetailsGlue.java:72)
>>>>        at ?.Given There are initially 3 Smartis
>>>> cards(integration/specs/simple/EnterTopUpDetailsSpec_listAllAndCreate.
>>>> feature:28)
>>> This looks to me that the container field isn't injected, so its a
>>> simple NPE.  Since you are inheriting from AbstractContainedObject,
>>> use
>>> getContainer() instead.
>>> 
>>> 
>>> 
>>> 
>>>> 2.      The second issue I have seen in the console output is that the
>>>> fixtures are getting called 3 times for everything, i.e. create
>>>> table, inserts and selects.  I am not sure if there is something in
>>>> configuration file that needs changing?
>>>> 
>>>>   10:40:59,946  [Native               main       DEBUG]  INSERT INTO
>>>> "Card"
>>>> ("expiryDate","cardId","category","type","cardNumber","status","vers
>>>> io
>>>> n")
>>>> VALUES
>> (<2014-03-03>,<633597111>,<'ITSO'>,<null>,<'123456789111'>,<'Live'>,<1>)
>>>>   10:40:59,946  [Native               main       DEBUG]  INSERT INTO
>>>> "Card"
>>>> ("expiryDate","cardId","category","type","cardNumber","status","vers
>>>> io
>>>> n")
>>>> VALUES
>> (<2014-03-03>,<633597111>,<'ITSO'>,<null>,<'123456789111'>,<'Live'>,<1>)
>>>>   10:40:59,946  [Native               main       DEBUG]  INSERT INTO
>>>> "Card"
>>>> ("expiryDate","cardId","category","type","cardNumber","status","vers
>>>> io
>>>> n")
>>>> VALUES
>> (<2014-03-03>,<633597111>,<'ITSO'>,<null>,<'123456789111'>,<'Live'>,<1>)
>>>>   1
>>> It's only called once, it's just that the logging is setup
>> incorrectly....
>>> the log4j.additivity clause was missing.
>>> 
>>> Modify your logging.properties for DataNucleus to read:
>>> 
>>> 
>>> # DataNucleus
>>> 
>>> # these are the two most useful ones
>>> # Native shows DML SQL, Schema shows DDL SQL
>>> log4j.logger.DataNucleus.Datastore.Native=DEBUG, Console
>>> log4j.logger.DataNucleus.Datastore.Schema=DEBUG, Console
>>> 
>>> # typically leave the remainder as WARN or ERROR.
>>> log4j.logger.DataNucleus.Persistence=WARN, Console
>>> log4j.logger.DataNucleus.Transaction=WARN, Console
>>> log4j.logger.DataNucleus.Connection=WARN, Console
>>> log4j.logger.DataNucleus.Query=WARN, Console
>>> log4j.logger.DataNucleus.Cache=WARN, Console
>>> log4j.logger.DataNucleus.MetaData=WARN, Console
>>> log4j.logger.DataNucleus.Datastore=WARN, Console
>>> log4j.logger.DataNucleus.Datastore.Persist=WARN, Console
>>> log4j.logger.DataNucleus.Datastore.Retrieve=WARN, Console
>>> log4j.logger.DataNucleus.General=WARN, Console
>>> log4j.logger.DataNucleus.Lifecycle=WARN, Console
>>> log4j.logger.DataNucleus.ValueGeneration=WARN, Console
>>> log4j.logger.DataNucleus.Enhancer=WARN, Console
>>> log4j.logger.DataNucleus.SchemaTool=ERROR, Console
>>> log4j.logger.DataNucleus.JDO=WARN, Console
>>> log4j.logger.DataNucleus.JPA=ERROR, Console
>>> log4j.logger.DataNucleus.JCA=WARN, Console
>>> log4j.logger.DataNucleus.IDE=ERROR, Console
>>> 
>>> log4j.additivity.DataNucleus.Datastore.Native=false
>>> log4j.additivity.DataNucleus.Datastore.Schema=false
>>> log4j.additivity.DataNucleus.Datastore.Persistence=false
>>> log4j.additivity.DataNucleus.Datastore.Transaction=false
>>> log4j.additivity.DataNucleus.Datastore.Connection=false
>>> log4j.additivity.DataNucleus.Datastore.Query=false
>>> log4j.additivity.DataNucleus.Datastore.Cache=false
>>> log4j.additivity.DataNucleus.Datastore.MetaData=false
>>> log4j.additivity.DataNucleus.Datastore.Datastore=false
>>> log4j.additivity.DataNucleus.Datastore.Datastore.Persist=false
>>> log4j.additivity.DataNucleus.Datastore.Datastore.Retrieve=false
>>> log4j.additivity.DataNucleus.Datastore.General=false
>>> log4j.additivity.DataNucleus.Datastore.Lifecycle=false
>>> log4j.additivity.DataNucleus.Datastore.ValueGeneration=false
>>> log4j.additivity.DataNucleus.Datastore.Enhancer=false
>>> log4j.additivity.DataNucleus.Datastore.SchemaTool=false
>>> log4j.additivity.DataNucleus.Datastore.JDO=false
>>> log4j.additivity.DataNucleus.Datastore.JPA=false
>>> log4j.additivity.DataNucleus.Datastore.JCA=false
>>> log4j.additivity.DataNucleus.Datastore.IDE=false
>>> 
>>> 
>>> 
>>> and see if that fixes the issue.  Hopefully it will, this is the fix
>>> going forward in 1.4.0-snapshot and will be in the next archetype we
>>> release
>>> 
>>> HTH
>>> Dan
>>> 
>>> 
>>> 
>>>> Thanks
>>>> Dharmesh
>> 

Reply via email to