Return-Path: X-Original-To: apmail-oodt-dev-archive@www.apache.org Delivered-To: apmail-oodt-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 6FAB2181DB for ; Fri, 31 Jul 2015 18:10:10 +0000 (UTC) Received: (qmail 45760 invoked by uid 500); 31 Jul 2015 18:10:10 -0000 Delivered-To: apmail-oodt-dev-archive@oodt.apache.org Received: (qmail 45722 invoked by uid 500); 31 Jul 2015 18:10:10 -0000 Mailing-List: contact dev-help@oodt.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@oodt.apache.org Delivered-To: mailing list dev@oodt.apache.org Received: (qmail 45631 invoked by uid 99); 31 Jul 2015 18:10:10 -0000 Received: from Unknown (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 31 Jul 2015 18:10:10 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id A3646C12C9 for ; Fri, 31 Jul 2015 18:10:09 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 4.001 X-Spam-Level: **** X-Spam-Status: No, score=4.001 tagged_above=-999 required=6.31 tests=[HTML_MESSAGE=3, KAM_LAZY_DOMAIN_SECURITY=1, URIBL_BLOCKED=0.001] autolearn=disabled Received: from mx1-eu-west.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id KsMXH6_Y--KX for ; Fri, 31 Jul 2015 18:09:57 +0000 (UTC) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1-eu-west.apache.org (ASF Mail Server at mx1-eu-west.apache.org) with ESMTPS id 15EC820559 for ; Fri, 31 Jul 2015 18:09:57 +0000 (UTC) Received: by lacct8 with SMTP id ct8so15919928lac.2 for ; Fri, 31 Jul 2015 11:09:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=H6RJDEaU6jHCNFU18Y4q0AG9sKWU/Dsp7FT7hDHZN/g=; b=JPrCXfa8z8HPRehAGMgw8CXcq/weQqpn0Nr0q7zbMyagmllL0W1LXlLB8YjvOh8+Vt mnq5Rq7g3Bcp8+NAa09JsAlehqsKgMUYPY8LKvcLFnNnsz+nFMsMte7ikyKI5CI37AjC BKb8Dy9fiGOGmPbzmtkmfhqhxHY7O4nCVfKqgQ8xlAXJNWWAG5iSnNIMtgwe4JnsJgJA bKStvonwWjt3Yn1wu3SHvDAmnR3JFmdCriTVfh0qSGv8JzM+HYy9os6VpL38bMewsoCX ljNPIJkjxXf5x0jxfJb7o5uV14LxWsKv/gP6vkxc5tVmWKADpQxZyXOhznsd5805m7AA rpNw== X-Gm-Message-State: ALoCoQlJz7KEL3mY3dXksCD2EgumC2QIi93oH7Vdk1+P1a50K+zsdRsn4YT58gfajuktDtpA7EPL X-Received: by 10.112.85.3 with SMTP id d3mr4367127lbz.33.1438366189211; Fri, 31 Jul 2015 11:09:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.17.92 with HTTP; Fri, 31 Jul 2015 11:09:29 -0700 (PDT) In-Reply-To: References: <06B504B8-C724-461F-B97F-00A951DC789D@jpl.nasa.gov> From: Tom Barber Date: Fri, 31 Jul 2015 19:09:29 +0100 Message-ID: Subject: Re: Osgi stuff To: "dev@oodt.apache.org" Content-Type: multipart/alternative; boundary=001a1134946cc3ec7e051c2fb93c --001a1134946cc3ec7e051c2fb93c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 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 >> Office: 818-354-1015 >> Cell: 818-395-8194 >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> On Jul 23, 2015, at 11:23 AM, Chris Mattmann > mattmann@apache.org>> >> wrote: >> >> Totally agree! >> >> JIRA issue time and if no one gets to it, maybe GSoC or student >> project? >> >> =E2=80=94 >> Chris Mattmann >> chris.mattmann@gmail.com >> >> >> >> >> >> >> -----Original Message----- >> From: Tom Barber >> Reply-To: >> Date: Thursday, July 23, 2015 at 11:21 AM >> To: >> 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 usefu= l. >> On 23 Jul 2015 19:08, "chrismattmann" 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. >> --- >> >> >> >> >> --001a1134946cc3ec7e051c2fb93c--