You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@accumulo.apache.org by Corey Nolet <cj...@gmail.com> on 2014/04/01 02:34:01 UTC

Re: Accumulo and OSGi

Geoffry,

What OSGi container are you using currently? The servicemix Hadoop bundle
should get you going with the Hadoop client dependencies at least [1]. It
looks like one of the servicemix guys created a Hadoop ticket for making
bundles of their jars as well [2], though it doesn't look like there's been
any movement on it.

I recently had to get the CDH3u4 client code working in Karaf. A good
starting place for me was [3], however I did need to make updates to
versions of many of the dependencies to get it functioning as expected. [3]
will get you at least started with dependent bundles and the proper
imports/exports to get it working.

I've got the Accumulo client running in OSGi. If I recall correctly,
versions 1.4 and above do not split packages across jars so it's really
just a matter of getting the dependencies right. Zookeeper also ships as a
bundle [4].


Hope this helps.

[1]
http://mvnrepository.com/artifact/org.apache.servicemix.bundles/org.apache.servicemix.bundles.hadoop-core/
[2] https://issues.apache.org/jira/browse/HADOOP-8446
[3] https://github.com/jbonofre/karaf-hadoop
[4] https://issues.apache.org/jira/browse/ZOOKEEPER-425



On Mon, Mar 31, 2014 at 11:37 AM, Geoffry Roberts <th...@gmail.com>wrote:

> Luk,
>
> Thanks for the link, but I am a bit lost.  wso2 offers middleware,
> apparently you believe this will help my situation.  If it's not too much,
> can you expand?
>
>
> On Mon, Mar 31, 2014 at 11:13 AM, Luk Vervenne <lu...@synergetics.be> wrote:
>
>> osgi... see wso2.com
>>
>> On 31 Mar 2014, at 16:58, Geoffry Roberts <th...@gmail.com> wrote:
>>
>> > All,
>> >
>> > I have a project for which Accumulo it appears will serve well.
>>  However, I have a significant amount of code I want to leverage that runs
>> in OSGi.  I don't need for Accumulo itself to be OSGi based but the
>> Accumulo client yes.  I see that the Accumulo client uses all the
>> dependencies of the Hadoop client and therefore is not OSGi ready at this
>> time.  The Hadoop client certainly doesn't do OSGi--I don't think it can
>> even spell it :-)--and attempting to make it so starts turning into a sure
>> path to a long sojourn through dependency hell.  I know, I've tried.
>> >
>> > Nonetheless, I would like to ask: Is there any interest in the Accumulo
>> world of having an OSGi based client for this otherwise very appealing
>> database?
>> >
>> > Thanks mucho
>> > --
>> > There are ways and there are ways,
>> >
>> > Geoffry Roberts
>>
>>
>
>
> --
> There are ways and there are ways,
>
> Geoffry Roberts
>

Re: Accumulo and OSGi

Posted by Corey Nolet <cj...@gmail.com>.
Geoffry,

Unfortunately, I will not be able to provide a patch on the internet for
the work I've done, yet. I hope some of the resources I've provided can be
a good starting place for you. I can certainly be available to help you
through some of the painful problems that I went through, but there's a lag
between my daily work and my ability to commit the work back to Apache and
I cannot promise when that will happen.

My vote would obvious be yes, I think it would be very useful to have
Accumulo's artifacts be OSGi bundles.



On Thu, Apr 10, 2014 at 10:59 AM, Luk Vervenne <lu...@synergetics.be> wrote:

> Yes
>
> On 10 Apr 2014, at 16:53, <Bo...@l-3com.com> <Bo...@l-3com.com>
> wrote:
>
> > Yes
> >
> > -----Original Message-----
> > From: Josh Elser [mailto:josh.elser@gmail.com]
> > Sent: Thursday, April 10, 2014 9:32 AM
> > To: user@accumulo.apache.org
> > Subject: Re: Accumulo and OSGi
> >
> >> You say the community would be well-accepting of bundling up the
> >> Accumulo client.  If that's the case, I'd like to hear from them.
> >
> > Yes :)
> >
>
>

Re: Accumulo and OSGi

Posted by Luk Vervenne <lu...@synergetics.be>.
Yes

On 10 Apr 2014, at 16:53, <Bo...@l-3com.com> <Bo...@l-3com.com> wrote:

> Yes
> 
> -----Original Message-----
> From: Josh Elser [mailto:josh.elser@gmail.com] 
> Sent: Thursday, April 10, 2014 9:32 AM
> To: user@accumulo.apache.org
> Subject: Re: Accumulo and OSGi
> 
>> You say the community would be well-accepting of bundling up the 
>> Accumulo client.  If that's the case, I'd like to hear from them.
> 
> Yes :)
> 


RE: Accumulo and OSGi

Posted by Bo...@l-3com.com.
Yes

-----Original Message-----
From: Josh Elser [mailto:josh.elser@gmail.com] 
Sent: Thursday, April 10, 2014 9:32 AM
To: user@accumulo.apache.org
Subject: Re: Accumulo and OSGi

> You say the community would be well-accepting of bundling up the 
> Accumulo client.  If that's the case, I'd like to hear from them.

Yes :)


Re: Accumulo and OSGi

Posted by Josh Elser <jo...@gmail.com>.
> You say the community would be well-accepting of bundling up the
> Accumulo client.  If that's the case, I'd like to hear from them.

Yes :)


Re: Accumulo and OSGi

Posted by Corey Nolet <cj...@gmail.com>.
+1 for slf4j.


On Wed, Apr 23, 2014 at 10:51 AM, Josh Elser <jo...@gmail.com> wrote:

> I'd love to see us move to slf4j. Hadoop is in the middle of a proposal
> about this too which sounds good to me.
>
> http://mail-archives.apache.org/mod_mbox/hadoop-common-
> dev/201404.mbox/%3CCA%2B4kjVv7N2dRR5rmdFHCpBx-K3yT7YRLs0Dvrvdjsn3iChUsEA%
> 40mail.gmail.com%3E
>
>
> On 4/23/14, 10:33 AM, Geoffry Roberts wrote:
>
>> If I were to pitch in on this,  how would it work?  and what logger?  Do
>> I submit patches?  Is slf4j the target?
>>
>>
>> On Wed, Apr 23, 2014 at 9:45 AM, Sean Busbey <busbey@cloudera.com
>> <ma...@cloudera.com>> wrote:
>>
>>     yes, there are also some bits using commons-logging. I think we
>>     managed to scrub out java.util.logging.
>>
>>
>>     On Wed, Apr 23, 2014 at 8:39 AM, Geoffry Roberts
>>     <threadedblue@gmail.com <ma...@gmail.com>> wrote:
>>
>>         I thought I'd check in.
>>
>>         After some encouragement from this group, I found some time and
>>         now have an Accumulo client running in OSGi (Felix).  It's
>>         rather primitive, at this juncture, in that it is little more
>>         than a wrap job.  I was, however, forced to hack Zookeeper to
>>         get things to work.  Zookeeper needed to import an additional
>>         package.  I used the servicemix bundle for Hadoop.
>>
>>         Josh, You asked if there was anything that could be done
>>         upstream to make osgification go better.  One thing, and it's
>>         not a huge deal, but getting everything on the same logging
>>         library would be nice.  So far, I see both log4j and slf4j.  Are
>>         there more?
>>
>>
>>
>>         On Thu, Apr 10, 2014 at 12:49 PM, Russ Weeks
>>         <rweeks@newbrightidea.com <ma...@newbrightidea.com>>
>> wrote:
>>
>>             On Thu, Apr 10, 2014 at 7:18 AM, Geoffry Roberts
>>             <threadedblue@gmail.com <ma...@gmail.com>>
>> wrote:
>>
>>                 You say the community would be well-accepting of
>>                 bundling up the Accumulo client.  If that's the case,
>>                 I'd like to hear from them.
>>
>>
>>             +1!
>>
>>
>>
>>
>>         --
>>         There are ways and there are ways,
>>
>>         Geoffry Roberts
>>
>>
>>
>>
>>     --
>>     Sean
>>
>>
>>
>>
>> --
>> There are ways and there are ways,
>>
>> Geoffry Roberts
>>
>

Re: Accumulo and OSGi

Posted by Josh Elser <jo...@gmail.com>.
I'd love to see us move to slf4j. Hadoop is in the middle of a proposal 
about this too which sounds good to me.

http://mail-archives.apache.org/mod_mbox/hadoop-common-dev/201404.mbox/%3CCA%2B4kjVv7N2dRR5rmdFHCpBx-K3yT7YRLs0Dvrvdjsn3iChUsEA%40mail.gmail.com%3E

On 4/23/14, 10:33 AM, Geoffry Roberts wrote:
> If I were to pitch in on this,  how would it work?  and what logger?  Do
> I submit patches?  Is slf4j the target?
>
>
> On Wed, Apr 23, 2014 at 9:45 AM, Sean Busbey <busbey@cloudera.com
> <ma...@cloudera.com>> wrote:
>
>     yes, there are also some bits using commons-logging. I think we
>     managed to scrub out java.util.logging.
>
>
>     On Wed, Apr 23, 2014 at 8:39 AM, Geoffry Roberts
>     <threadedblue@gmail.com <ma...@gmail.com>> wrote:
>
>         I thought I'd check in.
>
>         After some encouragement from this group, I found some time and
>         now have an Accumulo client running in OSGi (Felix).  It's
>         rather primitive, at this juncture, in that it is little more
>         than a wrap job.  I was, however, forced to hack Zookeeper to
>         get things to work.  Zookeeper needed to import an additional
>         package.  I used the servicemix bundle for Hadoop.
>
>         Josh, You asked if there was anything that could be done
>         upstream to make osgification go better.  One thing, and it's
>         not a huge deal, but getting everything on the same logging
>         library would be nice.  So far, I see both log4j and slf4j.  Are
>         there more?
>
>
>
>         On Thu, Apr 10, 2014 at 12:49 PM, Russ Weeks
>         <rweeks@newbrightidea.com <ma...@newbrightidea.com>> wrote:
>
>             On Thu, Apr 10, 2014 at 7:18 AM, Geoffry Roberts
>             <threadedblue@gmail.com <ma...@gmail.com>> wrote:
>
>                 You say the community would be well-accepting of
>                 bundling up the Accumulo client.  If that's the case,
>                 I'd like to hear from them.
>
>
>             +1!
>
>
>
>
>         --
>         There are ways and there are ways,
>
>         Geoffry Roberts
>
>
>
>
>     --
>     Sean
>
>
>
>
> --
> There are ways and there are ways,
>
> Geoffry Roberts

Re: Accumulo and OSGi

Posted by Geoffry Roberts <th...@gmail.com>.
If I were to pitch in on this,  how would it work?  and what logger?  Do I
submit patches?  Is slf4j the target?


On Wed, Apr 23, 2014 at 9:45 AM, Sean Busbey <bu...@cloudera.com> wrote:

> yes, there are also some bits using commons-logging. I think we managed to
> scrub out java.util.logging.
>
>
> On Wed, Apr 23, 2014 at 8:39 AM, Geoffry Roberts <th...@gmail.com>wrote:
>
>> I thought I'd check in.
>>
>> After some encouragement from this group, I found some time and now have
>> an Accumulo client running in OSGi (Felix).  It's rather primitive, at this
>> juncture, in that it is little more than a wrap job.  I was, however,
>> forced to hack Zookeeper to get things to work.  Zookeeper needed to import
>> an additional package.  I used the servicemix bundle for Hadoop.
>>
>> Josh, You asked if there was anything that could be done upstream to make
>> osgification go better.  One thing, and it's not a huge deal, but getting
>> everything on the same logging library would be nice.  So far, I see both
>> log4j and slf4j.  Are there more?
>>
>>
>>
>> On Thu, Apr 10, 2014 at 12:49 PM, Russ Weeks <rw...@newbrightidea.com>wrote:
>>
>>> On Thu, Apr 10, 2014 at 7:18 AM, Geoffry Roberts <threadedblue@gmail.com
>>> > wrote:
>>>
>>>> You say the community would be well-accepting of bundling up the
>>>> Accumulo client.  If that's the case, I'd like to hear from them.
>>>>
>>>
>>> +1!
>>>
>>
>>
>>
>> --
>> There are ways and there are ways,
>>
>> Geoffry Roberts
>>
>
>
>
> --
> Sean
>



-- 
There are ways and there are ways,

Geoffry Roberts

Re: Accumulo and OSGi

Posted by Sean Busbey <bu...@cloudera.com>.
yes, there are also some bits using commons-logging. I think we managed to
scrub out java.util.logging.


On Wed, Apr 23, 2014 at 8:39 AM, Geoffry Roberts <th...@gmail.com>wrote:

> I thought I'd check in.
>
> After some encouragement from this group, I found some time and now have
> an Accumulo client running in OSGi (Felix).  It's rather primitive, at this
> juncture, in that it is little more than a wrap job.  I was, however,
> forced to hack Zookeeper to get things to work.  Zookeeper needed to import
> an additional package.  I used the servicemix bundle for Hadoop.
>
> Josh, You asked if there was anything that could be done upstream to make
> osgification go better.  One thing, and it's not a huge deal, but getting
> everything on the same logging library would be nice.  So far, I see both
> log4j and slf4j.  Are there more?
>
>
>
> On Thu, Apr 10, 2014 at 12:49 PM, Russ Weeks <rw...@newbrightidea.com>wrote:
>
>> On Thu, Apr 10, 2014 at 7:18 AM, Geoffry Roberts <th...@gmail.com>wrote:
>>
>>> You say the community would be well-accepting of bundling up the
>>> Accumulo client.  If that's the case, I'd like to hear from them.
>>>
>>
>> +1!
>>
>
>
>
> --
> There are ways and there are ways,
>
> Geoffry Roberts
>



-- 
Sean

Re: Accumulo and OSGi

Posted by Mike Drob <ma...@cloudera.com>.
Geoffry,

Fixing our logging libraries is an open issue -
https://issues.apache.org/jira/browse/ACCUMULO-1242

I hope to see it resolved soon. It's a pretty big task, so if you feel
inspired to help, it would be appreciated as well!

Thanks,
Mike


On Wed, Apr 23, 2014 at 9:39 AM, Geoffry Roberts <th...@gmail.com>wrote:

> I thought I'd check in.
>
> After some encouragement from this group, I found some time and now have
> an Accumulo client running in OSGi (Felix).  It's rather primitive, at this
> juncture, in that it is little more than a wrap job.  I was, however,
> forced to hack Zookeeper to get things to work.  Zookeeper needed to import
> an additional package.  I used the servicemix bundle for Hadoop.
>
> Josh, You asked if there was anything that could be done upstream to make
> osgification go better.  One thing, and it's not a huge deal, but getting
> everything on the same logging library would be nice.  So far, I see both
> log4j and slf4j.  Are there more?
>
>
>
> On Thu, Apr 10, 2014 at 12:49 PM, Russ Weeks <rw...@newbrightidea.com>wrote:
>
>> On Thu, Apr 10, 2014 at 7:18 AM, Geoffry Roberts <th...@gmail.com>wrote:
>>
>>> You say the community would be well-accepting of bundling up the
>>> Accumulo client.  If that's the case, I'd like to hear from them.
>>>
>>
>> +1!
>>
>
>
>
> --
> There are ways and there are ways,
>
> Geoffry Roberts
>

Re: Accumulo and OSGi

Posted by Geoffry Roberts <th...@gmail.com>.
I thought I'd check in.

After some encouragement from this group, I found some time and now have an
Accumulo client running in OSGi (Felix).  It's rather primitive, at this
juncture, in that it is little more than a wrap job.  I was, however,
forced to hack Zookeeper to get things to work.  Zookeeper needed to import
an additional package.  I used the servicemix bundle for Hadoop.

Josh, You asked if there was anything that could be done upstream to make
osgification go better.  One thing, and it's not a huge deal, but getting
everything on the same logging library would be nice.  So far, I see both
log4j and slf4j.  Are there more?



On Thu, Apr 10, 2014 at 12:49 PM, Russ Weeks <rw...@newbrightidea.com>wrote:

> On Thu, Apr 10, 2014 at 7:18 AM, Geoffry Roberts <th...@gmail.com>wrote:
>
>> You say the community would be well-accepting of bundling up the Accumulo
>> client.  If that's the case, I'd like to hear from them.
>>
>
> +1!
>



-- 
There are ways and there are ways,

Geoffry Roberts

Re: Accumulo and OSGi

Posted by Russ Weeks <rw...@newbrightidea.com>.
On Thu, Apr 10, 2014 at 7:18 AM, Geoffry Roberts <th...@gmail.com>wrote:

> You say the community would be well-accepting of bundling up the Accumulo
> client.  If that's the case, I'd like to hear from them.
>

+1!

Re: Accumulo and OSGi

Posted by Geoffry Roberts <th...@gmail.com>.
I might be interested in taking on the work.  Can you help me find your
patch?

I have a code base already in OSGi that works with MongoDB.  I need to
point it at Accumulo instead, and if I can do so without porting out of
OSGi that would be nice.

You say the community would be well-accepting of bundling up the Accumulo
client.  If that's the case, I'd like to hear from them.


On Wed, Apr 9, 2014 at 2:09 PM, Corey Nolet <cj...@gmail.com> wrote:

> Geoffry,
>
>
> Interesting you have Hadoop working in Karaf.  I'm using equinox.
>
> Sure, but are we talking Karaf-specific features here? You just want a
> Hadoop Client bundle that works, right? The author of the Karaf-Hadoop
> project already worked through the classpath issues so it's not a bad
> starting place. Same with the ServiceMix features files.
>
> If I understand you correctly, I only need have Text available.  I'll
> look into that. It does answer my question and maybe I can avoid the JAAS
> mishmash.
>
> Without needing a connection to the FileSystem, can the JAAS stuff be set
> as an optional import?
>
> Close on to 100% of my troubles has always been with getting 3rd party
> libraries working.  Accumulo/Hadoop is only the latest round.
>
> You are getting no arguments from me. I've been using Karaf consistently
> for a few years now and no doubt most of my time maintaining the services
> is spent making sure 3rd party things work (and continue to work after
> updates). I've come to expect it at this point.
>
>
> It's security, scaleability, relationship to Hadoop's HDFS and MR all
> conspire to make it attractive.  But creating an uberbundle?
>
> Sure, packaging all the Accumulo classes into a single bundle got me up
> and running. I still took time wrapping all of its transitive dependencies
> in their own bundles and wiring up the imports/exports, but it works.
>
> As mentioned in previous posts, I think the community would be
> well-excepting of a first-class Accumulo bundle. If you are interested in
> taking on the work, the ticket I posted previously is open and ready for a
> patch.
>
> Both of these were advised by one of the bndtools gurus--neither worked.
>  When I did the Import-Package other things broke.
>
> I had to import several nested packages to get mine to work properly.
> Which other things broke when you did the Import Package of the JAAS
> packaes?
>
>
>
> On Wed, Apr 9, 2014 at 11:49 AM, Geoffry Roberts <th...@gmail.com>wrote:
>
>> Corey,
>>
>>
>> Interesting you have Hadoop working in Karaf.  I'm using equinox.  It
>> also sounds as if I don't need to access HFDS in order to get Accumulo to
>> work in OSGi. If I understand you correctly, I only need have Text
>> available.  I'll look into that. It does answer my question and maybe I
>> can avoid the JAAS mishmash.
>>
>>
>> I have been using OSGi off and on for a few years now. Close on to 100%
>> of my troubles has always been with getting 3rd party libraries working.
>>  Accumulo/Hadoop is only the latest round.
>>
>>
>> I'm gearing to do some major work based on Accumulo.  It's security,
>> scaleability, relationship to Hadoop's HDFS and MR all conspire to make it
>> attractive.  But creating an uberbundle? I'm sure I could get it working as
>> a proof of concept, but will it play in prime-time?
>>
>>
>> How hard would it be to make a proper Accumulo bundle?  Would the
>> community accept it?
>>
>>
>> Thanks
>>
>>
>> So far as my travails with JAAS is concerned, I did this in my bndtools
>> *.bndrun file:
>>
>>
>> -runproperties:
>> org.osgi.framework.system.packages.extra=com.sun.security.auth.module
>>
>> I also tried:
>> Import-Package: com.sun.security.auth.module
>> in my bundle that calls Hadoop.
>>
>> Both of these were advised by one of the bndtools gurus--neither worked.
>>  When I did the Import-Package other things broke.
>>
>> On Wed, Apr 9, 2014 at 9:46 AM, Corey Nolet <cj...@gmail.com> wrote:
>>
>>> Geoffry,
>>>
>>> As Josh pointed out, you should only need the Hadoop libraries on the
>>> client side to use the Text object. This means you won't have to go through
>>> the pain of placing the xml files in your root bundles.
>>>
>>> Did you try the JAAS export from the packages in your container? Did
>>> that help?
>>>
>>> I agree with your comment that we *should* be able to look at these
>>> bundles as black boxes but we're not dealing with true bundles, yet. Once I
>>> got my Hadoop client bundle ready to go, I haven't had to touch it (and the
>>> Hadoop Karaf project solved most of the import/export guessing work for me
>>> already).  For Accumulo, on the other hand, it's up to you if you want to
>>> create an uber-bundle with the necessary Accumulo packages or just wrap
>>> each one and provide the necessary imports/exports across them. For my
>>> needs, I just created one uber-bundle for Accumulo packages and imported
>>> the necessary non-Accumulo packages (many of those I had to wrap as well).
>>> I didn't find that part too painful on the Accumulo side. While not being
>>> the ideal situation from the OSGI side, with lack of an existing bundle
>>> artifact, it did solve my problem and I'm actively using both Accumulo and
>>> Hadoop in OSGi. My recommendation would be that until we get a proper
>>> bundle, that solution would certainly work in the short-term.
>>>
>>> I believe Josh posted this already but check out [1]. A ready-to-go OSGi
>>> bundle for Accumulo would be useful but the Hadoop client dependency would
>>> need to be wrapped (or exposed as its own bundle). IMO, with proper
>>> documentation this shouldn't be too painful for users. Thoughts?
>>>
>>>
>>> [1] https://issues.apache.org/jira/browse/ACCUMULO-2518
>>>
>>>
>>> On Mon, Apr 7, 2014 at 11:27 AM, Geoffry Roberts <threadedblue@gmail.com
>>> > wrote:
>>>
>>>> Ahh,  let me try and address where I might have gone off the linguistic
>>>> reservation.
>>>>
>>>> bndtools -- is an eclipse plugin that is very helpful when developing
>>>> OSGi bundles.  It does a lot of grimy, boilerplate things for you.
>>>>
>>>> inlining -- is where one places dependent *.jar files inside the OSGi
>>>> bundle and therefore on said bundle's class path.  It tends to promote
>>>> bloated bundles--not in the spirit of OSGi--but sometimes necessary.
>>>>
>>>> componentizing -- is the business of converting a class into a
>>>> component.  In the bndtools way of doing things, this can be a easy as
>>>> annotating a class with @Component.
>>>>
>>>> bundle -- You probably know what this is already, but I'll include it
>>>> for good measure.  A bundle is a body of code that is on the same class
>>>> path, and often acts as a service to there bundles.
>>>>
>>>> I don't know what could be done upstream other that making Accumulo's
>>>> client OAGI ready.  Would we like to do that?
>>>>
>>>>
>>>> On Mon, Apr 7, 2014 at 11:02 AM, Josh Elser <jo...@gmail.com>wrote:
>>>>
>>>>> You just used a lot of words that don't mean anything to me :)
>>>>>
>>>>> Hopefully you don't have to do much on your own. If there are things
>>>>> we can change upstream to make this process easier, please feel free to let
>>>>> us know.
>>>>>
>>>>>
>>>>> On 4/7/14, 10:55 AM, Geoffry Roberts wrote:
>>>>>
>>>>>> Thanks Josh,
>>>>>>
>>>>>> My container for the moment is equinox, but all should work in Felix
>>>>>> as
>>>>>> well.  I've been using bndtools for my other OSGi work so I'm faced
>>>>>> with
>>>>>> either annotating the Accumulo Code or wrapping it somehow.  What do
>>>>>> you
>>>>>> want to bet I wind up inlining it?  Still, the annotated (read
>>>>>> componentized) approach would be less kloogy.  I hesitate because I'd
>>>>>> wind up maintaining my own code line.
>>>>>>
>>>>>>
>>>>>> On Mon, Apr 7, 2014 at 10:28 AM, Josh Elser <josh.elser@gmail.com
>>>>>> <ma...@gmail.com>> wrote:
>>>>>>
>>>>>>     On 4/7/14, 10:07 AM, Geoffry Roberts wrote:
>>>>>>
>>>>>>         My original question remains: Is the Accumulo Client dependent
>>>>>>         on the
>>>>>>         Hadoop Client fully?  This determination can be made through
>>>>>>         trial and
>>>>>>         error.  But I'm looking to leverage OPE (other people's
>>>>>>         experience) if
>>>>>>         it exists.
>>>>>>
>>>>>>
>>>>>>     I thought someone had already said this (but I may be confusing
>>>>>>     threads): the Accumulo API uses Text throughout. Hadoop is a
>>>>>>     required dependency.
>>>>>>
>>>>>>
>>>>>>         In the same spirit, does anyone know if all the following are
>>>>>>         required
>>>>>>         to run an Accumulo Client? core, fate, start, trace?  If I
>>>>>>         attempt to
>>>>>>         OSGify, I'm trying to figure how much trouble am I getting
>>>>>> into.
>>>>>>
>>>>>>
>>>>>>     Yes, that should be about it from within Accumulo. You might need
>>>>>>     some other foss dependencies also available, but I'm not aware on
>>>>>>     what your "container" (or w/e the proper terminology would be)
>>>>>> provides.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> There are ways and there are ways,
>>>>>>
>>>>>> Geoffry Roberts
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> There are ways and there are ways,
>>>>
>>>> Geoffry Roberts
>>>>
>>>
>>>
>>
>>
>> --
>> There are ways and there are ways,
>>
>> Geoffry Roberts
>>
>
>


-- 
There are ways and there are ways,

Geoffry Roberts

Re: Accumulo and OSGi

Posted by Corey Nolet <cj...@gmail.com>.
Geoffry,

Interesting you have Hadoop working in Karaf.  I'm using equinox.

Sure, but are we talking Karaf-specific features here? You just want a
Hadoop Client bundle that works, right? The author of the Karaf-Hadoop
project already worked through the classpath issues so it's not a bad
starting place. Same with the ServiceMix features files.

If I understand you correctly, I only need have Text available.  I'll look
into that. It does answer my question and maybe I can avoid the JAAS
mishmash.

Without needing a connection to the FileSystem, can the JAAS stuff be set
as an optional import?

Close on to 100% of my troubles has always been with getting 3rd party
libraries working.  Accumulo/Hadoop is only the latest round.

You are getting no arguments from me. I've been using Karaf consistently
for a few years now and no doubt most of my time maintaining the services
is spent making sure 3rd party things work (and continue to work after
updates). I've come to expect it at this point.

It's security, scaleability, relationship to Hadoop's HDFS and MR all
conspire to make it attractive.  But creating an uberbundle?

Sure, packaging all the Accumulo classes into a single bundle got me up and
running. I still took time wrapping all of its transitive dependencies in
their own bundles and wiring up the imports/exports, but it works.

As mentioned in previous posts, I think the community would be
well-excepting of a first-class Accumulo bundle. If you are interested in
taking on the work, the ticket I posted previously is open and ready for a
patch.

Both of these were advised by one of the bndtools gurus--neither worked.
 When I did the Import-Package other things broke.

I had to import several nested packages to get mine to work properly.
Which other things broke when you did the Import Package of the JAAS
packaes?



On Wed, Apr 9, 2014 at 11:49 AM, Geoffry Roberts <th...@gmail.com>wrote:

