Skip to content
Snippets Groups Projects
  • Tomasz Grabiec's avatar
    f730c54d
    java: do not mask system classes · f730c54d
    Tomasz Grabiec authored
    
    Commit 211bb7fb introduced masking of
    system classes from the isolate point of view in order to prevent
    runjava dependencies form becoming visible, which might cause
    conflicts if application would like to use the same classes but of
    different version. Currently the dependencies include cglib and asm
    which are also used by spring framework and hibernate. Making them
    visible would force the applications to use our version of these
    libraries, which can be older or newer than the required one.
    
    Unfortunately this causes extension classes from jre/lib/ext to be
    unavailable to the application. They are part of the system class
    loader, not bootstrap. One of the side effects is that security
    providers are not found (See issue #208).
    
    This fix chooses another approach to fix the problem. Instead of
    masking dependencies we move them under io.osv.* namespace so that
    they will not cause conflicts. For this task I use apache plugin for
    maven which automatically renames packages in our uber runjava jar.
    
    Fixes #208.
    
    Reviewed-by: default avatarNadav Har'El <nyh@cloudius-systems.com>
    Signed-off-by: default avatarTomasz Grabiec <tgrabiec@cloudius-systems.com>
    Signed-off-by: default avatarPekka Enberg <penberg@cloudius-systems.com>
    f730c54d
    History
    java: do not mask system classes
    Tomasz Grabiec authored
    
    Commit 211bb7fb introduced masking of
    system classes from the isolate point of view in order to prevent
    runjava dependencies form becoming visible, which might cause
    conflicts if application would like to use the same classes but of
    different version. Currently the dependencies include cglib and asm
    which are also used by spring framework and hibernate. Making them
    visible would force the applications to use our version of these
    libraries, which can be older or newer than the required one.
    
    Unfortunately this causes extension classes from jre/lib/ext to be
    unavailable to the application. They are part of the system class
    loader, not bootstrap. One of the side effects is that security
    providers are not found (See issue #208).
    
    This fix chooses another approach to fix the problem. Instead of
    masking dependencies we move them under io.osv.* namespace so that
    they will not cause conflicts. For this task I use apache plugin for
    maven which automatically renames packages in our uber runjava jar.
    
    Fixes #208.
    
    Reviewed-by: default avatarNadav Har'El <nyh@cloudius-systems.com>
    Signed-off-by: default avatarTomasz Grabiec <tgrabiec@cloudius-systems.com>
    Signed-off-by: default avatarPekka Enberg <penberg@cloudius-systems.com>