metron-issues mailing list archives

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

    [ https://issues.apache.org/jira/browse/METRON-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15158033#comment-15158033
] 

Casey Stella commented on METRON-48:
------------------------------------

Ran into the guava and dependency issues too.  If you look Metron-Common's pom, we've started
to relocate aggressively deprecating dependencies such as guava.  This creates a stable base
for us to depend on, because as the maven shade plugin builds the jar, it'll rewrite the bytecode.
 This is the same technique that Storm uses (see lines 536+ at https://github.com/apache/storm/blob/master/storm-core/pom.xml).

Right now Guava is the only jar that we're doing that for, but we'll probably do it for others.
 Is there other concerns outside of classpath conflicts?

Moving to OSGi sounds like quite a bit of core work and I'd like to know more about what exactly
we get for it before endeavoring into that adventure.  Do you have any idea if there is a
performance impact?  If so, how much would we be looking at?

> 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