> Corey,
>
>
> Interesting you have Hadoop working in Karaf.  I'm using equinox.  It also
> sounds as if I don't need to access HFDS in order to get Accumulo to work
> in OSGi. If I understand you correctly, I only need have Text available.
>  I'll look into that. It does answer my question and maybe I can avoid
> the JAAS mishmash.
>
>
> I have been using OSGi off and on for a few years now. Close on to 100% of
> my troubles has always been with getting 3rd party libraries working.
>  Accumulo/Hadoop is only the latest round.
>
>
> I'm gearing to do some major work based on Accumulo.  It's security,
> scaleability, relationship to Hadoop's HDFS and MR all conspire to make it
> attractive.  But creating an uberbundle? I'm sure I could get it working as
> a proof of concept, but will it play in prime-time?
>
>
> How hard would it be to make a proper Accumulo bundle?  Would the
> community accept it?
>
>
> Thanks
>
>
> So far as my travails with JAAS is concerned, I did this in my bndtools
> *.bndrun file:
>
>
> -runproperties:
> org.osgi.framework.system.packages.extra=com.sun.security.auth.module
>
> I also tried:
> Import-Package: com.sun.security.auth.module
> in my bundle that calls Hadoop.
>
> Both of these were advised by one of the bndtools gurus--neither worked.
>  When I did the Import-Package other things broke.
>
> On Wed, Apr 9, 2014 at 9:46 AM, Corey Nolet <cj...@gmail.com> wrote:
>
>> Geoffry,
>>
>> As Josh pointed out, you should only need the Hadoop libraries on the
>> client side to use the Text object. This means you won't have to go through
>> the pain of placing the xml files in your root bundles.
>>
>> Did you try the JAAS export from the packages in your container? Did that
>> help?
>>
>> I agree with your comment that we *should* be able to look at these
>> bundles as black boxes but we're not dealing with true bundles, yet. Once I
>> got my Hadoop client bundle ready to go, I haven't had to touch it (and the
>> Hadoop Karaf project solved most of the import/export guessing work for me
>> already).  For Accumulo, on the other hand, it's up to you if you want to
>> create an uber-bundle with the necessary Accumulo packages or just wrap
>> each one and provide the necessary imports/exports across them. For my
>> needs, I just created one uber-bundle for Accumulo packages and imported
>> the necessary non-Accumulo packages (many of those I had to wrap as well).
>> I didn't find that part too painful on the Accumulo side. While not being
>> the ideal situation from the OSGI side, with lack of an existing bundle
>> artifact, it did solve my problem and I'm actively using both Accumulo and
>> Hadoop in OSGi. My recommendation would be that until we get a proper
>> bundle, that solution would certainly work in the short-term.
>>
>> I believe Josh posted this already but check out [1]. A ready-to-go OSGi
>> bundle for Accumulo would be useful but the Hadoop client dependency would
>> need to be wrapped (or exposed as its own bundle). IMO, with proper
>> documentation this shouldn't be too painful for users. Thoughts?
>>
>>
>> [1] https://issues.apache.org/jira/browse/ACCUMULO-2518
>>
>>
>> On Mon, Apr 7, 2014 at 11:27 AM, Geoffry Roberts <th...@gmail.com>wrote:
>>
>>> Ahh,  let me try and address where I might have gone off the linguistic
>>> reservation.
>>>
>>> bndtools -- is an eclipse plugin that is very helpful when developing
>>> OSGi bundles.  It does a lot of grimy, boilerplate things for you.
>>>
>>> inlining -- is where one places dependent *.jar files inside the OSGi
>>> bundle and therefore on said bundle's class path.  It tends to promote
>>> bloated bundles--not in the spirit of OSGi--but sometimes necessary.
>>>
>>> componentizing -- is the business of converting a class into a
>>> component.  In the bndtools way of doing things, this can be a easy as
>>> annotating a class with @Component.
>>>
>>> bundle -- You probably know what this is already, but I'll include it
>>> for good measure.  A bundle is a body of code that is on the same class
>>> path, and often acts as a service to there bundles.
>>>
>>> I don't know what could be done upstream other that making Accumulo's
>>> client OAGI ready.  Would we like to do that?
>>>
>>>
>>> On Mon, Apr 7, 2014 at 11:02 AM, Josh Elser <jo...@gmail.com>wrote:
>>>
>>>> You just used a lot of words that don't mean anything to me :)
>>>>
>>>> Hopefully you don't have to do much on your own. If there are things we
>>>> can change upstream to make this process easier, please feel free to let us
>>>> know.
>>>>
>>>>
>>>> On 4/7/14, 10:55 AM, Geoffry Roberts wrote:
>>>>
>>>>> Thanks Josh,
>>>>>
>>>>> My container for the moment is equinox, but all should work in Felix as
>>>>> well.  I've been using bndtools for my other OSGi work so I'm faced
>>>>> with
>>>>> either annotating the Accumulo Code or wrapping it somehow.  What do
>>>>> you
>>>>> want to bet I wind up inlining it?  Still, the annotated (read
>>>>> componentized) approach would be less kloogy.  I hesitate because I'd
>>>>> wind up maintaining my own code line.
>>>>>
>>>>>
>>>>> On Mon, Apr 7, 2014 at 10:28 AM, Josh Elser <josh.elser@gmail.com
>>>>> <ma...@gmail.com>> wrote:
>>>>>
>>>>>     On 4/7/14, 10:07 AM, Geoffry Roberts wrote:
>>>>>
>>>>>         My original question remains: Is the Accumulo Client dependent
>>>>>         on the
>>>>>         Hadoop Client fully?  This determination can be made through
>>>>>         trial and
>>>>>         error.  But I'm looking to leverage OPE (other people's
>>>>>         experience) if
>>>>>         it exists.
>>>>>
>>>>>
>>>>>     I thought someone had already said this (but I may be confusing
>>>>>     threads): the Accumulo API uses Text throughout. Hadoop is a
>>>>>     required dependency.
>>>>>
>>>>>
>>>>>         In the same spirit, does anyone know if all the following are
>>>>>         required
>>>>>         to run an Accumulo Client? core, fate, start, trace?  If I
>>>>>         attempt to
>>>>>         OSGify, I'm trying to figure how much trouble am I getting
>>>>> into.
>>>>>
>>>>>
>>>>>     Yes, that should be about it from within Accumulo. You might need
>>>>>     some other foss dependencies also available, but I'm not aware on
>>>>>     what your "container" (or w/e the proper terminology would be)
>>>>> provides.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> There are ways and there are ways,
>>>>>
>>>>> Geoffry Roberts
>>>>>
>>>>
>>>
>>>
>>> --
>>> There are ways and there are ways,
>>>
>>> Geoffry Roberts
>>>
>>
>>
>
>
> --
> There are ways and there are ways,
>
> Geoffry Roberts
>

Re: Accumulo and OSGi

Posted by Geoffry Roberts <th...@gmail.com>.
Corey,


Interesting you have Hadoop working in Karaf.  I'm using equinox.  It also
sounds as if I don't need to access HFDS in order to get Accumulo to work
in OSGi. If I understand you correctly, I only need have Text available.
 I'll look into that. It does answer my question and maybe I can avoid the
JAAS mishmash.


I have been using OSGi off and on for a few years now. Close on to 100% of
my troubles has always been with getting 3rd party libraries working.
 Accumulo/Hadoop is only the latest round.


I'm gearing to do some major work based on Accumulo.  It's security,
scaleability, relationship to Hadoop's HDFS and MR all conspire to make it
attractive.  But creating an uberbundle? I'm sure I could get it working as
a proof of concept, but will it play in prime-time?


How hard would it be to make a proper Accumulo bundle?  Would the community
accept it?


Thanks


So far as my travails with JAAS is concerned, I did this in my bndtools
*.bndrun file:


-runproperties:
org.osgi.framework.system.packages.extra=com.sun.security.auth.module

I also tried:
Import-Package: com.sun.security.auth.module
in my bundle that calls Hadoop.

Both of these were advised by one of the bndtools gurus--neither worked.
 When I did the Import-Package other things broke.

On Wed, Apr 9, 2014 at 9:46 AM, Corey Nolet <cj...@gmail.com> wrote:

> Geoffry,
>
> As Josh pointed out, you should only need the Hadoop libraries on the
> client side to use the Text object. This means you won't have to go through
> the pain of placing the xml files in your root bundles.
>
> Did you try the JAAS export from the packages in your container? Did that
> help?
>
> I agree with your comment that we *should* be able to look at these
> bundles as black boxes but we're not dealing with true bundles, yet. Once I
> got my Hadoop client bundle ready to go, I haven't had to touch it (and the
> Hadoop Karaf project solved most of the import/export guessing work for me
> already).  For Accumulo, on the other hand, it's up to you if you want to
> create an uber-bundle with the necessary Accumulo packages or just wrap
> each one and provide the necessary imports/exports across them. For my
> needs, I just created one uber-bundle for Accumulo packages and imported
> the necessary non-Accumulo packages (many of those I had to wrap as well).
> I didn't find that part too painful on the Accumulo side. While not being
> the ideal situation from the OSGI side, with lack of an existing bundle
> artifact, it did solve my problem and I'm actively using both Accumulo and
> Hadoop in OSGi. My recommendation would be that until we get a proper
> bundle, that solution would certainly work in the short-term.
>
> I believe Josh posted this already but check out [1]. A ready-to-go OSGi
> bundle for Accumulo would be useful but the Hadoop client dependency would
> need to be wrapped (or exposed as its own bundle). IMO, with proper
> documentation this shouldn't be too painful for users. Thoughts?
>
>
> [1] https://issues.apache.org/jira/browse/ACCUMULO-2518
>
>
> On Mon, Apr 7, 2014 at 11:27 AM, Geoffry Roberts <th...@gmail.com>wrote:
>
>> Ahh,  let me try and address where I might have gone off the linguistic
>> reservation.
>>
>> bndtools -- is an eclipse plugin that is very helpful when developing
>> OSGi bundles.  It does a lot of grimy, boilerplate things for you.
>>
>> inlining -- is where one places dependent *.jar files inside the OSGi
>> bundle and therefore on said bundle's class path.  It tends to promote
>> bloated bundles--not in the spirit of OSGi--but sometimes necessary.
>>
>> componentizing -- is the business of converting a class into a component.
>>  In the bndtools way of doing things, this can be a easy as annotating a
>> class with @Component.
>>
>> bundle -- You probably know what this is already, but I'll include it for
>> good measure.  A bundle is a body of code that is on the same class path,
>> and often acts as a service to there bundles.
>>
>> I don't know what could be done upstream other that making Accumulo's
>> client OAGI ready.  Would we like to do that?
>>
>>
>> On Mon, Apr 7, 2014 at 11:02 AM, Josh Elser <jo...@gmail.com> wrote:
>>
>>> You just used a lot of words that don't mean anything to me :)
>>>
>>> Hopefully you don't have to do much on your own. If there are things we
>>> can change upstream to make this process easier, please feel free to let us
>>> know.
>>>
>>>
>>> On 4/7/14, 10:55 AM, Geoffry Roberts wrote:
>>>
>>>> Thanks Josh,
>>>>
>>>> My container for the moment is equinox, but all should work in Felix as
>>>> well.  I've been using bndtools for my other OSGi work so I'm faced with
>>>> either annotating the Accumulo Code or wrapping it somehow.  What do you
>>>> want to bet I wind up inlining it?  Still, the annotated (read
>>>> componentized) approach would be less kloogy.  I hesitate because I'd
>>>> wind up maintaining my own code line.
>>>>
>>>>
>>>> On Mon, Apr 7, 2014 at 10:28 AM, Josh Elser <josh.elser@gmail.com
>>>> <ma...@gmail.com>> wrote:
>>>>
>>>>     On 4/7/14, 10:07 AM, Geoffry Roberts wrote:
>>>>
>>>>         My original question remains: Is the Accumulo Client dependent
>>>>         on the
>>>>         Hadoop Client fully?  This determination can be made through
>>>>         trial and
>>>>         error.  But I'm looking to leverage OPE (other people's
>>>>         experience) if
>>>>         it exists.
>>>>
>>>>
>>>>     I thought someone had already said this (but I may be confusing
>>>>     threads): the Accumulo API uses Text throughout. Hadoop is a
>>>>     required dependency.
>>>>
>>>>
>>>>         In the same spirit, does anyone know if all the following are
>>>>         required
>>>>         to run an Accumulo Client? core, fate, start, trace?  If I
>>>>         attempt to
>>>>         OSGify, I'm trying to figure how much trouble am I getting into.
>>>>
>>>>
>>>>     Yes, that should be about it from within Accumulo. You might need
>>>>     some other foss dependencies also available, but I'm not aware on
>>>>     what your "container" (or w/e the proper terminology would be)
>>>> provides.
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> There are ways and there are ways,
>>>>
>>>> Geoffry Roberts
>>>>
>>>
>>
>>
>> --
>> There are ways and there are ways,
>>
>> Geoffry Roberts
>>
>
>


