From dev-return-89259-apmail-geronimo-dev-archive=geronimo.apache.org@geronimo.apache.org Wed Mar 02 08:32:11 2011 Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 7544 invoked from network); 2 Mar 2011 08:32:09 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 2 Mar 2011 08:32:09 -0000 Received: (qmail 15638 invoked by uid 500); 2 Mar 2011 08:32:09 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 14933 invoked by uid 500); 2 Mar 2011 08:32:07 -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 14364 invoked by uid 99); 2 Mar 2011 08:32:07 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Mar 2011 08:32:07 +0000 X-ASF-Spam-Status: No, hits=0.0 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RFC_ABUSE_POST,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [98.136.44.56] (HELO smtp101.prem.mail.sp1.yahoo.com) (98.136.44.56) by apache.org (qpsmtpd/0.29) with SMTP; Wed, 02 Mar 2011 08:32:00 +0000 Received: (qmail 57466 invoked from network); 2 Mar 2011 08:31:40 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=DKIM-Signature:Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=YvHWUk1IGzBjDB6yXR6WknflVErtZ5ht5RMwgS6g0/DQo+W3XoRp3Tcx1AhCUJp5oTPl0mkIHk1kPQQVNsdyGqRBAbckEDSWEzwbrcGU91SR5LhZ5qoQqiEEiPV4YLHeyB3DQgcjSFeJ5JNPoqQNU5UQqmUqTSMloUwpqUf9lCI= ; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1299054699; bh=Vn1V3Tuy0CbVmWGwA9fyew7ebTluUbcV91fc1QfGYGw=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=DJKtPnuMLohDrHa3QveugGe7HKHhzV+TNPHP2hjoD0DXhbuqpAlwKhtPo3S2kTHeJAy32FG531fJDVs1xJ4Pv1ZHi4X9130Moqy6ZGwLFgmWDzzg/jImKys9Bri5VEdTvFEbKev+41pfRn0fDF+OPu2+vMHU+OfLoOcvIv3neU0= Received: from [10.0.1.147] (david_jencks@76.76.148.215 with plain) by smtp101.prem.mail.sp1.yahoo.com with SMTP; 02 Mar 2011 00:31:39 -0800 PST X-Yahoo-SMTP: .9oIUzyswBANsYgUm_5uPui0skTnzGJXJQ-- X-YMail-OSG: fZcbk1EVM1ne_gFhCGynfZZ58tbx8fzrhS17LQN6CV946VA BwyqlVZp17jVqENol1b4Z4UKzupWq3WkAy_0xxVKMRqHWGEMRzvdSK8UK9HZ 9T8HYL7EmT0EqMSX3m.kagrLOEbMQuB1sg_EzHr.vTQ8S8WrPgqfaCSI8d61 wr9fyvHQtml8pj3ZxPKt9.RdfemubzZw6ubOZgGwgeroH9gMYxwIIiSELT7B F5SfprkJ0EPBfhphnRgVFbi7P2oLNvPlKd5wf0QxvUenyTVDYbmH28WQ- X-Yahoo-Newman-Property: ymail-3 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) Subject: Re: dependencies, isolation, and features in g 3 From: David Jencks In-Reply-To: Date: Wed, 2 Mar 2011 00:31:38 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: dev@geronimo.apache.org X-Mailer: Apple Mail (2.1082) I managed to get a server to build and start without restricted gbean = visibility (A.2). I had to eliminate gbean reference validation and = change how datasources are looked up but the overall code change is = pretty small. I haven't tried running any tests to see what might be = broken. thanks david jencks On Feb 28, 2011, at 12:28 PM, David Jencks wrote: > In our migration away from gbeans in g 3 we will soon have to deal = with some incompatibilities between the gbean model and osgi. Here are = some thoughts about some aspects of this. >=20 > Currently in g 3 we may start from a maven pom in a g. plugin project, = we may get a geronimo-plugin.xml, and we certainly get a geronimo plan, = all of which have similar jar-based notions of dependency. =20 >=20 > A. In the geronimo plan, translated into a geronimo configuration: > 1. The dependencies have nothing to do with classloading. >=20 > 2. The dependencies only restrict gbean visibility for single values = gbean references. =20 > There is no equivalent in osgi. Isolation schemes based on framework = hooks can restrict service visibility but I really doubt anyone would = like an isolation environments <=3D=3D> bundle scheme which is pretty = much an equivalent of what we have now. In any case we don't have any = isolation yet. I think we should do an experiment and turn off this = restriction and see how much breaks. It may be much harder to deploy = more than one app on geronimo but we may have to live with this until we = can install isolation. If this works we may be able to just install all = gbeans as osgi services and use osgi to track them rather than the g. = kernel. If this works it should make migration away from gbeans much = easier. >=20 > 3. The dependencies serve to control startup order via our = DependencyManager. > Again the idea of the dependency manager doesn't fit in osgi. There's = a slightly bigger question of how to decide or record what is in a = server, especially after a "clean". However ignoring this larger = question perhaps we can use start level, incremented by one for each = installed plugin, to get our plugins to start in a usable order. >=20 > 4. So my suggestion is to simply remove (or possibly ignore) the = dependencies in geronimo plans. >=20 > B. One of the ideas going into the osgi subsystem spec is karaf = features and possibly kar files. I think this is a good replacement for = our idea of the plugin installer installing all the required jars and = plugins listed as plugin dependencies. At the moment a karaf feature or = kar maven project (only in karaf 3 snapshot) only creates the feature or = kar, and doesn't do anything else like our car plugin does with calling = the geronimo deployment system. So this change would require some new = maven projects to create the features. On the other hand we will need = fewer "config" projects since I anticipate most of our configs will be = replaced by DS in the "module" bundles. >=20 > C. We currently have no osgi isolation. It looks like all osgi = isolation solutions are going to be built on top of the 4.3 framework = hooks. There's an osgi subsystem spec under development and virgo has a = concept of regions. >=20 > Aries has a prototype of subsystems based on "scopes". IIUC scopes = form a tree. Scopes can import and export stuff from their container. = They have some idea of updates but I'm not sure what. I think the = various ideas of subsystems (applications like ebas, subsystems, = features) are particular kinds of scopes with conventions about what is = imported and exported. IIUC from some conversations the idea is a scope = is a "thing" that can be "deployed" "somewhere". Since scopes form a = tree, you can "cd" to an appropriate node of the tree and deploy a scope = into it. =46rom a very brief glance at the aries code it looks like = making scopes form a directed acyclic graph would be pretty easy = code-wise. This would lose the "deploy to a "single" "location"" idea = but you could still "deploy" to a set of nodes (scope parents). >=20 > I know even less about virgo regions but I think they are not = restricted to be a tree and might even not be an acyclic graph. IIUC = the idea of a region is more something you set up and then deploy = artifacts into. Aside from this I don't know how they might differ from = the multi-parent scopes I propose above. >=20 > In any case we are going to need some kind of isolation solution. If = we can turn all gbeans into osgi services as proposed in A.2. we may be = able to start experimenting with isolation before getting rid of all = gbeans. >=20 > -- > I don't have full confidence that these ideas all make sense so = comments are definitely more than welcome. >=20 > thanks > david jencks >=20