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
<[email protected]> wrote:
On Fri, Oct 2, 2009 at 6:28 PM, Guillaume Nodet <[email protected]> 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
<[email protected]> 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 <[email protected]>
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
