aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jay D. McHugh" <>
Subject Re: Wab url handler and imports
Date Fri, 02 Oct 2009 21:34:36 GMT
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.  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)?


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:
>>>>> ------------------------
>>>>> Open Source SOA
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog:
>>> ------------------------
>>> Open Source SOA

View raw message