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.
On 2019/03/28 10:04:43, Andi Huber <[EMAIL PROTECTED]> wrote: