metron-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Charles Porter (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (METRON-48) make metron modular with OSGi or Jigsaw or...?
Date Tue, 23 Feb 2016 00:30:18 GMT

     [ 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)

Mime
View raw message