-- 
There are ways and there are ways,

Geoffry Roberts

Re: Accumulo and OSGi

Posted by Corey Nolet <cj...@gmail.com>.
Geoffry,

As Josh pointed out, you should only need the Hadoop libraries on the
client side to use the Text object. This means you won't have to go through
the pain of placing the xml files in your root bundles.

Did you try the JAAS export from the packages in your container? Did that
help?

I agree with your comment that we *should* be able to look at these bundles
as black boxes but we're not dealing with true bundles, yet. Once I got my
Hadoop client bundle ready to go, I haven't had to touch it (and the Hadoop
Karaf project solved most of the import/export guessing work for me
already).  For Accumulo, on the other hand, it's up to you if you want to
create an uber-bundle with the necessary Accumulo packages or just wrap
each one and provide the necessary imports/exports across them. For my
needs, I just created one uber-bundle for Accumulo packages and imported
the necessary non-Accumulo packages (many of those I had to wrap as well).
I didn't find that part too painful on the Accumulo side. While not being
the ideal situation from the OSGI side, with lack of an existing bundle
artifact, it did solve my problem and I'm actively using both Accumulo and
Hadoop in OSGi. My recommendation would be that until we get a proper
bundle, that solution would certainly work in the short-term.

I believe Josh posted this already but check out [1]. A ready-to-go OSGi
bundle for Accumulo would be useful but the Hadoop client dependency would
need to be wrapped (or exposed as its own bundle). IMO, with proper
documentation this shouldn't be too painful for users. Thoughts?


[1] https://issues.apache.org/jira/browse/ACCUMULO-2518


On Mon, Apr 7, 2014 at 11:27 AM, Geoffry Roberts <th...@gmail.com>wrote:

> Ahh,  let me try and address where I might have gone off the linguistic
> reservation.
>
> bndtools -- is an eclipse plugin that is very helpful when developing OSGi
> bundles.  It does a lot of grimy, boilerplate things for you.
>
> inlining -- is where one places dependent *.jar files inside the OSGi
> bundle and therefore on said bundle's class path.  It tends to promote
> bloated bundles--not in the spirit of OSGi--but sometimes necessary.
>
> componentizing -- is the business of converting a class into a component.
>  In the bndtools way of doing things, this can be a easy as annotating a
> class with @Component.
>
> bundle -- You probably know what this is already, but I'll include it for
> good measure.  A bundle is a body of code that is on the same class path,
> and often acts as a service to there bundles.
>
> I don't know what could be done upstream other that making Accumulo's
> client OAGI ready.  Would we like to do that?
>
>
> On Mon, Apr 7, 2014 at 11:02 AM, Josh Elser <jo...@gmail.com> wrote:
>
>> You just used a lot of words that don't mean anything to me :)
>>
>> Hopefully you don't have to do much on your own. If there are things we
>> can change upstream to make this process easier, please feel free to let us
>> know.
>>
>>
>> On 4/7/14, 10:55 AM, Geoffry Roberts wrote:
>>
>>> Thanks Josh,
>>>
>>> My container for the moment is equinox, but all should work in Felix as
>>> well.  I've been using bndtools for my other OSGi work so I'm faced with
>>> either annotating the Accumulo Code or wrapping it somehow.  What do you
>>> want to bet I wind up inlining it?  Still, the annotated (read
>>> componentized) approach would be less kloogy.  I hesitate because I'd
>>> wind up maintaining my own code line.
>>>
>>>
>>> On Mon, Apr 7, 2014 at 10:28 AM, Josh Elser <josh.elser@gmail.com
>>> <ma...@gmail.com>> wrote:
>>>
>>>     On 4/7/14, 10:07 AM, Geoffry Roberts wrote:
>>>
>>>         My original question remains: Is the Accumulo Client dependent
>>>         on the
>>>         Hadoop Client fully?  This determination can be made through
>>>         trial and
>>>         error.  But I'm looking to leverage OPE (other people's
>>>         experience) if
>>>         it exists.
>>>
>>>
>>>     I thought someone had already said this (but I may be confusing
>>>     threads): the Accumulo API uses Text throughout. Hadoop is a
>>>     required dependency.
>>>
>>>
>>>         In the same spirit, does anyone know if all the following are
>>>         required
>>>         to run an Accumulo Client? core, fate, start, trace?  If I
>>>         attempt to
>>>         OSGify, I'm trying to figure how much trouble am I getting into.
>>>
>>>
>>>     Yes, that should be about it from within Accumulo. You might need
>>>     some other foss dependencies also available, but I'm not aware on
>>>     what your "container" (or w/e the proper terminology would be)
>>> provides.
>>>
>>>
>>>
>>>
>>> --
>>> There are ways and there are ways,
>>>
>>> Geoffry Roberts
>>>
>>
>
>
> --
> There are ways and there are ways,
>
> Geoffry Roberts
>

Re: Accumulo and OSGi

Posted by Geoffry Roberts <th...@gmail.com>.
Ahh,  let me try and address where I might have gone off the linguistic
reservation.

bndtools -- is an eclipse plugin that is very helpful when developing OSGi
bundles.  It does a lot of grimy, boilerplate things for you.

inlining -- is where one places dependent *.jar files inside the OSGi
bundle and therefore on said bundle's class path.  It tends to promote
bloated bundles--not in the spirit of OSGi--but sometimes necessary.

componentizing -- is the business of converting a class into a component.
 In the bndtools way of doing things, this can be a easy as annotating a
class with @Component.

bundle -- You probably know what this is already, but I'll include it for
good measure.  A bundle is a body of code that is on the same class path,
and often acts as a service to there bundles.

I don't know what could be done upstream other that making Accumulo's
client OAGI ready.  Would we like to do that?


On Mon, Apr 7, 2014 at 11:02 AM, Josh Elser <jo...@gmail.com> wrote:

> You just used a lot of words that don't mean anything to me :)
>
> Hopefully you don't have to do much on your own. If there are things we
> can change upstream to make this process easier, please feel free to let us
> know.
>
>
> On 4/7/14, 10:55 AM, Geoffry Roberts wrote:
>
>> Thanks Josh,
>>
>> My container for the moment is equinox, but all should work in Felix as
>> well.  I've been using bndtools for my other OSGi work so I'm faced with
>> either annotating the Accumulo Code or wrapping it somehow.  What do you
>> want to bet I wind up inlining it?  Still, the annotated (read
>> componentized) approach would be less kloogy.  I hesitate because I'd
>> wind up maintaining my own code line.
>>
>>
>> On Mon, Apr 7, 2014 at 10:28 AM, Josh Elser <josh.elser@gmail.com
>> <ma...@gmail.com>> wrote:
>>
>>     On 4/7/14, 10:07 AM, Geoffry Roberts wrote:
>>
>>         My original question remains: Is the Accumulo Client dependent
>>         on the
>>         Hadoop Client fully?  This determination can be made through
>>         trial and
>>         error.  But I'm looking to leverage OPE (other people's
>>         experience) if
>>         it exists.
>>
>>
>>     I thought someone had already said this (but I may be confusing
>>     threads): the Accumulo API uses Text throughout. Hadoop is a
>>     required dependency.
>>
>>
>>         In the same spirit, does anyone know if all the following are
>>         required
>>         to run an Accumulo Client? core, fate, start, trace?  If I
>>         attempt to
>>         OSGify, I'm trying to figure how much trouble am I getting into.
>>
>>
>>     Yes, that should be about it from within Accumulo. You might need
>>     some other foss dependencies also available, but I'm not aware on
>>     what your "container" (or w/e the proper terminology would be)
>> provides.
>>
>>
>>
>>
>> --
>> There are ways and there are ways,
>>
>> Geoffry Roberts
>>
>


