Andrew Rubinger wrote:
I've actually been giving this some thought, too, but left it out of this discussion for the time-being. Now that you raise it, what the hell. :)
If we were to build out a remote repository of modules (much like Maven Central), it'd open the door to on-demand installation of services into JBossAS. Carlo used to envision something like a "yum" or "apt-get" feature which could map a named service into a series of dependencies to be brought in and installed.
Additionally, we could perform upgrades of running services; it'd even be possible to have two versions of the same subsystem running concurrently in a single VM, provided we worked out a way to synchronize access to shared external resources (like ports). It'd be nice to have a user application A running on JBossWeb version X alongside user application B running on JBossWeb version Y; users wouldn't have to touch application A until they're ready. To some extent this is already possible by bundling frameworks inside the deployment.
The real value-add for me here is that we'd essentially be able to match what RHN (Red Hat Network) does for RHEL - provide a subscription service to push one-click upgrades to all servers in a Domain or ServerGroup.
One obvious hitch I see is the use of "main" as a default; I suspect that modules would have to become more explicit about the versions they depend upon. As it stands, JBossAS ships with a single module repository populated with the versions it needs - we'd have to expand this notion such that all modules would be aware that they could be housed in a much more expansive repository (which would grow over time) and be explicit about their versioned dependencies.
Has any of the above been discussed/planned in the context of JBossAS.next?
S,
ALR
Yeah, I've been giving this a lot of thought but there's nothing concrete yet. I hope to spend some time on this idea next year though.