You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@metron.apache.org by "Charles Porter (JIRA)" <ji...@apache.org> on 2016/02/23 01:30:18 UTC

[jira] [Updated] (METRON-48) make metron modular with OSGi or Jigsaw or...?

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

Charles Porter updated METRON-48:
---------------------------------
    Summary: make metron modular with OSGi or Jigsaw or...?  (was: make metron modular with OSGi or Jigsaw)

> make metron modular with OSGi or Jigsaw or...?
> ----------------------------------------------
>
>                 Key: METRON-48
>                 URL: https://issues.apache.org/jira/browse/METRON-48
>             Project: Metron
>          Issue Type: Improvement
>         Environment: any
>            Reporter: Charles Porter
>   Original Estimate: 1,344h
>  Remaining Estimate: 1,344h
>
> The large number of dependencies and transitive dependencies make it very difficult or impossible to be sure that there are no conflicts in libraried. For example, hBase 1.1 currently depends on guava 1.7 or lower, but ElasticSearch 2.1.x depends on guava 1.8 or higher. This means it is impossible to build Metron so it satisfies both requirements. 
> The above is meant only as an illustration, because it is an issue I have seen. I have worked around this in my current project, but the work-around is ugly.
> The correct solution is a modularization system, allowing bolts and spouts to _each_ run in their own classloader.   We could roll our own solution or use OSGi (or Jigsaw, if it existed)
> Perhaps the right place to solve this is in Storm, since storm controls classloading.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)