-- 
There are ways and there are ways,

Geoffry Roberts

Re: Accumulo and OSGi

Posted by Josh Elser <jo...@gmail.com>.
You just used a lot of words that don't mean anything to me :)

Hopefully you don't have to do much on your own. If there are things we 
can change upstream to make this process easier, please feel free to let 
us know.

On 4/7/14, 10:55 AM, Geoffry Roberts wrote:
> Thanks Josh,
>
> My container for the moment is equinox, but all should work in Felix as
> well.  I've been using bndtools for my other OSGi work so I'm faced with
> either annotating the Accumulo Code or wrapping it somehow.  What do you
> want to bet I wind up inlining it?  Still, the annotated (read
> componentized) approach would be less kloogy.  I hesitate because I'd
> wind up maintaining my own code line.
>
>
> On Mon, Apr 7, 2014 at 10:28 AM, Josh Elser <josh.elser@gmail.com
> <ma...@gmail.com>> wrote:
>
>     On 4/7/14, 10:07 AM, Geoffry Roberts wrote:
>
>         My original question remains: Is the Accumulo Client dependent
>         on the
>         Hadoop Client fully?  This determination can be made through
>         trial and
>         error.  But I'm looking to leverage OPE (other people's
>         experience) if
>         it exists.
>
>
>     I thought someone had already said this (but I may be confusing
>     threads): the Accumulo API uses Text throughout. Hadoop is a
>     required dependency.
>
>
>         In the same spirit, does anyone know if all the following are
>         required
>         to run an Accumulo Client? core, fate, start, trace?  If I
>         attempt to
>         OSGify, I'm trying to figure how much trouble am I getting into.
>
>
>     Yes, that should be about it from within Accumulo. You might need
>     some other foss dependencies also available, but I'm not aware on
>     what your "container" (or w/e the proper terminology would be) provides.
>
>
>
>
> --
> There are ways and there are ways,
>
> Geoffry Roberts

Re: Accumulo and OSGi

Posted by Geoffry Roberts <th...@gmail.com>.
Thanks Josh,

My container for the moment is equinox, but all should work in Felix as
well.  I've been using bndtools for my other OSGi work so I'm faced with
either annotating the Accumulo Code or wrapping it somehow.  What do you
want to bet I wind up inlining it?  Still, the annotated (read
componentized) approach would be less kloogy.  I hesitate because I'd wind
up maintaining my own code line.


On Mon, Apr 7, 2014 at 10:28 AM, Josh Elser <jo...@gmail.com> wrote:

> On 4/7/14, 10:07 AM, Geoffry Roberts wrote:
>
>> My original question remains: Is the Accumulo Client dependent on the
>> Hadoop Client fully?  This determination can be made through trial and
>> error.  But I'm looking to leverage OPE (other people's experience) if
>> it exists.
>>
>
> I thought someone had already said this (but I may be confusing threads):
> the Accumulo API uses Text throughout. Hadoop is a required dependency.
>
>
>  In the same spirit, does anyone know if all the following are required
>> to run an Accumulo Client? core, fate, start, trace?  If I attempt to
>> OSGify, I'm trying to figure how much trouble am I getting into.
>>
>
> Yes, that should be about it from within Accumulo. You might need some
> other foss dependencies also available, but I'm not aware on what your
> "container" (or w/e the proper terminology would be) provides.
>



-- 
There are ways and there are ways,

Geoffry Roberts

Re: Accumulo and OSGi

Posted by Josh Elser <jo...@gmail.com>.
On 4/7/14, 10:07 AM, Geoffry Roberts wrote:
> My original question remains: Is the Accumulo Client dependent on the
> Hadoop Client fully?  This determination can be made through trial and
> error.  But I'm looking to leverage OPE (other people's experience) if
> it exists.

I thought someone had already said this (but I may be confusing 
threads): the Accumulo API uses Text throughout. Hadoop is a required 
dependency.

> In the same spirit, does anyone know if all the following are required
> to run an Accumulo Client? core, fate, start, trace?  If I attempt to
> OSGify, I'm trying to figure how much trouble am I getting into.

Yes, that should be about it from within Accumulo. You might need some 
other foss dependencies also available, but I'm not aware on what your 
"container" (or w/e the proper terminology would be) provides.

Re: Accumulo and OSGi

Posted by Geoffry Roberts <th...@gmail.com>.
Thanks Corey,

I appreciate your insights wrt the internal nature of the Hadoop Client.  I
hadn't yet opened it up.  Ideally, we should be able to use these things as
black boxes, or so the theory goes. Nevertheless, I'll look into your notes.

My original question remains: Is the Accumulo Client dependent on the
Hadoop Client fully?  This determination can be made through trial and
error.  But I'm looking to leverage OPE (other people's experience) if it
exists.

In the same spirit, does anyone know if all the following are required to
run an Accumulo Client? core, fate, start, trace?  If I attempt to OSGify,
I'm trying to figure how much trouble am I getting into.

Thanks all.


On Sun, Apr 6, 2014 at 11:54 AM, Corey Nolet <cj...@gmail.com> wrote:

> Geoffrey,
>
> My quick answer is that I needed to adjust my container (Karaf in my case)
> to export the JAAS packages because they come in the JRE. Then I needed to
> make the hadoop bundle import them.
>
> Also before I forget, Hadoop packages its default xml configurations
> (core-site.xml, core-default.xml, etc...) in the default namespace so they
> can't be exported. For this reason, you need to make sure they are included
> at the root bundle level of any bundles needing to use the client (this
> should pertain to the libraries needing the filesystem object, not bundles
> that just  need the Text object, for instance...).
>
> That's my quick answer on my phone. Ill look into the rest and provide a
> more detailed description of what I did.
>
> I went through this headache too and it would help to capture the solution
> somewhere (like this thread)
> On Apr 6, 2014 11:18 AM, "Geoffry Roberts" <th...@gmail.com> wrote:
>
>> All,
>>
>> To what extent does the Accumulo Client rely on the Hadoop Client?  I
>> apologize if the question is a bit obtuse.  But I got into dependency weeds
>> trying to get the Hadoop Client to work in OSGI.  (See below Hadoop Client
>> woes)   I am now wondering if I OSGified Accumulo's client would I
>> encounter the same-old-same-old or somehow dodge the bullet.
>>
>> Would anyone else be interested?
>>
>> <Hadoop Client woes>
>> I sat down to do what Corey suggested and took a shot at getting the
>> Hadoop Client working in OSGi.  I used the service mix bundles, but alas,
>> it seems that somewhere in the dependencies something wants to use JAAS and
>> that is stopping the show.  I creating a fragment that exports the required
>> package so OSGI can find them--nothing doing; I'm stuck.
>>
>> If one Googles, one finds JAAS is problematic in OSGi as are a number of
>> J2EE technologies.
>> </Hadoop Client woes>
>>
>>
>> On Tue, Apr 1, 2014 at 11:22 AM, Geoffry Roberts <th...@gmail.com>wrote:
>>
>>> Thank you Corey,
>>>
>>> I was unaware of the service mix Hadoop client.  It's funny that no one
>>> on the Hadoop list ever mentioned it.
>>>
>>> You say you have 1.4 working in OSGi. Did you do a proper port or just
>>> wrap it with something like bnd?   I have Hadoop 2.3.0 so I need to use
>>> Accumulo 1.5.1.  I'm glad to hear the bane of split packages has been put
>>> asunder.
>>>
>>> I am using equinox for now.  Most of my legacy code in based on bndtools
>>> and I exercise it in equinox.  I've used equinox in the past for production
>>> and things went well.
>>>
>>> I just grabbed the Hadoop core & client from service mix then zookeeper.
>>> At the least, they were accepted into my bndtools repository as valid
>>> bundles.  I noticed that a number of the usual Hadoop dependencies are in
>>> service mix as well so I sense a glimmer of hope. Wrt Accumulo, I think
>>> I'll take a stab at either wrapping or porting core, frame, start, and
>>> trace to OSGi and see how much trouble I get into.
>>>
>>> It's either do the above or abandon OSGi altogether for this project.
>>>
>>> My objective is to persist EMF object graphs into Accumulo.  These
>>> graphs were built by others and are based on ISO standards so I need to
>>> walk the straight and narrow and not drop a stitch.  I have code that does
>>> what I need (persist any graph sight unseen) into MongoDB.  I need to adapt
>>> said code to Accumulo. All the above is OSGi based so it would really help
>>> if I can keep the Accumulo end of things in OSGi as well.
>>>
>>> Wish me well
>>>
>>>
>>> On Mon, Mar 31, 2014 at 8:34 PM, Corey Nolet <cj...@gmail.com> wrote:
>>>
>>>> Geoffry,
>>>>
>>>> What OSGi container are you using currently? The servicemix Hadoop
>>>> bundle should get you going with the Hadoop client dependencies at least
>>>> [1]. It looks like one of the servicemix guys created a Hadoop ticket for
>>>> making bundles of their jars as well [2], though it doesn't look like
>>>> there's been any movement on it.
>>>>
>>>> I recently had to get the CDH3u4 client code working in Karaf. A good
>>>> starting place for me was [3], however I did need to make updates to
>>>> versions of many of the dependencies to get it functioning as expected. [3]
>>>> will get you at least started with dependent bundles and the proper
>>>> imports/exports to get it working.
>>>>
>>>> I've got the Accumulo client running in OSGi. If I recall correctly,
>>>> versions 1.4 and above do not split packages across jars so it's really
>>>> just a matter of getting the dependencies right. Zookeeper also ships as a
>>>> bundle [4].
>>>>
>>>>
>>>> Hope this helps.
>>>>
>>>> [1]
>>>> http://mvnrepository.com/artifact/org.apache.servicemix.bundles/org.apache.servicemix.bundles.hadoop-core/
>>>>  [2] https://issues.apache.org/jira/browse/HADOOP-8446
>>>> [3] https://github.com/jbonofre/karaf-hadoop
>>>> [4] https://issues.apache.org/jira/browse/ZOOKEEPER-425
>>>>
>>>>
>>>>
>>>> On Mon, Mar 31, 2014 at 11:37 AM, Geoffry Roberts <
>>>> threadedblue@gmail.com> wrote:
>>>>
>>>>> Luk,
>>>>>
>>>>> Thanks for the link, but I am a bit lost.  wso2 offers middleware,
>>>>> apparently you believe this will help my situation.  If it's not too much,
>>>>> can you expand?
>>>>>
>>>>>
>>>>> On Mon, Mar 31, 2014 at 11:13 AM, Luk Vervenne <lu...@synergetics.be>wrote:
>>>>>
>>>>>> osgi... see wso2.com
>>>>>>
>>>>>> On 31 Mar 2014, at 16:58, Geoffry Roberts <th...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> > All,
>>>>>> >
>>>>>> > I have a project for which Accumulo it appears will serve well.
>>>>>>  However, I have a significant amount of code I want to leverage that runs
>>>>>> in OSGi.  I don't need for Accumulo itself to be OSGi based but the
>>>>>> Accumulo client yes.  I see that the Accumulo client uses all the
>>>>>> dependencies of the Hadoop client and therefore is not OSGi ready at this
>>>>>> time.  The Hadoop client certainly doesn't do OSGi--I don't think it can
>>>>>> even spell it :-)--and attempting to make it so starts turning into a sure
>>>>>> path to a long sojourn through dependency hell.  I know, I've tried.
>>>>>> >
>>>>>> > Nonetheless, I would like to ask: Is there any interest in the
>>>>>> Accumulo world of having an OSGi based client for this otherwise very
>>>>>> appealing database?
>>>>>> >
>>>>>> > Thanks mucho
>>>>>> > --
>>>>>> > There are ways and there are ways,
>>>>>> >
>>>>>> > Geoffry Roberts
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> There are ways and there are ways,
>>>>>
>>>>> Geoffry Roberts
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> There are ways and there are ways,
>>>
>>> Geoffry Roberts
>>>
>>
>>
>>
>> --
>> There are ways and there are ways,
>>
>> Geoffry Roberts
>>
>


