Return-Path: Delivered-To: apmail-incubator-aries-dev-archive@minotaur.apache.org Received: (qmail 54109 invoked from network); 3 Oct 2009 18:09:08 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 3 Oct 2009 18:09:08 -0000 Received: (qmail 55728 invoked by uid 500); 3 Oct 2009 18:09:03 -0000 Delivered-To: apmail-incubator-aries-dev-archive@incubator.apache.org Received: (qmail 55687 invoked by uid 500); 3 Oct 2009 18:09:03 -0000 Mailing-List: contact aries-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: aries-dev@incubator.apache.org Delivered-To: mailing list aries-dev@incubator.apache.org Received: (qmail 55623 invoked by uid 99); 3 Oct 2009 18:09:03 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 03 Oct 2009 18:09:03 +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 (nike.apache.org: domain of ianrbsn@googlemail.com designates 209.85.220.209 as permitted sender) Received: from [209.85.220.209] (HELO mail-fx0-f209.google.com) (209.85.220.209) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 03 Oct 2009 18:08:51 +0000 Received: by fxm5 with SMTP id 5so1817963fxm.27 for ; Sat, 03 Oct 2009 11:08:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type; bh=KzLsmFASUWHTgivLKsRfEZVSAT1H+qn5KwoVsjTNZPk=; b=wGyse/njVvI6nGVom2oSJzMrvwgexsZbq8AO5AhG0deGRwcmpQZ/BqI2TegN/0PJIn o0GlY3KjosyW9snsOMfOZK9LBfg9JiYWzRB7oZdx3aaelEgS8A3JajRgt7NBfOzw+3lx uetfYFNaT/GAjPFRJSSutE/74ydi288AAKUmE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; b=kr7iGr9ZwPSKzpj22V9lkgicv4IzC4FtsbUIlWLru1RVRxBnZW2a7HxNColwyz+DCo ybO8cDPRpIxaGaDRJl2E9M+Mz+Yc1v2Ph1w7N4r8XRCafHzH9Rt10shevLOZQcjy4uVX 2fKab8hl+xGeKT9cLEaZo5abkVONmOqkbBD+w= Received: by 10.86.225.38 with SMTP id x38mr3565788fgg.59.1254593309773; Sat, 03 Oct 2009 11:08:29 -0700 (PDT) Received: from ?192.168.0.2? (93-97-38-188.zone5.bethere.co.uk [93.97.38.188]) by mx.google.com with ESMTPS id l12sm2500110fgb.5.2009.10.03.11.08.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 03 Oct 2009 11:08:28 -0700 (PDT) Message-ID: <4AC79325.2000402@googlemail.com> Date: Sat, 03 Oct 2009 19:08:37 +0100 From: Ian Robinson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: aries-dev@incubator.apache.org Subject: Re: Wab url handler and imports References: <4AC671EC.8090603@gmail.com> In-Reply-To: <4AC671EC.8090603@gmail.com> Content-Type: multipart/mixed; boundary="------------010302090606080601080203" X-Virus-Checked: Checked by ClamAV on apache.org --------------010302090606080601080203 Content-Type: multipart/alternative; boundary="------------010007050203000405060605" --------------010007050203000405060605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit If the aplication starting point is a vanilla war that runs in Java EE in a non-OSGi context then that war would need to have been correctly packaged with all its dependencies in order to run in that environment. When converting such a war to a web application bundle we should probably assume - as a starting point - that we don't need even optional imports for the packages referenced by the embedded libraries as putting these in the manifest will likely result in over-provisioning. - Ian Jay D. McHugh wrote: > This may be premature - but... > > I am looking ahead to when Aries is in use by an app server to provide > the required plumbing. And, in a case like that, a WAR file may > (probably will) be deployed that expects to have the EE framework (mail, > JNDI, EJB, etc) available. This is my expectation, although we'll surely see web and other profiles that don't include everything. > So, there will be WAR files that just have > deployment descriptors that specify what the dependencies are. > Or, would we expect that there will be some other part of the EE > framework that will have to provide backward compatibility (mapping the > deployment descriptor onto a OSGi manifest)? > > Jay > > > Guillaume Nodet wrote: > >> I would think we should trust the user and expect it to have packaged >> his war correctly, i.e. with all the mandatory dependencies. >> Any other option would force the user to write the full manifest, thus >> removing the need for the war url handler ;-) >> >> On Fri, Oct 2, 2009 at 19:44, Valentin Mahrwald >> wrote: >> >>> On Fri, Oct 2, 2009 at 6:28 PM, Guillaume Nodet wrote: >>> >>> >>>> What about setting up the import package so that all the imports are >>>> optional ? >>>> This would at least make sure that wars that have no external >>>> dependencies could deploy without any problems. >>>> >>>> >>> I suppose that is fine if the major use case deploying self-contained war >>> files. Otherwise, I would be afraid of unpredictable ClassNotFoundExceptions >>> occurring at runtime, which I guess the aim would be to avoid as far as >>> possible. >>> >>> However, I can see a point for generating all-optional imports for embedded >>> libraries without manifest since there isn't much else we can do other than >>> force the user to specify dependencies explicitly, which seems a bit >>> awkward. >>> >>> This seems to be a question of whether we would rather stop a legacy war >>> from deploying if we are unsure whether it will work at runtime / which >>> extra dependencies need to be supplied >>> or deploy anyway and let the user deal with any problem if/when they occur. >>> >>> >>> >>>> On Fri, Oct 2, 2009 at 19:23, Valentin Mahrwald >>>> wrote: >>>> >>>>> You are right embedded libraries are indeed a major problem with the code >>>>> >>>> as >>>> >>>>> it stands and has been discussed (but, alas, not resolved) IBM >>>>> >>>> internally. >>>> >>>>> As far as I am aware there is no prescribed solution for this in RFC 66, >>>>> >>>> so >>>> >>>>> we are free to devise the mechanism that seems best. >>>>> >>>>> Possibly, the best mechanism would be to require embedded libraries to >>>>> either >>>>> - specify a valid OSGi manifest from which we could determine what >>>>> dependency the library adds and which it resolves >>>>> or >>>>> - have no external dependencies (which is of course very hard to check at >>>>> runtime since we cannot know for any given libraries whether dependencies >>>>> are optional or not). >>>>> >>>>> This would I hope cover the majority of utility libraries one would want >>>>> >>>> to >>>> >>>>> include in a WAB. >>>>> >>>>> >>>>> On Fri, Oct 2, 2009 at 1:24 PM, Guillaume Nodet >>>>> >>>> wrote: >>>> >>>>>> Just having a quick look at the contributed wab/war url handler, it >>>>>> seems that the strategy is to analyze all the classes and import all >>>>>> the packages that are used minus those that are provided by the web >>>>>> archive. >>>>>> I may have missed something, but I doubt this really work, because any >>>>>> library included in the war will need *all* the referenced packages to >>>>>> be solved. But lots of those packages may be optional. How would >>>>>> that work ? >>>>>> >>>>>> -- >>>>>> Cheers, >>>>>> Guillaume Nodet >>>>>> ------------------------ >>>>>> Blog: http://gnodet.blogspot.com/ >>>>>> ------------------------ >>>>>> Open Source SOA >>>>>> http://fusesource.com >>>>>> >>>>>> >>>> -- >>>> Cheers, >>>> Guillaume Nodet >>>> ------------------------ >>>> Blog: http://gnodet.blogspot.com/ >>>> ------------------------ >>>> Open Source SOA >>>> http://fusesource.com >>>> >>>> >> >> > > --------------010007050203000405060605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit If the aplication starting point is a vanilla war that runs in Java EE in a non-OSGi context then that war would need to have been correctly packaged with all its dependencies in order to run in that environment. When converting such a war to a web application bundle we should probably assume - as a starting point - that we don't need even optional imports for the packages referenced by the embedded libraries as putting these in the manifest will likely result in over-provisioning.

