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

[Manik Surtani (JIRA)]

     [ https://issues.jboss.org/browse/ISPN-1096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Manik Surtani updated ISPN-1096:
--------------------------------

           Priority: Blocker  (was: Major)
    Forum Reference: http://markmail.org/search/?q=infinispan#query:infinispan%20list%3Aorg.jboss.lists.infinispan-dev%20order%3Adate-backward+page:1+mid:nvjjekkli442oepm+state:results  (was: http://markmail.org/search/?q=infinispan#query:infinispan%20list%3Aorg.jboss.lists.infinispan-dev%20order%3Adate-backward+page:1+mid:nvjjekkli442oepm+state:results)


> 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