You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@metron.apache.org by Otto Fowler <ot...@gmail.com> on 2017/04/24 11:14:15 UTC
Silly question about zk_load_configs.sh
So, this script is in common, but:
export JAR=metron-parsers-$METRON_VERSION-uber.jar
Is the jar it executes. The class it references is :
Re: Silly question about zk_load_configs.sh
Posted by Casey Stella <ce...@gmail.com>.
haha you're not thick; you're noticing a bit of a hack that should probably
be corrected. The use of parsers here is entirely to opportunistically
take advantage of the fact taht the parsers have as direct dependencies all
of the stellar functions in Metron. This was done prior to us being able
to side-load stellar functions (and it was still a bit of a hack, tbh).
Moving forward, I'd love to see the stellar functions extracted from Metron
and installed into HDFS and referenced that way, rather than bundled and
opportunistically referred to like in here.
On Mon, Apr 24, 2017 at 10:03 AM, Otto Fowler <ot...@gmail.com>
wrote:
> OK, not to be thick, I just don’t see where any class from metron-parsers
> gets called or instantiated.
> ¯\_(ツ)_/¯
>
>
> On April 24, 2017 at 09:55:38, Casey Stella (cestella@gmail.com) wrote:
>
> All of the current stellar functions are depended on either directly or
> indirectly by the parser.
>
> On Mon, Apr 24, 2017 at 9:54 AM, Otto Fowler <ot...@gmail.com>
> wrote:
>
>> too bad there isn’t a pr out for that kind of stuff ;)
>>
>> There are no stellar functions in parsers, except what is brought in from
>> common, why doesn’t this just call common?
>> You don’t need parsers jar for any of this do you?
>>
>>
>> On April 24, 2017 at 09:22:06, Casey Stella (cestella@gmail.com) wrote:
>>
>> Because stellar statements are validated prior to pushing, we needed the
>> functions on the classpath. I don't particularly like it as it's a
>> kludge. I'd really prefer to separate the non-core stellar functions from
>> the Metron core and have them deployed to HDFS, but we haven't gotten
>> there
>> quite yet. :)
>>
>> Casey
>>
>> On Mon, Apr 24, 2017 at 7:15 AM, Otto Fowler <ot...@gmail.com>
>> wrote:
>>
>> > So, this script is in common, but:
>> >
>> > export JAR=metron-parsers-$METRON_VERSION-uber.jar
>> >
>> > Is the jar it executes. The class it references is :
>> >
>> >
>> > export CLASSNAME=“org.apache.metron.common.cli.ConfigurationManager"
>> >
>> > So, why is it calling the parsers jar?
>> >
>>
>>
>
Re: Silly question about zk_load_configs.sh
Posted by Otto Fowler <ot...@gmail.com>.
OK, not to be thick, I just don’t see where any class from metron-parsers
gets called or instantiated.
¯\_(ツ)_/¯
On April 24, 2017 at 09:55:38, Casey Stella (cestella@gmail.com) wrote:
All of the current stellar functions are depended on either directly or
indirectly by the parser.
On Mon, Apr 24, 2017 at 9:54 AM, Otto Fowler <ot...@gmail.com>
wrote:
> too bad there isn’t a pr out for that kind of stuff ;)
>
> There are no stellar functions in parsers, except what is brought in from
> common, why doesn’t this just call common?
> You don’t need parsers jar for any of this do you?
>
>
> On April 24, 2017 at 09:22:06, Casey Stella (cestella@gmail.com) wrote:
>
> Because stellar statements are validated prior to pushing, we needed the
> functions on the classpath. I don't particularly like it as it's a
> kludge. I'd really prefer to separate the non-core stellar functions from
> the Metron core and have them deployed to HDFS, but we haven't gotten there
> quite yet. :)
>
> Casey
>
> On Mon, Apr 24, 2017 at 7:15 AM, Otto Fowler <ot...@gmail.com>
> wrote:
>
> > So, this script is in common, but:
> >
> > export JAR=metron-parsers-$METRON_VERSION-uber.jar
> >
> > Is the jar it executes. The class it references is :
> >
> >
> > export CLASSNAME=“org.apache.metron.common.cli.ConfigurationManager"
> >
> > So, why is it calling the parsers jar?
> >
>
>
Re: Silly question about zk_load_configs.sh
Posted by Casey Stella <ce...@gmail.com>.
All of the current stellar functions are depended on either directly or
indirectly by the parser.
On Mon, Apr 24, 2017 at 9:54 AM, Otto Fowler <ot...@gmail.com>
wrote:
> too bad there isn’t a pr out for that kind of stuff ;)
>
> There are no stellar functions in parsers, except what is brought in from
> common, why doesn’t this just call common?
> You don’t need parsers jar for any of this do you?
>
>
> On April 24, 2017 at 09:22:06, Casey Stella (cestella@gmail.com) wrote:
>
> Because stellar statements are validated prior to pushing, we needed the
> functions on the classpath. I don't particularly like it as it's a
> kludge. I'd really prefer to separate the non-core stellar functions from
> the Metron core and have them deployed to HDFS, but we haven't gotten
> there
> quite yet. :)
>
> Casey
>
> On Mon, Apr 24, 2017 at 7:15 AM, Otto Fowler <ot...@gmail.com>
> wrote:
>
> > So, this script is in common, but:
> >
> > export JAR=metron-parsers-$METRON_VERSION-uber.jar
> >
> > Is the jar it executes. The class it references is :
> >
> >
> > export CLASSNAME=“org.apache.metron.common.cli.ConfigurationManager"
> >
> > So, why is it calling the parsers jar?
> >
>
>
Re: Silly question about zk_load_configs.sh
Posted by Otto Fowler <ot...@gmail.com>.
too bad there isn’t a pr out for that kind of stuff ;)
There are no stellar functions in parsers, except what is brought in from
common, why doesn’t this just call common?
You don’t need parsers jar for any of this do you?
On April 24, 2017 at 09:22:06, Casey Stella (cestella@gmail.com) wrote:
Because stellar statements are validated prior to pushing, we needed the
functions on the classpath. I don't particularly like it as it's a
kludge. I'd really prefer to separate the non-core stellar functions from
the Metron core and have them deployed to HDFS, but we haven't gotten there
quite yet. :)
Casey
On Mon, Apr 24, 2017 at 7:15 AM, Otto Fowler <ot...@gmail.com>
wrote:
> So, this script is in common, but:
>
> export JAR=metron-parsers-$METRON_VERSION-uber.jar
>
> Is the jar it executes. The class it references is :
>
>
> export CLASSNAME=“org.apache.metron.common.cli.ConfigurationManager"
>
> So, why is it calling the parsers jar?
>
Re: Silly question about zk_load_configs.sh
Posted by Casey Stella <ce...@gmail.com>.
Because stellar statements are validated prior to pushing, we needed the
functions on the classpath. I don't particularly like it as it's a
kludge. I'd really prefer to separate the non-core stellar functions from
the Metron core and have them deployed to HDFS, but we haven't gotten there
quite yet. :)
Casey
On Mon, Apr 24, 2017 at 7:15 AM, Otto Fowler <ot...@gmail.com>
wrote:
> So, this script is in common, but:
>
> export JAR=metron-parsers-$METRON_VERSION-uber.jar
>
> Is the jar it executes. The class it references is :
>
>
> export CLASSNAME=“org.apache.metron.common.cli.ConfigurationManager"
>
> So, why is it calling the parsers jar?
>
Re: Silly question about zk_load_configs.sh
Posted by Otto Fowler <ot...@gmail.com>.
So, this script is in common, but:
export JAR=metron-parsers-$METRON_VERSION-uber.jar
Is the jar it executes. The class it references is :
export CLASSNAME=“org.apache.metron.common.cli.ConfigurationManager"
So, why is it calling the parsers jar?