Thanks Jörg and Vladimir for your feedback! Addressing your comments ...
Apache Isis (the framework itself) will rely on having 'Spring Data' on the class-path. The application bootstrapping however, is done by the application code. Meaning you can write your Spring Application anyway you like. Only thing to do for the application code is to let Spring 'discover' the 'Isis Framework Module'. This will rely on Spring's class-path scanning, yes. Discovery of the 'Isis Framework Module' will result in getting the framework's beans (singletons, context-scoped services, bean-producers, ...) provisioned by Spring. Consequently Spring will manage all your 'Domain Objects' and almost all 'Isis Services', such that you can inject (@Inject or @Autowire) any Bean into any Bean managed by Spring. Yes, this includes persistent entities as well. Regarding nested transactions: We are planning to delegate persistence and transaction-handling entirely to 'Spring Data'. We hope, that we can remove Isis' 'TransactionManager' and fully rely on your application code to use Spring's 'Transaction-API'. All this leaves some open questions: a) How hard will it be, to migrate existing projects away from JDO. Or is there any hope for a 'spring-data-jdo' module. Maybe we should ask Andy Jefferson (main contributor to DataNucleus), or maybe someone wants to do the work or fund this one. b) 'Transaction handling' appears to be the major problem currently left to be solved within 'v2' development. As said before, the framework was initially built around JDO, with the idea of having only a single persistence context (PC) and having transactions only associated with this single PC. Business logic annotated with @Action (as provided by Isis) were automatically wrapped with transactions. But with 'Spring Data' provided transactions, it is yet unclear how to redisign/extend the @Action annotation. Meta annotations come to mind, but still, how to get this right, to support multiple persistence contexts? c) Isis' background execution was originally designed without an API that would allow to have the UI present any real-time feedback on background task progress (eg. allow for a progress-bar or a 'task cancel button'). Since background execution also involves transactions, it is deeply related to b) and suggests a proper redesign. Its also unclear how this new API should look like. d) 'Integration Test Support' will most likely utilize 'Spring Boot', so for existing projects there is possibly some migration work to do as well. Cheers, Andi! On 2019/03/28 10:04:43, Andi Huber <ahu...@apache.org> wrote: > Hi folks, > > to keep you in the loop, we are currently re-platforming Isis on top of the > latest Spring release. First thought was to make Spring integration a > plug-able feature, but by having a closer look at how Spring handles > persistence and especially transactions, it has now become clear, that we > want to go all-in with Spring, and fully utilize Spring Data. This will not > be optional but mandatory. > > This move has some profound consequences. Isis was initially built around > JDO, which we will no longer support. We instead delegate any JDO concerns to > the Spring community. Sadly there is no 'spring-data-jdo' module [1] yet, and > it appears that there wont be one in the near future [2]. > > Also at the moment it is not clear, whether Isis' builtin domain-event will > be still supported with a v2 release. Spring's event API is much more > powerful, why not just use that instead. However, we will have a look at > whether its doable to provide some kind of backward compatibility. > > Also persistence and transactions [3] do work differently in Spring Data, > than what you might be used to when using JDO. Its very likely that we'll > drop eg. the 'RepositoryService'. > > All these changes for Isis appear necessary to stay relevant as a platform. > We hope to have a 2.0.0-M3 milestone-release ready around Q3 to showcase Isis > powered by Spring. > > In case you really need Jdo support, the way to go is to help the Spring > community and implement the missing 'spring-data-jdo' module. This should not > be to hard in terms of lines of code required. > > Cheers, Andi! > > [1] https://github.com/spring-projects/spring-framework/issues/18702 > [2] https://jira.spring.io/browse/DATACMNS-96 > [3] > https://docs.spring.io/spring/docs/current/spring-framework-reference/data-access.html#spring-data-tier > > > > > > > > >
