From dev-return-62342-apmail-geronimo-dev-archive=geronimo.apache.org@geronimo.apache.org Thu Apr 17 14:41:37 2008 Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 97349 invoked from network); 17 Apr 2008 14:41:36 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 17 Apr 2008 14:41:36 -0000 Received: (qmail 13682 invoked by uid 500); 17 Apr 2008 14:41:35 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 13630 invoked by uid 500); 17 Apr 2008 14:41:34 -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 13619 invoked by uid 99); 17 Apr 2008 14:41:34 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 17 Apr 2008 07:41:34 -0700 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: local policy) Received: from [72.10.46.63] (HELO as.toolazydogs.com) (72.10.46.63) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 17 Apr 2008 14:40:42 +0000 Received: (qmail 9952 invoked from network); 17 Apr 2008 07:41:00 -0700 Received: from c-71-202-181-13.hsd1.ca.comcast.net (HELO ?192.168.1.101?) (71.202.181.13) by toolazydogs.com with (AES128-SHA encrypted) SMTP; 17 Apr 2008 07:41:00 -0700 Message-Id: <77A0A35D-BBC5-4423-81A1-76AE750AEA45@toolazydogs.com> From: "Alan D. Cabrera" To: dev@geronimo.apache.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: Geronimo specs jars in OSGi Date: Thu, 17 Apr 2008 07:40:59 -0700 References: <1b5bfeb50804170427i563f20c0nc8d1b6aea7523d66@mail.gmail.com> X-Mailer: Apple Mail (2.919.2) X-Virus-Checked: Checked by ClamAV on apache.org IIUC, they're not entirely legacy, i.e. you at least put in the OSGi manifest entries. You do so using the maven/BND plugin I suspect. This strikes me as a common service discovery pattern. Off the top of my head I would think that a plugin that adds the necessary BundleActivator for legacy modules would be useful. Another thought that flashed in my head is that in a buttoned down environment getting service notifications might be easier than getting access to every Bundle's class loader. Regards, Alan On Apr 17, 2008, at 7:30 AM, Guillaume Nodet wrote: > Cleaner, but the main problem is that it does not work with legacy > code. > Will you rewrite the jaxb2 implementation to do that instead of > using the stax > factory ? ;-) > We've got tons of legacy stuff that use stax, or jaxb2 and i don't > see rewriting > the whole lot as realistic. it would also mean having an OSGi > specific thing > everywhere we use a factory from a j2ee spec :-( > > On Thu, Apr 17, 2008 at 4:24 PM, Alan D. Cabrera > wrote: >> >> >> On Apr 17, 2008, at 6:54 AM, Guillaume Nodet wrote: >> >> >>> On Thu, Apr 17, 2008 at 1:27 PM, Jacek Laskowski >> > >> wrote: >>> >>>> On Wed, Apr 16, 2008 at 5:20 PM, Guillaume Nodet >> wrote: >>>> >>>> >>>>> However, lots of these spec jars define factories (stax, saaj for >> example) >>>>> that use the META-INF/services/ discovery mechanism to find an >>>>> implementation of the spec and load it. This mechanism does not >>>>> fit >> well in >>>>> OSGi (really, it does not), mainly because usually, the >>>>> classloader >>>>> containing the spec jar will not contain the implementation. >>>>> I'd like to work on these spec jars so that they will contain an >>>>> OSGi >>>>> BundleActivator that would change the behavior of these >>>>> factories when >>>>> deployed in an OSGi environment (without changing the behavior in >> other >>>>> case). The idea is that the activator would scan OSGi bundles >>>>> when >> they are >>>>> started to find META-INF/services and populate a map that would be >> used by >>>>> the factory when creating an object before using the standard >> mechanism. >>>>> >>>> >>>> Just to ensure I'm following, you are about to create a activator >>>> that >>>> would be a bundle listener (o.o.f.BundleListener) and whenever a >>>> bundle is registered the activator will scan it for provided >>>> services? >>>> Can you explain how osgi works now without these >>>> META-INF/services-based services? Doesn't it use them at all? >>>> >>> >>> This is the tricky part. The work we've done on the specs so far >>> means that each spec >>> is an OSGi bundle. In OSGi, each bundle has each own classloader >>> and >>> classloaders >>> are not organized in a simple tree: if bundle A requires bundle B >>> and >>> bundle B requires >>> bundle C, it does not mean that C will be accessible to A. >>> Following so >> far ? >>> So, let's say I create a bundle that references the Stax Api. >>> My bundle will have the geronimo stax api in its classpath. The >>> stax >>> implementation that >>> I deploy will also have the stax api in its classpath, but it >>> won't be >>> available to either >>> the the stax api or my bundle. >>> The problem happens when the stax api needs to find and create the >>> implementation. >>> Usually, the existing code won't be able to do that at all, because >>> the META-INF/services >>> and the implementation class are not available from the stax api >> classloader. >>> One way to work around that is (if the api uses the thread context >>> classloader) to make sure >>> my bundle includes the implementation in its classloader and make >>> sure >>> the thread context >>> classloader is correctly set. This usually involves copying the >>> META-INF/services/xx stuff >>> in our bundle and explicitely referencing the implementation to make >>> sure the classloader >>> includes it. >>> >>> The problem is that it's a bit annoying to do that on all the >>> bundles >>> and it does prevent >>> swicthing implementations. >>> >>> So now, there is no need to reference the implementation from the >>> bundle. The spec jar bundle >>> activator will use OSGi to find the META-INF/services/ entries each >>> time a bundle is installed >>> and if an implementation is used, will load the class through OSGi >>> API, using the implementation >>> bundle classloader instead of the spec jar classloader. >>> >> >> I think, just my personal opinion, that scouring bundles' META-INF/ >> services >> entries is kinda klunky. Could we not use a service/whiteboard >> approach >> that is common in OSGi? When in Rome, do as the Romans do. >> >> Let's assume that we go with the virgin spec jar wrapped in a bundle >> paradigm I spoke of in a previous post. Here the bundles that use >> the stax >> api would register stax api service implementations. The stax api >> would >> catch those service registrations and properly configure the >> factory. A >> bit cleaner imo and you don't have to search every bundle. >> >> >> Regards, >> Alan >> >> > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ >