Return-Path: 
 <dev-return-79103-apmail-geronimo-dev-archive=geronimo.apache.org@geronimo.apache.org>
Delivered-To: apmail-geronimo-dev-archive@www.apache.org
Received: (qmail 91694 invoked from network); 4 Jan 2010 06:19:42 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3)
  by minotaur.apache.org with SMTP; 4 Jan 2010 06:19:42 -0000
Received: (qmail 37125 invoked by uid 500); 4 Jan 2010 06:19:41 -0000
Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org
Received: (qmail 37027 invoked by uid 500); 4 Jan 2010 06:19:41 -0000
Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@geronimo.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@geronimo.apache.org>
List-Post: <mailto:dev@geronimo.apache.org>
Reply-To: dev@geronimo.apache.org
List-Id: <dev.geronimo.apache.org>
Delivered-To: mailing list dev@geronimo.apache.org
Received: (qmail 37019 invoked by uid 99); 4 Jan 2010 06:19:41 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Jan 2010 06:19:41 +0000
X-ASF-Spam-Status: No, hits=2.2 required=10.0
	tests=HTML_MESSAGE,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of xhhsld@gmail.com designates
 209.85.221.201 as permitted sender)
Received: from [209.85.221.201] (HELO mail-qy0-f201.google.com)
 (209.85.221.201)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Jan 2010 06:19:34 +0000
Received: by qyk39 with SMTP id 39so7308681qyk.27
        for <dev@geronimo.apache.org>; Sun, 03 Jan 2010 22:19:13 -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;
        bh=QcoEP0GZMSvAX+ru9zc5FwrXxGksRErS2mM390YvYlY=;
        b=UAkhxkpHog7T3WqjaPInkwIYhddbn8Iw3wAOFSyKGAaCWAwDYSSMruHPCcdaT5RMU/
         S5sT5qO2iRF0dTBniSKe8EHpe3aCCobmrL06fbvHLmlkFnyxz7NHaEpPTeHfzp2FbVtv
         sxeMFOKtEwlRLPLdTa5r5mDdf6yLDh2cGk2HY=
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;
        b=UwKnXAFwbJuhVSSz2hxMEZ63Jfosu8KNp/4ZEi5LJDrw7wid+62jNiqXxHWEGnhKi+
         U6HnWcbGlrVDHkRTHZ7YKF5B31Swrwn9nNgEB4IrUxhhNgF/KADYoM2J4MWQj36FjDSP
         Jw+NYR0IpSu1iFo6JED8GHRJQ1Jm8x4oPdtjQ=
MIME-Version: 1.0
Received: by 10.229.15.203 with SMTP id l11mr9502935qca.43.1262585953787;
 Sun,
	03 Jan 2010 22:19:13 -0800 (PST)
In-Reply-To: <2B5C967A-8D33-46D2-A556-E955B0DF1434@yahoo.com>
References: <45f744e40912280651p3898657i1a980ef996db5a1e@mail.gmail.com>
	 <AEBF5408-258D-4D7F-AF00-EEBB1C950074@yahoo.com>
	 <45f744e40912281829o64d7ae30g6e007e36291a3261@mail.gmail.com>
	 <45f744e40912310033o7d1ef43au151cb3e8d183973a@mail.gmail.com>
	 <9990A76C-D2B4-41D4-B6DA-10C0D0A272C0@yahoo.com>
	 <45f744e40912310610m675d251cta9647ae1b7304193@mail.gmail.com>
	 <45f744e41001031753i28127ef6k3212542bb129a9d0@mail.gmail.com>
	 <2B5C967A-8D33-46D2-A556-E955B0DF1434@yahoo.com>
Date: Mon, 4 Jan 2010 14:19:13 +0800
Message-ID: <45f744e41001032219x235a67c3ge589ea95e9c6bb6a@mail.gmail.com>
Subject: Re: About deploying web applications to Tomcat 7.0
From: Ivan <xhhsld@gmail.com>
To: dev@geronimo.apache.org
Content-Type: multipart/alternative; boundary=0015175ce0944621e3047c50b3d4

--0015175ce0944621e3047c50b3d4
Content-Type: text/plain; charset=ISO-8859-1

Yes, I am also sure that it should be easy to make the mvn protocol handler
to support the nested bundle function.  The reason for saying "not a
standard bundle" is for the no-copying OSGI bundle deployment, I guess that
it might be more difficult if the source file is a nested bundle file.
However, it is just a guess ;-)

2010/1/4 David Jencks <david_jencks@yahoo.com>