- Ian

Jay D. McHugh wrote: 
This may be premature - but...

I am looking ahead to when Aries is in use by an app server to provide
the required plumbing.  And, in a case like that, a WAR file may
(probably will) be deployed that expects to have the EE framework (mail,
JNDI, EJB, etc) available.
This is my expectation, although we'll surely see web and other profiles that don't include everything. 

So, there will be WAR files that just have
deployment descriptors that specify what the dependencies are.
Or, would we expect that there will be some other part of the EE
framework that will have to provide backward compatibility (mapping the
deployment descriptor onto a OSGi manifest)?

Jay

  
Guillaume Nodet wrote:
  
I would think we should trust the user and expect it to have packaged
his war correctly, i.e. with all the mandatory dependencies.
Any other option would force the user to write the full manifest, thus
removing the need for the war url handler ;-)

On Fri, Oct 2, 2009 at 19:44, Valentin Mahrwald
<vmahrwald@googlemail.com> wrote:
    
On Fri, Oct 2, 2009 at 6:28 PM, Guillaume Nodet <gnodet@gmail.com> wrote:

      
What about setting up the import package so that all the imports are
optional ?
This would at least make sure that wars that have no external
dependencies could deploy without any problems.

        
I suppose that is fine if the major use case deploying self-contained war
files. Otherwise, I would be afraid of unpredictable ClassNotFoundExceptions
occurring at runtime, which I guess the aim would be to avoid as far as
possible.

However, I can see a point for generating all-optional imports for embedded
libraries without manifest since there isn't much else we can do other than
force the user to specify dependencies explicitly, which seems a bit
awkward.

This seems to be a question of whether we would rather stop a legacy war
from deploying if we are unsure whether it will work at runtime / which
extra dependencies need to be supplied
or deploy anyway and let the user deal with any problem if/when they occur.


      
On Fri, Oct 2, 2009 at 19:23, Valentin Mahrwald
<vmahrwald@googlemail.com> wrote:
        
You are right embedded libraries are indeed a major problem with the code
          
as
        
it stands and has been discussed (but, alas, not resolved) IBM
          
internally.
        
As far as I am aware there is no prescribed solution for this in RFC 66,
          
so
        
we are free to devise the mechanism that seems best.

Possibly, the best mechanism would be to require embedded libraries to
either
- specify a valid OSGi manifest from which we could determine what
dependency the library adds and which it resolves
or
- have no external dependencies (which is of course very hard to check at
runtime since we cannot know for any given libraries whether dependencies
are optional or not).

This would I hope cover the majority of utility libraries one would want
          
to
        
include in a WAB.


On Fri, Oct 2, 2009 at 1:24 PM, Guillaume Nodet <gnodet@gmail.com>
          
wrote:
        
Just having a quick look at the contributed wab/war url handler, it
seems that the strategy is to analyze all the classes and import all
the packages that are used minus those that are provided by the web
archive.
I may have missed something, but I doubt this really work, because any
library included in the war will need *all* the referenced packages to
be solved.  But lots of those packages may be optional.  How would
that work ?

--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

            
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
--------------010007050203000405060605-- --------------010302090606080601080203--