Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 37809 invoked from network); 4 Dec 2009 16:40:56 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 4 Dec 2009 16:40:56 -0000 Received: (qmail 62814 invoked by uid 500); 4 Dec 2009 16:40:56 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 62738 invoked by uid 500); 4 Dec 2009 16:40:55 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 62730 invoked by uid 99); 4 Dec 2009 16:40:55 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Dec 2009 16:40:55 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of jaydmchugh@gmail.com designates 209.85.211.177 as permitted sender) Received: from [209.85.211.177] (HELO mail-yw0-f177.google.com) (209.85.211.177) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Dec 2009 16:40:47 +0000 Received: by ywh7 with SMTP id 7so2657204ywh.24 for ; Fri, 04 Dec 2009 08:40:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=X+KyjwXva6tnIjymbDShtwFv9MKoguvoN6SXiUHdZms=; b=mmiWtr0qB0MXFhjb9KcU2sK+L882QCdMI7tAe3mBE/vMHMOO7z5VzH5wXId8YEijDV XkvR/f+pf7T2MihfMfpkCYkEixhFi12UQytndonW2e9+a1XD/ixhx/BiTXWO45DO4nim h9I5a7bBJNnHhw+BkPC4zzIZ6AWDavOZP/TBo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=OUOlufi8500Pka8ufNwdWIbhUu1jWWc0vL8Cq1pQYLLG526V2aqN4VzZUSOCU5ceaX A+JTgB2DZtMyC/SiKf2YUVyYiYCzths8f8SynJdkqxJZFLtB/13JTf4/BNg3A+prlLb5 lbGE5ZM/TQw7qCoiDbDN7Vm3jzIoGPoRjBoYc= MIME-Version: 1.0 Received: by 10.150.110.23 with SMTP id i23mr5702244ybc.345.1259944826144; Fri, 04 Dec 2009 08:40:26 -0800 (PST) In-Reply-To: References: <1F4691EE-C0CD-452E-A5A7-FD3DBF06FB83@yahoo.com> Date: Fri, 4 Dec 2009 10:40:26 -0600 Message-ID: <1f6aacb70912040840y320e8e98rf3fe0c048dffd09e@mail.gmail.com> Subject: Re: Fun with ears and osgi From: Jay McHugh To: dev@geronimo.apache.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org Hello all, This gets into a question that I have had about the OSGi-ification goal of the server. That is, how much are we trying to keep the internal architecture of Geronimo hidden? Are we looking to have a server that is able to install any old Java EE apps and resources (that just happens to be OSGi on the inside)? Or, are we trying to build a server environment where everyone 'knows' that it is OSGi and (if possible) builds their applications taking that into account? It seems like the direction we are going is the latter. Am I seeing things correctly? Jay On Fri, Dec 4, 2009 at 9:25 AM, Lin Sun wrote: > Hi, > > I wonder if ear should continue working as what what they were working > before and would not be installed as bundles in OSGi framework. =C2=A0And > if users want to leverage OSGi functions in ear, they would have to > migrate their ear file to an Aries Application > (http://incubator.apache.org/aries/applications.html). > > Lin > > On Thu, Dec 3, 2009 at 8:26 PM, David Jencks wro= te: >> Working on the admin console I've run into the problem that ears most >> naturally translate into more than one osgi bundle -- at least one bundl= e >> for each web module, maybe one per module. >> >> Right now the deployment system is putting the wars inside the car file, >> just like in 2.2, but as bundles. =C2=A0It looks like we are generating = sort of >> reasonable metadata for the embedded bundles but there is certainly no w= ay >> to access them. >> >> I can think of several approaches here: >> >> 1. For now at least, just have one bundle per ear. =C2=A0This is probabl= y just a >> couple lines to change and should work for all reasonable apps. >> >> 2. modify the pax mvn url handler so it can deal with bundles hidden ins= ide >> bundles. =C2=A0This has the advantage that an ear is still a single arti= fact but >> is otherwise slightly weird. >> >> 3. modify geronimo to package the wars as entirely separate bundles from= the >> main ear. =C2=A0Maybe we can use the war module name as the classifier. >> >> In the interests of getting something working quickly I will probably tr= y >> (1) first. =C2=A0I'm intrigued by (2) but would certainly appreciate som= e >> discussion before I spend much time on either (2) or (3)..... and maybe >> someone has an even better idea. >> >> I assume there is a similar problem for app clients.... >> >> thanks >> david jencks >> >> >