>
> On Jan 3, 2010, at 5:53 PM, Ivan wrote:
> <snip>
>
>  I will try the solution about dividing the ear as multiple bundles, the
>>> ear itself is one, all the modules it contains are the others, and it is
>>> possible to use require-bundle to connect the module bundle to the ear
>>> bundle.
>>>
>>
>> I'd prefer to avoid require-bundle.  I was thinking of modifying the pax
>> url handler so that we could continue to repackage the ear as we do now, but
>> have the car file contain several bundles corresponding to the different
>> modules inside.  We could perhaps imitate jar urls and append !<moduleName>
>> to point to an "internal" bundle.  If we did this the car would still be a
>> single artifact in maven but would supply all the bundles at once.
>>
>>    Yes, require-bundle did not have a good reputation in the OSGI world,
>> but in this scenario, I think we could use it to reduce the complexity.
>>    Keeping the same package way is a good choice, for currently, the
>> repository directory is a really 'repository', Geronimo never loads any
>> class from it, ^_^.  But if in that way, the file is not a standard bundle,
>> and it only works for the special url handler.
>>
>
> Well, after the bundle gets extracted by the url handler it's a plain
> ordinary bundle.  The car-with bundles-inside is really just a delivery
> mechanism.  I'm pretty sure it would be easy to implement, but might not be
> a great idea long term.  It might be convenient until we find something
> better.  On the other hand it might get popular in other contexts.
>
> I forgot to mention that the other approach that seems promising to me is
> to use the application bundle idea from the aries project.
>
> thanks
> david jencks
>
>
>>  One thing I am thinking is that how to generate the exports for the ear
>>> bundle, maybe the deployer might need use something like asm to scan all the
>>> library files.
>>>
>>
>> I think we should look into using BND for this.
>>
>>    Yes, BND should help us.
>>
>> thanks
>> david jencks
>>
> <snip>
>



-- 
Ivan

--0015175ce0944621e3047c50b3d4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Yes, I am also sure that it should be easy to make the mvn protocol handler=
 to support the nested bundle function.=A0 The reason for saying &quot;not =
a standard bundle&quot; is for the no-copying OSGI bundle deployment, I gue=
ss that it might be more difficult if the source file is a nested bundle fi=
le. However, it is just a guess ;-)<br>
<br><div class=3D"gmail_quote">2010/1/4 David Jencks <span dir=3D"ltr">&lt;=
<a href=3D"mailto:david_jencks@yahoo.com">david_jencks@yahoo.com</a>&gt;</s=
pan><br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid r=
gb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
On Jan 3, 2010, at 5:53 PM, Ivan wrote:<br>
&lt;snip&gt;<div class=3D"im"><br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><blockquote class=
=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 204, 204); margin=
: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

I will try the solution about dividing the ear as multiple bundles, the ear=
 itself is one, all the modules it contains are the others, and it is possi=
ble to use require-bundle to connect the module bundle to the ear bundle.<b=
r>

</blockquote>
<br>
I&#39;d prefer to avoid require-bundle. =A0I was thinking of modifying the =
pax url handler so that we could continue to repackage the ear as we do now=
, but have the car file contain several bundles corresponding to the differ=
ent modules inside. =A0We could perhaps imitate jar urls and append !&lt;mo=
duleName&gt; to point to an &quot;internal&quot; bundle. =A0If we did this =
the car would still be a single artifact in maven but would supply all the =
bundles at once.<br>

<br>
 =A0 =A0Yes, require-bundle did not have a good reputation in the OSGI worl=
d, but in this scenario, I think we could use it to reduce the complexity.<=
br>
 =A0 =A0Keeping the same package way is a good choice, for currently, the r=
epository directory is a really &#39;repository&#39;, Geronimo never loads =
any class from it, ^_^. =A0But if in that way, the file is not a standard b=
undle, and it only works for the special url handler.<br>

</blockquote>
<br></div>
Well, after the bundle gets extracted by the url handler it&#39;s a plain o=
rdinary bundle. =A0The car-with bundles-inside is really just a delivery me=
chanism. =A0I&#39;m pretty sure it would be easy to implement, but might no=
t be a great idea long term. =A0It might be convenient until we find someth=
ing better. =A0On the other hand it might get popular in other contexts.<br=
>

<br>
I forgot to mention that the other approach that seems promising to me is t=
o use the application bundle idea from the aries project.<br>
<br>
thanks<br>
david jencks<div class=3D"im"><br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
One thing I am thinking is that how to generate the exports for the ear bun=
dle, maybe the deployer might need use something like asm to scan all the l=
ibrary files.<br>
</blockquote>
<br>
I think we should look into using BND for this.<br>
<br>
 =A0 =A0Yes, BND should help us.<br>
<br>
thanks<br>
david jencks<br>
</blockquote></div>
&lt;snip&gt;<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br>Ivan<br>

--0015175ce0944621e3047c50b3d4--