[infinispan-issues] [JBoss JIRA] Commented: (ISPN-1096) Rework application class loading to be more friendly to modular environments

[Galder Zamarreño (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-1096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12612196#comment-12612196 ] 

Galder Zamarreño commented on ISPN-1096:
----------------------------------------

Pete, I agree with your points about setting the TCCL and to top it up, being constantly setting the TCL is rather slow cos it requires acquiring the right security permission. A marshaller per named cache to be able to serve a different CL per thread accessing the cache seems like a good option.

> Rework application class loading to be more friendly to modular environments
> ----------------------------------------------------------------------------
>
>                 Key: ISPN-1096
>                 URL: https://issues.jboss.org/browse/ISPN-1096
>             Project: Infinispan
>          Issue Type: Feature Request
>          Components: Core API
>    Affects Versions: 4.2.1.FINAL
>            Reporter: Pete Muir
>            Assignee: Pete Muir
>            Priority: Blocker
>              Labels: ClassLoader, Modularity, OSGi
>             Fix For: 5.0.0.CR7, 5.0.0.FINAL
>
>
> There are two issues with modularity/classloading in Infinispan:
> 1) Using the TCCL as the classloader to load Infinispan classes is a bad idea. Instead we should use org.infinispan.foo.Bar.getClass().getClassLoader().
> This has been addressed as a separate issue.
> 2) When we need to load application classes we need a different approach to that used today. Most of the time the TCCL is perfect for this. However *sometimes* Infinispan may be invoked outside of the application, when the TCCL may not be set in AS7. Jason and I discussed three options:
> a) require (through a platform integration documentation contract) that the TCCL must always be set when Infinispan is invoked.
> b) Have some sort of InvocationContext which knows what the correct classloader to use is (aka Hibernate/Seam/Weld design where there is a per-application construct based on a ThreadLocal). Given this hasn't been designed into the core, it seems like a large retrofit
> c) Make users specify the CL (directly or indirectly) via the API (as we discussed).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira