David Lloyd wrote:
Paul Robinson wrote:
David,
My current thoughts are that we can get classloading to do most of the heavy-lifting here and prevent too-much disruption of the Narayana code-base. Are you able to take a look at the "Overview of the solution" section and let me know if you think I am heading in the right direction? I suspect the main problem would be that we are simplifying the development work at the cost of performance and memory footprint due to there being two TMs running.
Thanks,
Paul.
One thing I want to point out here is that a key use case of the new streamlined management system is making embedded use of the server infrastructure easier (and by easier I mean "humanly possible"). So assuming we prove out this idea, the class loading solution can never be more than temporary (else I'll have to hack up some kind of infrastructure to replicate modules, which could be quite ugly - and if effort is spent I'd rather it be done to improve a thing rather than add odd one-off hacks).
I probably don't understand enough about how the "embeded use of the server infrastructure" would work, but here's my understanding:
There will be a separate project (to WildFly) containing the kernel of the AS. This will contain just enough to manage the lifecycle of installed Subsystems, provide management functionality and some other low-level things. There will then be other projects that build on this infrastructure; one such project being WildFly. In the WildFly case, a number of subsystems would be provided that when installed in the "kernel" would provide the Application Server as we currently know it. Any java libraries required by this kernel would be used just by it and not be visible in the class loaders used by the installed Subsystems.
So, assuming what I say above is mostly correct, I would see MSC in the "kernal" having a dependency on ArjunaCore with a TransactionManager and Recovery Manager initialized and running in the kernel's class loader. I would then imagine that subsystems installed in the kernel, would use JBoss Modules to manage their dependencies. In which case, any subsystem (or application) could depend on the current org.jboss.jts module if transactions which would run in a different class loader and thus be isolated from the kernel's instance of ArjunaCore.