oodt-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Barber <tom.bar...@meteorite.bi>
Subject Re: Osgi stuff
Date Fri, 31 Jul 2015 18:09:29 GMT
Friday is for sharing(I think) or its certainly for drinking. Before I hit
beer o'clock I thought I'd share this little clip, as I'm hoping we can
merge some of this stuff back upstream to offer an alternative to OPSUI.

https://slack-files.com/T02531WE8-F08EFGLH1-85c44e77d8 (Hopefully you can
see that video)

Its very bare bones at the moment, but I have a central karaf server that
can accept remote services via DOSGI(currently SOAP CXF, but could also be
Hazelcast or another transport mechanism), anyway the window on the right
is a websocket connection that mimics what would eventually be a webpage
offering live stats about your OODT cluster.

The cool thing is the window in the middle is a Karaf wrapped filemanager
and it publishes its service via the DOSGI interface and could be located
anywhere in the world, but you still get access to its full API (I know
there is some rest stuff in the filemanager, but this can be replicated for
all the other components without me having to change their code initially).
You can see how it registers a new filemanager when I start it up and
pushes it to my websocket.

So, very rough, but provides some cool insight into some of the stuff that
we can do with OSGI/Karaf containers.

Happy friday.

Tom

On Fri, Jul 24, 2015 at 8:02 AM, Tom Barber <tom.barber@meteorite.bi> wrote:

> Thanks Paul
>
> I certainly think the natural modularity of oodt components lends itself
> nicely to osgi integration and usage.
>
> Tom
> On 23 Jul 2015 21:01, "Ramirez, Paul M (398M)" <
> paul.m.ramirez@jpl.nasa.gov> wrote:
>
>> +1 sounds great to me.
>>
>> --Paul
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Paul Ramirez, M.S.
>> Technical Group Supervisor
>> Computer Science for Data Intensive Applications (398M)
>> Instrument Software and Science Data Systems Section (398)
>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>> Office: 158-264, Mailstop: 158-242
>> Email: paul.m.ramirez@jpl.nasa.gov<mailto:paul.m.ramirez@jpl.nasa.gov>
>> Office: 818-354-1015
>> Cell: 818-395-8194
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> On Jul 23, 2015, at 11:23 AM, Chris Mattmann <mattmann@apache.org<mailto:
>> mattmann@apache.org>>
>>  wrote:
>>
>> Totally agree!
>>
>> JIRA issue time and if no one gets to it, maybe GSoC or student
>> project?
>>
>> —
>> Chris Mattmann
>> chris.mattmann@gmail.com<mailto:chris.mattmann@gmail.com>
>>
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: Tom Barber <tom.barber@meteorite.bi>
>> Reply-To: <dev@oodt.apache.org>
>> Date: Thursday, July 23, 2015 at 11:21 AM
>> To: <dev@oodt.apache.org>
>> Subject: Osgi stuff
>>
>> Taking that off of there and onto here about your mega bundle stuff. One
>> thing I would like to do with this little project over time is create a
>> karaf feature so people could run "feature:install oodt.xyz" and karaf
>> spin
>> up working OODT components radix style. I think that would be very useful.
>> On 23 Jul 2015 19:08, "chrismattmann" <git@git.apache.org> wrote:
>>
>> Github user chrismattmann commented on the pull request:
>>
>>    https://github.com/apache/oodt/pull/23#issuecomment-124189993
>>
>>    gotcha. That's fine, well then I wouldn't change the default
>> packaging
>> of the components from jar to bundle then. As you are doing in a profile
>> anyways with the plugin and dependencies, make the packaging also
>> something
>> that is dependent on the profile. I am +1 as long as it doesn't change
>> the
>> default behavior of jar packaging on these. @buggtb
>>
>>
>> ---
>> If your project is set up for it, you can reply to this email and have
>> your
>> reply appear on GitHub as well. If your project does not have this
>> feature
>> enabled and wishes so, or if the feature is enabled but not working,
>> please
>> contact infrastructure at infrastructure@apache.org or file a JIRA
>> ticket
>> with INFRA.
>> ---
>>
>>
>>
>>
>>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message