-- 
There are ways and there are ways,

Geoffry Roberts

Re: Accumulo and OSGi

Posted by Corey Nolet <cj...@gmail.com>.
Geoffrey,

My quick answer is that I needed to adjust my container (Karaf in my case)
to export the JAAS packages because they come in the JRE. Then I needed to
make the hadoop bundle import them.

Also before I forget, Hadoop packages its default xml configurations
(core-site.xml, core-default.xml, etc...) in the default namespace so they
can't be exported. For this reason, you need to make sure they are included
at the root bundle level of any bundles needing to use the client (this
should pertain to the libraries needing the filesystem object, not bundles
that just  need the Text object, for instance...).

That's my quick answer on my phone. Ill look into the rest and provide a
more detailed description of what I did.

I went through this headache too and it would help to capture the solution
somewhere (like this thread)
On Apr 6, 2014 11:18 AM, "Geoffry Roberts" <th...@gmail.com> wrote:

> All,
>
> To what extent does the Accumulo Client rely on the Hadoop Client?  I
> apologize if the question is a bit obtuse.  But I got into dependency weeds
> trying to get the Hadoop Client to work in OSGI.  (See below Hadoop Client
> woes)   I am now wondering if I OSGified Accumulo's client would I
> encounter the same-old-same-old or somehow dodge the bullet.
>
> Would anyone else be interested?
>
> <Hadoop Client woes>
> I sat down to do what Corey suggested and took a shot at getting the
> Hadoop Client working in OSGi.  I used the service mix bundles, but alas,
> it seems that somewhere in the dependencies something wants to use JAAS and
> that is stopping the show.  I creating a fragment that exports the required
> package so OSGI can find them--nothing doing; I'm stuck.
>
> If one Googles, one finds JAAS is problematic in OSGi as are a number of
> J2EE technologies.
> </Hadoop Client woes>
>
>
> On Tue, Apr 1, 2014 at 11:22 AM, Geoffry Roberts <th...@gmail.com>wrote:
>
>> Thank you Corey,
>>
>> I was unaware of the service mix Hadoop client.  It's funny that no one
>> on the Hadoop list ever mentioned it.
>>
>> You say you have 1.4 working in OSGi. Did you do a proper port or just
>> wrap it with something like bnd?   I have Hadoop 2.3.0 so I need to use
>> Accumulo 1.5.1.  I'm glad to hear the bane of split packages has been put
>> asunder.
>>
>> I am using equinox for now.  Most of my legacy code in based on bndtools
>> and I exercise it in equinox.  I've used equinox in the past for production
>> and things went well.
>>
>> I just grabbed the Hadoop core & client from service mix then zookeeper.
>> At the least, they were accepted into my bndtools repository as valid
>> bundles.  I noticed that a number of the usual Hadoop dependencies are in
>> service mix as well so I sense a glimmer of hope. Wrt Accumulo, I think
>> I'll take a stab at either wrapping or porting core, frame, start, and
>> trace to OSGi and see how much trouble I get into.
>>
>> It's either do the above or abandon OSGi altogether for this project.
>>
>> My objective is to persist EMF object graphs into Accumulo.  These graphs
>> were built by others and are based on ISO standards so I need to walk the
>> straight and narrow and not drop a stitch.  I have code that does what I
>> need (persist any graph sight unseen) into MongoDB.  I need to adapt said
>> code to Accumulo. All the above is OSGi based so it would really help if I
>> can keep the Accumulo end of things in OSGi as well.
>>
>> Wish me well
>>
>>
>> On Mon, Mar 31, 2014 at 8:34 PM, Corey Nolet <cj...@gmail.com> wrote:
>>
>>> Geoffry,
>>>
>>> What OSGi container are you using currently? The servicemix Hadoop
>>> bundle should get you going with the Hadoop client dependencies at least
>>> [1]. It looks like one of the servicemix guys created a Hadoop ticket for
>>> making bundles of their jars as well [2], though it doesn't look like
>>> there's been any movement on it.
>>>
>>> I recently had to get the CDH3u4 client code working in Karaf. A good
>>> starting place for me was [3], however I did need to make updates to
>>> versions of many of the dependencies to get it functioning as expected. [3]
>>> will get you at least started with dependent bundles and the proper
>>> imports/exports to get it working.
>>>
>>> I've got the Accumulo client running in OSGi. If I recall correctly,
>>> versions 1.4 and above do not split packages across jars so it's really
>>> just a matter of getting the dependencies right. Zookeeper also ships as a
>>> bundle [4].
>>>
>>>
>>> Hope this helps.
>>>
>>> [1]
>>> http://mvnrepository.com/artifact/org.apache.servicemix.bundles/org.apache.servicemix.bundles.hadoop-core/
>>>  [2] https://issues.apache.org/jira/browse/HADOOP-8446
>>> [3] https://github.com/jbonofre/karaf-hadoop
>>> [4] https://issues.apache.org/jira/browse/ZOOKEEPER-425
>>>
>>>
>>>
>>> On Mon, Mar 31, 2014 at 11:37 AM, Geoffry Roberts <
>>> threadedblue@gmail.com> wrote:
>>>
>>>> Luk,
>>>>
>>>> Thanks for the link, but I am a bit lost.  wso2 offers middleware,
>>>> apparently you believe this will help my situation.  If it's not too much,
>>>> can you expand?
>>>>
>>>>
>>>> On Mon, Mar 31, 2014 at 11:13 AM, Luk Vervenne <lu...@synergetics.be>wrote:
>>>>
>>>>> osgi... see wso2.com
>>>>>
>>>>> On 31 Mar 2014, at 16:58, Geoffry Roberts <th...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> > All,
>>>>> >
>>>>> > I have a project for which Accumulo it appears will serve well.
>>>>>  However, I have a significant amount of code I want to leverage that runs
>>>>> in OSGi.  I don't need for Accumulo itself to be OSGi based but the
>>>>> Accumulo client yes.  I see that the Accumulo client uses all the
>>>>> dependencies of the Hadoop client and therefore is not OSGi ready at this
>>>>> time.  The Hadoop client certainly doesn't do OSGi--I don't think it can
>>>>> even spell it :-)--and attempting to make it so starts turning into a sure
>>>>> path to a long sojourn through dependency hell.  I know, I've tried.
>>>>> >
>>>>> > Nonetheless, I would like to ask: Is there any interest in the
>>>>> Accumulo world of having an OSGi based client for this otherwise very
>>>>> appealing database?
>>>>> >
>>>>> > Thanks mucho
>>>>> > --
>>>>> > There are ways and there are ways,
>>>>> >
>>>>> > Geoffry Roberts
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> There are ways and there are ways,
>>>>
>>>> Geoffry Roberts
>>>>
>>>
>>>
>>
>>
>> --
>> There are ways and there are ways,
>>
>> Geoffry Roberts
>>
>
>
>
> --
> There are ways and there are ways,
>
> Geoffry Roberts
>

Re: Accumulo and OSGi

Posted by Geoffry Roberts <th...@gmail.com>.
All,

To what extent does the Accumulo Client rely on the Hadoop Client?  I
apologize if the question is a bit obtuse.  But I got into dependency weeds
trying to get the Hadoop Client to work in OSGI.  (See below Hadoop Client
woes)   I am now wondering if I OSGified Accumulo's client would I
encounter the same-old-same-old or somehow dodge the bullet.

