LifecycleAware and Guava Service

[Eric Sammer <es...@cloudera.com>]

Flumees:

I was looking at some of the various LifecycleAware components in NG and
judging how best to handle certain error cases (now that at least the
basics are moving correctly) and realize I wasn't nearly consistent in the
semantics as I would have liked to be during initial implementation. I went
to look at a few other systems that use a similar construct (Jetty, some
Google projects) and realized Google's Guava actually has a construct
similar / the same as LifecycleAware in the com.google.common.base.Service
interface and constituents. They actually handle state transitions in the
same way I was going to during the review. This, of course, leads me to the
next question of should we just adopt Guava's Service interface and replace
LifecycleAware? Porting LifecycleSupervisor to use Service instances and
updating the LifecycleAware impls is just a bunch of monkey labor I am
willing to do. If this makes sense, doing this now is probably the only
option as this is a dependent interface of sources, sinks, and many other
user extensible bits.

I think this is in the continuing theme of keeping Flume small and
deferring to existing libraries where possible (this wouldn't add a
dependency as we already use Guava for other things). Unless there's a
major objection I'm going to create a JIRA and belt it out.

-- 
Eric Sammer
twitter: esammer
data: www.cloudera.com

Re: LifecycleAware and Guava Service

[Arvind Prabhakar <ar...@apache.org>]

I looked through the Guava library documentation and agree that this
meets our requirements for NG. Moreover, the added benefit of
simplification, reducing the code footprint are all great positives.
As Eric points out, this is the right time to make infrastructural
change without impacting too much of dependent code.

My strong +1 for this change.

Thanks,
Arvind

On Wed, Dec 7, 2011 at 1:02 PM, Basier Aziz <ba...@cloudera.com> wrote:
> ASL2.0 <http://code.google.com/p/guava-libraries/> (left pane)
>
> On Wed, Dec 7, 2011 at 1:00 PM, Ralph Goers <ra...@dslextreme.com>wrote:
>
>> What is the license for Guava?
>>
>> Ralph
>>
>> On Dec 7, 2011, at 11:39 AM, Eric Sammer wrote:
>>
>> > Flumees:
>> >
>> > I was looking at some of the various LifecycleAware components in NG and
>> > judging how best to handle certain error cases (now that at least the
>> > basics are moving correctly) and realize I wasn't nearly consistent in
>> the
>> > semantics as I would have liked to be during initial implementation. I
>> went
>> > to look at a few other systems that use a similar construct (Jetty, some
>> > Google projects) and realized Google's Guava actually has a construct
>> > similar / the same as LifecycleAware in the
>> com.google.common.base.Service
>> > interface and constituents. They actually handle state transitions in the
>> > same way I was going to during the review. This, of course, leads me to
>> the
>> > next question of should we just adopt Guava's Service interface and
>> replace
>> > LifecycleAware? Porting LifecycleSupervisor to use Service instances and
>> > updating the LifecycleAware impls is just a bunch of monkey labor I am
>> > willing to do. If this makes sense, doing this now is probably the only
>> > option as this is a dependent interface of sources, sinks, and many other
>> > user extensible bits.
>> >
>> > I think this is in the continuing theme of keeping Flume small and
>> > deferring to existing libraries where possible (this wouldn't add a
>> > dependency as we already use Guava for other things). Unless there's a
>> > major objection I'm going to create a JIRA and belt it out.
>> >
>> > --
>> > Eric Sammer
>> > twitter: esammer
>> > data: www.cloudera.com
>>
>>

Re: LifecycleAware and Guava Service

[Basier Aziz <ba...@cloudera.com>]

ASL2.0 <http://code.google.com/p/guava-libraries/> (left pane)

On Wed, Dec 7, 2011 at 1:00 PM, Ralph Goers <ra...@dslextreme.com>wrote:

> What is the license for Guava?
>
> Ralph
>
> On Dec 7, 2011, at 11:39 AM, Eric Sammer wrote:
>
> > Flumees:
> >
> > I was looking at some of the various LifecycleAware components in NG and
> > judging how best to handle certain error cases (now that at least the
> > basics are moving correctly) and realize I wasn't nearly consistent in
> the
> > semantics as I would have liked to be during initial implementation. I
> went
> > to look at a few other systems that use a similar construct (Jetty, some
> > Google projects) and realized Google's Guava actually has a construct
> > similar / the same as LifecycleAware in the
> com.google.common.base.Service
> > interface and constituents. They actually handle state transitions in the
> > same way I was going to during the review. This, of course, leads me to
> the
> > next question of should we just adopt Guava's Service interface and
> replace
> > LifecycleAware? Porting LifecycleSupervisor to use Service instances and
> > updating the LifecycleAware impls is just a bunch of monkey labor I am
> > willing to do. If this makes sense, doing this now is probably the only
> > option as this is a dependent interface of sources, sinks, and many other
> > user extensible bits.
> >
> > I think this is in the continuing theme of keeping Flume small and
> > deferring to existing libraries where possible (this wouldn't add a
> > dependency as we already use Guava for other things). Unless there's a
> > major objection I'm going to create a JIRA and belt it out.
> >
> > --
> > Eric Sammer
> > twitter: esammer
> > data: www.cloudera.com
>
>

Re: LifecycleAware and Guava Service

[Ralph Goers <ra...@dslextreme.com>]

What is the license for Guava?

Ralph

On Dec 7, 2011, at 11:39 AM, Eric Sammer wrote:

> Flumees:
> 
> I was looking at some of the various LifecycleAware components in NG and
> judging how best to handle certain error cases (now that at least the
> basics are moving correctly) and realize I wasn't nearly consistent in the
> semantics as I would have liked to be during initial implementation. I went
> to look at a few other systems that use a similar construct (Jetty, some
> Google projects) and realized Google's Guava actually has a construct
> similar / the same as LifecycleAware in the com.google.common.base.Service
> interface and constituents. They actually handle state transitions in the
> same way I was going to during the review. This, of course, leads me to the
> next question of should we just adopt Guava's Service interface and replace
> LifecycleAware? Porting LifecycleSupervisor to use Service instances and
> updating the LifecycleAware impls is just a bunch of monkey labor I am
> willing to do. If this makes sense, doing this now is probably the only
> option as this is a dependent interface of sources, sinks, and many other
> user extensible bits.
> 
> I think this is in the continuing theme of keeping Flume small and
> deferring to existing libraries where possible (this wouldn't add a
> dependency as we already use Guava for other things). Unless there's a
> major objection I'm going to create a JIRA and belt it out.
> 
> -- 
> Eric Sammer
> twitter: esammer
> data: www.cloudera.com