You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@isis.apache.org by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com> on 2013/05/28 18:51:10 UTC
Latest Snapshot and latest release
Hi to all.
We are migrating to the latest snapshot our current code, just for testing pre-release.
Main test classes have been moved to "core", as you said on previous emails.
We can use the "old" IsisJRunner code for properly initializing the Isis context on our Tests base class.
Also, as the following annotations have been removed:
import org.apache.isis.viewer.junit.Service;
import org.apache.isis.viewer.junit.Services;
We must manually inject by: getPersistenceSession().getServicesInjector()..injectServicesInto([domainObject, Service, Repository, ...]);
As you said on previous emails, could the current implementation on "org.apache.isis.viewer.junit.internal.ServicesInstallerAnnotatedClass" be used with "little changes" as a standard way of registering Factories, Repositories and other Services simply by annotating them, without needing to add them to the "isis.properties" file ?
Where should the new "ServicesInstaller" be declared?
Seems that the automatic "Service" registration, without the need to update the "isis.services" entry on the "isis.properties" is nearly there, but would need to move also that code to the "core" module or another one.
Re: Latest Snapshot and latest release
Posted by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>.
Thanks, Dan, for the email and the effort required to prepare the release.
Seems quite clear on the examples. We will try it.
El 29/05/2013, a las 15:50, Dan Haywood <da...@haywood-associates.co.uk> escribió:
> Hi Oscar,
> Good to see your tracking the latest changes on trunk. (By the way, there
> is a vote underway, so hopefully this will be released by the end of the
> week).
>
> With respect to using the old IsisTestRunner class, can I suggest you now
> stop using that? Instead, I recommend that you use
> the IsisSystemForTestRule class that bootstraps an Isis system with a
> proper JDO backend (rather than the old JUnit in-memory objectstore). This
> is a much more faithful test environment.
>
> I've refactored the example app, you can see an abstract test class here
> [1]; as you can see, you only need to register your services once. An
> example concrete test that subclasses from it is [2]; plenty of other
> examples are in the subpackages under [3].
>
> One thing to be aware of: the database is never torn down once created (the
> Isis system is held on a ThreadLocal). So each test needs to reset
> afterwards. In the example tests I do this in the @After method, but you
> could also use dbUnit or any other approach that makes sense.
>
> HTH
> Dan
>
> [1]
> https://github.com/apache/isis/blob/master/example/application/quickstart_wicket_restful_jdo/integtests/src/test/java/integtests/AbstractIntegTest.java
> [2]
> https://github.com/apache/isis/blob/master/example/application/quickstart_wicket_restful_jdo/integtests/src/test/java/integtests/ToDoItem_title.java
> [3]
> https://github.com/apache/isis/tree/master/example/application/quickstart_wicket_restful_jdo/integtests/src/test/java/integtests
>
>
>
> On 28 May 2013 17:51, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>wrote:
>
>>
>> Hi to all.
>>
>> We are migrating to the latest snapshot our current code, just for testing
>> pre-release.
>>
>> Main test classes have been moved to "core", as you said on previous
>> emails.
>>
>> We can use the "old" IsisJRunner code for properly initializing the Isis
>> context on our Tests base class.
>>
>> Also, as the following annotations have been removed:
>>
>> import org.apache.isis.viewer.junit.Service;
>> import org.apache.isis.viewer.junit.Services;
>>
>> We must manually inject by:
>> getPersistenceSession().getServicesInjector()..injectServicesInto([domainObject,
>> Service, Repository, ...]);
>>
>>
>> As you said on previous emails, could the current implementation on
>> "org.apache.isis.viewer.junit.internal.ServicesInstallerAnnotatedClass" be
>> used with "little changes" as a standard way of registering Factories,
>> Repositories and other Services simply by annotating them, without needing
>> to add them to the "isis.properties" file ?
>>
>> Where should the new "ServicesInstaller" be declared?
>>
>> Seems that the automatic "Service" registration, without the need to
>> update the "isis.services" entry on the "isis.properties" is nearly there,
>> but would need to move also that code to the "core" module or another one.
>>
>>
>>
Re: Latest Snapshot and latest release
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Hi Oscar,
Good to see your tracking the latest changes on trunk. (By the way, there
is a vote underway, so hopefully this will be released by the end of the
week).
With respect to using the old IsisTestRunner class, can I suggest you now
stop using that? Instead, I recommend that you use
the IsisSystemForTestRule class that bootstraps an Isis system with a
proper JDO backend (rather than the old JUnit in-memory objectstore). This
is a much more faithful test environment.
I've refactored the example app, you can see an abstract test class here
[1]; as you can see, you only need to register your services once. An
example concrete test that subclasses from it is [2]; plenty of other
examples are in the subpackages under [3].
One thing to be aware of: the database is never torn down once created (the
Isis system is held on a ThreadLocal). So each test needs to reset
afterwards. In the example tests I do this in the @After method, but you
could also use dbUnit or any other approach that makes sense.
HTH
Dan
[1]
https://github.com/apache/isis/blob/master/example/application/quickstart_wicket_restful_jdo/integtests/src/test/java/integtests/AbstractIntegTest.java
[2]
https://github.com/apache/isis/blob/master/example/application/quickstart_wicket_restful_jdo/integtests/src/test/java/integtests/ToDoItem_title.java
[3]
https://github.com/apache/isis/tree/master/example/application/quickstart_wicket_restful_jdo/integtests/src/test/java/integtests
On 28 May 2013 17:51, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>wrote:
>
> Hi to all.
>
> We are migrating to the latest snapshot our current code, just for testing
> pre-release.
>
> Main test classes have been moved to "core", as you said on previous
> emails.
>
> We can use the "old" IsisJRunner code for properly initializing the Isis
> context on our Tests base class.
>
> Also, as the following annotations have been removed:
>
> import org.apache.isis.viewer.junit.Service;
> import org.apache.isis.viewer.junit.Services;
>
> We must manually inject by:
> getPersistenceSession().getServicesInjector()..injectServicesInto([domainObject,
> Service, Repository, ...]);
>
>
> As you said on previous emails, could the current implementation on
> "org.apache.isis.viewer.junit.internal.ServicesInstallerAnnotatedClass" be
> used with "little changes" as a standard way of registering Factories,
> Repositories and other Services simply by annotating them, without needing
> to add them to the "isis.properties" file ?
>
> Where should the new "ServicesInstaller" be declared?
>
> Seems that the automatic "Service" registration, without the need to
> update the "isis.services" entry on the "isis.properties" is nearly there,
> but would need to move also that code to the "core" module or another one.
>
>
>
Re: Latest Snapshot and latest release
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Hi Oscar,
Good to see your tracking the latest changes on trunk. (By the way, there
is a vote underway, so hopefully this will be released by the end of the
week).
With respect to using the old IsisTestRunner class, can I suggest you now
stop using that? Instead, I recommend that you use
the IsisSystemForTestRule class that bootstraps an Isis system with a
proper JDO backend (rather than the old JUnit in-memory objectstore). This
is a much more faithful test environment.
I've refactored the example app, you can see an abstract test class here
[1]; as you can see, you only need to register your services once. An
example concrete test that subclasses from it is [2]; plenty of other
examples are in the subpackages under [3].
One thing to be aware of: the database is never torn down once created (the
Isis system is held on a ThreadLocal). So each test needs to reset
afterwards. In the example tests I do this in the @After method, but you
could also use dbUnit or any other approach that makes sense.
HTH
Dan
[1]
https://github.com/apache/isis/blob/master/example/application/quickstart_wicket_restful_jdo/integtests/src/test/java/integtests/AbstractIntegTest.java
[2]
https://github.com/apache/isis/blob/master/example/application/quickstart_wicket_restful_jdo/integtests/src/test/java/integtests/ToDoItem_title.java
[3]
https://github.com/apache/isis/tree/master/example/application/quickstart_wicket_restful_jdo/integtests/src/test/java/integtests
On 28 May 2013 17:51, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>wrote:
>
> Hi to all.
>
> We are migrating to the latest snapshot our current code, just for testing
> pre-release.
>
> Main test classes have been moved to "core", as you said on previous
> emails.
>
> We can use the "old" IsisJRunner code for properly initializing the Isis
> context on our Tests base class.
>
> Also, as the following annotations have been removed:
>
> import org.apache.isis.viewer.junit.Service;
> import org.apache.isis.viewer.junit.Services;
>
> We must manually inject by:
> getPersistenceSession().getServicesInjector()..injectServicesInto([domainObject,
> Service, Repository, ...]);
>
>
> As you said on previous emails, could the current implementation on
> "org.apache.isis.viewer.junit.internal.ServicesInstallerAnnotatedClass" be
> used with "little changes" as a standard way of registering Factories,
> Repositories and other Services simply by annotating them, without needing
> to add them to the "isis.properties" file ?
>
> Where should the new "ServicesInstaller" be declared?
>
> Seems that the automatic "Service" registration, without the need to
> update the "isis.services" entry on the "isis.properties" is nearly there,
> but would need to move also that code to the "core" module or another one.
>
>
>