Brian Stansberry wrote:
> I think it does open up some interesting possibilities for
patching as
> well. If you zip up all the module.xml files in the AS they come to
> 300k, which means that for a 'patch' you could basically just distribute
> a whole new set of modules, and just have the patch tool download any
> jars that are missing into the local repository. This should mean that
> there is no need to use overlays or any sort of layering mechanism.
>
That can work if we rework how the patch staging/application process
works. If a patch is a layer, the new module.xml files can be copied to
disk (staged) but are effectively invisible to jboss-modules until the
process is restarted. If we completely replace the files, we'll have to
do the filesystem replacement work after the system is down.
Either way this question is unrelated to the binaries; i.e. whether
patches add a layer or just completely replace the module.xml files, the
binaries can be handled via a repo.
I actually mean't that a complete set of module.xml files would just be
unzipped in a separate location in the AS (/modules/versions/eap_6.2.54
or whatever). JBoss modules would still need to know which module root
to point at. The main difference would be that each patch is a complete
set of module.xml files.
Stuart