tapestry-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Luca Arzeni (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (TAP5-2592) Classloader issues under JBoss 6.X - 7.X (and I guess it affects most other application servers) - patch included
Date Mon, 04 Dec 2017 09:43:00 GMT

     [ https://issues.apache.org/jira/browse/TAP5-2592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Luca Arzeni updated TAP5-2592:
------------------------------
    Summary: Classloader issues under JBoss 6.X - 7.X (and I guess it affects most other application
servers) - patch included  (was: Classloader issues under JBoss 6.X - 7.X (and I guess it
affects most other application servers))

> Classloader issues under JBoss 6.X - 7.X (and I guess it affects most other application
servers) - patch included
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: TAP5-2592
>                 URL: https://issues.apache.org/jira/browse/TAP5-2592
>             Project: Tapestry 5
>          Issue Type: Bug
>          Components: plastic
>    Affects Versions: 5.3.8, 5.4.1, 5.4.2, 5.4.3
>            Reporter: Luca Arzeni
>            Priority: Minor
>              Labels: patch
>
> few years ago, I raised an alert concerning the compatibility between Tapestry5 and JBoss;
the thread was: 
> "Is tapestry plastic incompatible with JEE specs?" 
> https://mail-archives.apache.org/mod_mbox/tapestry-users/201512.mbox/%3Ctrinity-fc3b0e36-0402-4d71-b48a-4a464cbd6474-1449857158334@3capp-mailcom-lxa14%3E
> At that time I found a workaround and concluded that there was no way to solve the issue,
thinking that was a problem related to the jboss classloader (or, more generally, between
an appserver classloader and the behaviour of plastic). 
> Few days ago, working on a new project under JBoss 7.0.0.GA, I was again badly hitted
by this problem, but this time I investigated more thoroughly the issue and I found the source
of all evil: the class "org.apache.tapestry5.internal.plastic.asm.ClassWriter" of plastic.

> The classloader used to find (and load) the classes by plastic is really not compatible
with an appserver. An appserver is required to enforce classloaded isolation and plastic ignores
this. 
> Anyway plastic can be patched to solve the issue; here I attach a patch, please I ask
to some developer to kindly forward and apply this patch to the 5.4.x branch and to the 5.5.

> I also want to give thanks to these guys to help me to focus the problem: 
> https://stackoverflow.com/questions/42423907/unable-to-move-tapestry-jars-out-of-the-war-with-page-code-inside-the-war-still
> https://blog.progs.be/50/tapestry-classloading-problems-on-jboss
> Regards, 
> Luca Arzeni 
> *** Here is the original code: *** 
> 1752     protected String getCommonSuperClass(final String type1, final String type2)
{ 
> 1753         Class<?> c, d; 
> 1754         ClassLoader classLoader = getClass().getClassLoader(); 
> 1755         try { 
> 1756             c = Class.forName(type1.replace('/', '.'), false, classLoader); 
> 1757             d = Class.forName(type2.replace('/', '.'), false, classLoader); 
> 1758         } catch (Exception e) { 
> 1759             throw new RuntimeException(e.toString()); 
> 1760         } 
> 1761         if (c.isAssignableFrom(d)) { 
> 1762             return type1; 
> 1763         } 
> 1764         if (d.isAssignableFrom(c)) { 
> 1765             return type2; 
> 1766         } 
> 1767         if (c.isInterface() || d.isInterface()) { 
> 1768             return "java/lang/Object"; 
> 1769         } else { 
> 1770             do { 
> 1771                 c = c.getSuperclass(); 
> 1772             } while (!c.isAssignableFrom(d)); 
> 1773             return c.getName().replace('.', '/'); 
> 1774         } 
> 1775     } 
> *** Here is the patch: *** 
> 1752    protected String getCommonSuperClass(final String type1, final String type2)
{ 
> 1753        Class<?> c, d; 
> 1754        ClassLoader classLoader = getClass().getClassLoader(); 
> 1755        try { 
> 1756            c = Class.forName(type1.replace('/', '.'), false, classLoader); 
> 1757            d = Class.forName(type2.replace('/', '.'), false, classLoader); 
> 1758        } catch (Exception e) { 
> // --- ARZILLO PATCH BEGIN -----------------------------------------------------------

>     System.err.println("WARNING: type1:" + type1 + ", type2: " + type2 + ", exception:
" + e + ", classLoader: " + classLoader +", attempting to use the classloader of the current
thread"); 
>     classLoader = Thread.currentThread().getContextClassLoader(); 
>         if ( classLoader != null ) { 
>         try { 
>         c = Class.forName(type1.replace('/', '.'), false, classLoader); 
>         d = Class.forName(type2.replace('/', '.'), false, classLoader); 
>         } 
>                 catch (Exception e_inner) { 
>             System.err.println("ERROR 1: type1:" + type1 + ", type2: " + type2 + ", e_inner:
" + e_inner + ", classLoader: " + classLoader +", failed even using the classloader of the
current thread"); 
>             throw new RuntimeException(e_inner.toString()); 
>                 } 
>         } 
>         else { 
>         System.err.println("ERROR 2: type1:" + type1 + ", type2: " + type2 + ", exception:
" + e + ", classLoader: " + classLoader +", unable to get the classloader of the current thread");

>         throw new RuntimeException(e.toString()); 
>         } 
> // --- ARZILLO PATCH END -----------------------------------------------------------

> 1760        } 
> 1761	if (c.isAssignableFrom(d)) { 
> 1762            return type1; 
> 1763        } 
> 1764        if (d.isAssignableFrom(c)) { 
> 1765            return type2; 
> 1766        } 
> 1767        if (c.isInterface() || d.isInterface()) { 
> 1768            return "java/lang/Object"; 
> 1779        } else { 
> 1770            do { 
> 1771                c = c.getSuperclass(); 
> 1772            } while (!c.isAssignableFrom(d)); 
> 1773            return c.getName().replace('.', '/'); 
> 1774        } 
> 1775    } 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message