Would anyone else be interested?

<Hadoop Client woes>
I sat down to do what Corey suggested and took a shot at getting the Hadoop
Client working in OSGi.  I used the service mix bundles, but alas, it seems
that somewhere in the dependencies something wants to use JAAS and that is
stopping the show.  I creating a fragment that exports the required package
so OSGI can find them--nothing doing; I'm stuck.

If one Googles, one finds JAAS is problematic in OSGi as are a number of
J2EE technologies.
</Hadoop Client woes>


On Tue, Apr 1, 2014 at 11:22 AM, Geoffry Roberts <th...@gmail.com>wrote:

> Thank you Corey,
>
> I was unaware of the service mix Hadoop client.  It's funny that no one on
> the Hadoop list ever mentioned it.
>
> You say you have 1.4 working in OSGi. Did you do a proper port or just
> wrap it with something like bnd?   I have Hadoop 2.3.0 so I need to use
> Accumulo 1.5.1.  I'm glad to hear the bane of split packages has been put
> asunder.
>
> I am using equinox for now.  Most of my legacy code in based on bndtools
> and I exercise it in equinox.  I've used equinox in the past for production
> and things went well.
>
> I just grabbed the Hadoop core & client from service mix then zookeeper.
> At the least, they were accepted into my bndtools repository as valid
> bundles.  I noticed that a number of the usual Hadoop dependencies are in
> service mix as well so I sense a glimmer of hope. Wrt Accumulo, I think
> I'll take a stab at either wrapping or porting core, frame, start, and
> trace to OSGi and see how much trouble I get into.
>
> It's either do the above or abandon OSGi altogether for this project.
>
> My objective is to persist EMF object graphs into Accumulo.  These graphs
> were built by others and are based on ISO standards so I need to walk the
> straight and narrow and not drop a stitch.  I have code that does what I
> need (persist any graph sight unseen) into MongoDB.  I need to adapt said
> code to Accumulo. All the above is OSGi based so it would really help if I
> can keep the Accumulo end of things in OSGi as well.
>
> Wish me well
>
>
> On Mon, Mar 31, 2014 at 8:34 PM, Corey Nolet <cj...@gmail.com> wrote:
>
>> Geoffry,
>>
>> What OSGi container are you using currently? The servicemix Hadoop bundle
>> should get you going with the Hadoop client dependencies at least [1]. It
>> looks like one of the servicemix guys created a Hadoop ticket for making
>> bundles of their jars as well [2], though it doesn't look like there's been
>> any movement on it.
>>
>> I recently had to get the CDH3u4 client code working in Karaf. A good
>> starting place for me was [3], however I did need to make updates to
>> versions of many of the dependencies to get it functioning as expected. [3]
>> will get you at least started with dependent bundles and the proper
>> imports/exports to get it working.
>>
>> I've got the Accumulo client running in OSGi. If I recall correctly,
>> versions 1.4 and above do not split packages across jars so it's really
>> just a matter of getting the dependencies right. Zookeeper also ships as a
>> bundle [4].
>>
>>
>> Hope this helps.
>>
>> [1]
>> http://mvnrepository.com/artifact/org.apache.servicemix.bundles/org.apache.servicemix.bundles.hadoop-core/
>>  [2] https://issues.apache.org/jira/browse/HADOOP-8446
>> [3] https://github.com/jbonofre/karaf-hadoop
>> [4] https://issues.apache.org/jira/browse/ZOOKEEPER-425
>>
>>
>>
>> On Mon, Mar 31, 2014 at 11:37 AM, Geoffry Roberts <threadedblue@gmail.com
>> > wrote:
>>
>>> Luk,
>>>
>>> Thanks for the link, but I am a bit lost.  wso2 offers middleware,
>>> apparently you believe this will help my situation.  If it's not too much,
>>> can you expand?
>>>
>>>
>>> On Mon, Mar 31, 2014 at 11:13 AM, Luk Vervenne <lu...@synergetics.be>wrote:
>>>
>>>> osgi... see wso2.com
>>>>
>>>> On 31 Mar 2014, at 16:58, Geoffry Roberts <th...@gmail.com>
>>>> wrote:
>>>>
>>>> > All,
>>>> >
>>>> > I have a project for which Accumulo it appears will serve well.
>>>>  However, I have a significant amount of code I want to leverage that runs
>>>> in OSGi.  I don't need for Accumulo itself to be OSGi based but the
>>>> Accumulo client yes.  I see that the Accumulo client uses all the
>>>> dependencies of the Hadoop client and therefore is not OSGi ready at this
>>>> time.  The Hadoop client certainly doesn't do OSGi--I don't think it can
>>>> even spell it :-)--and attempting to make it so starts turning into a sure
>>>> path to a long sojourn through dependency hell.  I know, I've tried.
>>>> >
>>>> > Nonetheless, I would like to ask: Is there any interest in the
>>>> Accumulo world of having an OSGi based client for this otherwise very
>>>> appealing database?
>>>> >
>>>> > Thanks mucho
>>>> > --
>>>> > There are ways and there are ways,
>>>> >
>>>> > Geoffry Roberts
>>>>
>>>>
>>>
>>>
>>> --
>>> There are ways and there are ways,
>>>
>>> Geoffry Roberts
>>>
>>
>>
>
>
> --
> There are ways and there are ways,
>
> Geoffry Roberts
>



-- 
There are ways and there are ways,

Geoffry Roberts

Re: Accumulo and OSGi

Posted by Geoffry Roberts <th...@gmail.com>.
Thank you Corey,

I was unaware of the service mix Hadoop client.  It's funny that no one on
the Hadoop list ever mentioned it.

You say you have 1.4 working in OSGi. Did you do a proper port or just wrap
it with something like bnd?   I have Hadoop 2.3.0 so I need to use Accumulo
1.5.1.  I'm glad to hear the bane of split packages has been put asunder.

I am using equinox for now.  Most of my legacy code in based on bndtools
and I exercise it in equinox.  I've used equinox in the past for production
and things went well.

I just grabbed the Hadoop core & client from service mix then zookeeper. At
the least, they were accepted into my bndtools repository as valid bundles.
 I noticed that a number of the usual Hadoop dependencies are in service
mix as well so I sense a glimmer of hope. Wrt Accumulo, I think I'll take a
stab at either wrapping or porting core, frame, start, and trace to OSGi
and see how much trouble I get into.

It's either do the above or abandon OSGi altogether for this project.

My objective is to persist EMF object graphs into Accumulo.  These graphs
were built by others and are based on ISO standards so I need to walk the
straight and narrow and not drop a stitch.  I have code that does what I
need (persist any graph sight unseen) into MongoDB.  I need to adapt said
code to Accumulo. All the above is OSGi based so it would really help if I
can keep the Accumulo end of things in OSGi as well.

Wish me well


On Mon, Mar 31, 2014 at 8:34 PM, Corey Nolet <cj...@gmail.com> wrote:

> Geoffry,
>
> What OSGi container are you using currently? The servicemix Hadoop bundle
> should get you going with the Hadoop client dependencies at least [1]. It
> looks like one of the servicemix guys created a Hadoop ticket for making
> bundles of their jars as well [2], though it doesn't look like there's been
> any movement on it.
>
> I recently had to get the CDH3u4 client code working in Karaf. A good
> starting place for me was [3], however I did need to make updates to
> versions of many of the dependencies to get it functioning as expected. [3]
> will get you at least started with dependent bundles and the proper
> imports/exports to get it working.
>
> I've got the Accumulo client running in OSGi. If I recall correctly,
> versions 1.4 and above do not split packages across jars so it's really
> just a matter of getting the dependencies right. Zookeeper also ships as a
> bundle [4].
>
>
> Hope this helps.
>
> [1]
> http://mvnrepository.com/artifact/org.apache.servicemix.bundles/org.apache.servicemix.bundles.hadoop-core/
>  [2] https://issues.apache.org/jira/browse/HADOOP-8446
> [3] https://github.com/jbonofre/karaf-hadoop
> [4] https://issues.apache.org/jira/browse/ZOOKEEPER-425
>
>
>
> On Mon, Mar 31, 2014 at 11:37 AM, Geoffry Roberts <th...@gmail.com>wrote:
>
>> Luk,
>>
>> Thanks for the link, but I am a bit lost.  wso2 offers middleware,
>> apparently you believe this will help my situation.  If it's not too much,
>> can you expand?
>>
>>
>> On Mon, Mar 31, 2014 at 11:13 AM, Luk Vervenne <lu...@synergetics.be>wrote:
>>
>>> osgi... see wso2.com
>>>
>>> On 31 Mar 2014, at 16:58, Geoffry Roberts <th...@gmail.com>
>>> wrote:
>>>
>>> > All,
>>> >
>>> > I have a project for which Accumulo it appears will serve well.
>>>  However, I have a significant amount of code I want to leverage that runs
>>> in OSGi.  I don't need for Accumulo itself to be OSGi based but the
>>> Accumulo client yes.  I see that the Accumulo client uses all the
>>> dependencies of the Hadoop client and therefore is not OSGi ready at this
>>> time.  The Hadoop client certainly doesn't do OSGi--I don't think it can
>>> even spell it :-)--and attempting to make it so starts turning into a sure
>>> path to a long sojourn through dependency hell.  I know, I've tried.
>>> >
>>> > Nonetheless, I would like to ask: Is there any interest in the
>>> Accumulo world of having an OSGi based client for this otherwise very
>>> appealing database?
>>> >
>>> > Thanks mucho
>>> > --
>>> > There are ways and there are ways,
>>> >
>>> > Geoffry Roberts
>>>
>>>
>>
>>
>> --
>> There are ways and there are ways,
>>
>> Geoffry Roberts
>>
>
>


-- 
There are ways and there are ways,

Geoffry Roberts