From user-return-15823-apmail-geronimo-user-archive=geronimo.apache.org@geronimo.apache.org Tue Nov 8 03:05:32 2011 Return-Path: X-Original-To: apmail-geronimo-user-archive@www.apache.org Delivered-To: apmail-geronimo-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E44379B78 for ; Tue, 8 Nov 2011 03:05:32 +0000 (UTC) Received: (qmail 89225 invoked by uid 500); 8 Nov 2011 03:05:32 -0000 Delivered-To: apmail-geronimo-user-archive@geronimo.apache.org Received: (qmail 89196 invoked by uid 500); 8 Nov 2011 03:05:31 -0000 Mailing-List: contact user-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: user@geronimo.apache.org List-Id: Delivered-To: mailing list user@geronimo.apache.org Received: (qmail 89183 invoked by uid 99); 8 Nov 2011 03:05:28 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 08 Nov 2011 03:05:28 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of xhhsld@gmail.com designates 74.125.82.50 as permitted sender) Received: from [74.125.82.50] (HELO mail-ww0-f50.google.com) (74.125.82.50) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 08 Nov 2011 03:05:19 +0000 Received: by wwp14 with SMTP id 14so51519wwp.31 for ; Mon, 07 Nov 2011 19:04:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=ThXtAqgwUqoCzHHZBGbKIgB9fYl2ippoYT5gMjwJxcE=; b=DOHKaF1mUeM0xuP1WfYNm8SwfywIqj4Viik1TKNQ5W9+aNqZtfAnF/XCjOQNkq5/p9 KKtGX+mgTR7VHG3NayQHGtGSAe81J7OqDT42rqfB33bAExltCBAcRq5LAb0ZF9L/XqWj 4rCdbyW5XL1GYZCWTjAb1+iaPLWuKV3uVoWWQ= MIME-Version: 1.0 Received: by 10.216.230.21 with SMTP id i21mr4042428weq.23.1320721499434; Mon, 07 Nov 2011 19:04:59 -0800 (PST) Received: by 10.216.88.82 with HTTP; Mon, 7 Nov 2011 19:04:59 -0800 (PST) In-Reply-To: <006C5FA1-5FEF-4A3F-835E-ADA087E0D848@yahoo.com> References: <4EB437D5.2030303@sendmail.cz> <4EC0382F-AF78-4B3D-9AF1-99DBC9D13F17@gmail.com> <006C5FA1-5FEF-4A3F-835E-ADA087E0D848@yahoo.com> Date: Tue, 8 Nov 2011 11:04:59 +0800 Message-ID: Subject: Re: classloading in 3.0 From: Ivan To: user@geronimo.apache.org Content-Type: multipart/alternative; boundary=0016e64716f4d22f5104b1306f52 X-Virus-Checked: Checked by ClamAV on apache.org --0016e64716f4d22f5104b1306f52 Content-Type: text/plain; charset=ISO-8859-1 Agree, but as we discussed in the past, we need to validate each component one by one, to make the context classloader and resource searching work. 2011/11/8 David Jencks > > On Nov 7, 2011, at 5:03 AM, Kevan Miller wrote: > > > > > On Nov 4, 2011, at 3:42 PM, David Jencks wrote: > > > >> > >> On Nov 4, 2011, at 12:07 PM, Radim Kolar wrote: > >> > >>> I propose to make classloading in 3.0 entirely different. Give user > aplication access to javax.* stuff and other required J2EE 6 apis and > nothing else unless told otherwise by deployment descriptor. > >> > >> I'd like this too. How do you propose to get this to work? I've been > working on several ideas that end up requiring major modifications to > geronimo that I haven't been able to get to work. Any ideas you might have > would be great to see. > > > > Agreed. We'd discussed this previously, IIRC. > > > >> > >> What I'd actually like to see is that, instead of arbitrarily importing > any particular set of classes, we run bnd on the application classes to > determine the Import-Packages needed. > > > > Are you saying you don't want to arbitrarily import spec api classes? Or > are you suggesting we use BND to dynamically determine Import-Packages for > non-spec classes? I assume the latter would be filtering (not importing) > packages that are already included in the application archive? > > I imagine we can figure out how to configure bnd to not generate > import-package for anything in the application. It might be a little > different from the maven-bundle-plugin since maven will be missing. > > > > > Automatically importing a default set of spec api classes would be a > good first step, IMO. And require explicit Import-Packages -- at least > initially. > > I'd like there to be no default import-packages and all imports, spec or > anything else, be determined by byte-code analysis by bnd. If you need > more (e.g. dynamic class loading) you can specify bnd instructions. I > don't think this will really work until we get everything in the server to > work as a bundle extender, but maybe I'm being too pessimistic. > > david jencks > > > > > --kevan > > -- Ivan --0016e64716f4d22f5104b1306f52 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Agree, but as we discussed in the past, we need to validate each component = one by one, to make the context classloader and resource searching work.
2011/11/8 David Jencks &l= t;david_jencks@yahoo.com><= /span>

On Nov 7, 2011, at 5:03 AM, Kevan Miller wrote:

>
> On Nov 4, 2011, at 3:42 PM, David Jencks wrote:
>
>>
>> On Nov 4, 2011, at 12:07 PM, Radim Kolar wrote:
>>
>>> I propose to make classloading in 3.0 entirely different. Give= user aplication access to javax.* stuff and other required J2EE 6 apis and= nothing else unless told otherwise by deployment descriptor.
>>
>> I'd like this too. =A0How do you propose to get this to work? = =A0I've been working on several ideas that end up requiring major modif= ications to geronimo that I haven't been able to get to work. =A0Any id= eas you might have would be great to see.
>
> Agreed. We'd discussed this previously, IIRC.
>
>>
>> What I'd actually like to see is that, instead of arbitrarily = importing any particular set of classes, we run bnd on the application clas= ses to determine the Import-Packages needed.
>
> Are you saying you don't want to arbitrarily import spec api class= es? Or are you suggesting we use BND to dynamically determine Import-Packag= es for non-spec classes? I assume the latter would be filtering (not import= ing) packages that are already included in the application archive?

I imagine we can figure out how to configure bnd to not generate impo= rt-package for anything in the application. =A0It might be a little differe= nt from the maven-bundle-plugin since maven will be missing.

>
> Automatically importing a default set of spec api classes would be a g= ood first step, IMO. And require explicit Import-Packages -- at least initi= ally.

I'd like there to be no default import-packages and all imports, = spec or anything else, be determined by byte-code analysis by bnd. =A0If yo= u need more (e.g. dynamic class loading) you can specify bnd instructions. = =A0I don't think this will really work until we get everything in the s= erver to work as a bundle extender, but maybe I'm being too pessimistic= .

david jencks

>
> --kevan




--
Ivan
--0016e64716f4d22f5104b1306f52--