Rajini Sivaram wrote:
On 2/22/08, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Jean-Sebastien Delfino wrote:
Great to see a *test* case for cycles, but my question was: Do you
have a *use* case for cycles and partial packages right now or can
it >> be fixed later?
Rajini Sivaram wrote:
No, I dont have an use-case, at least not an SCA one. But there are
plenty
of them in OSGi - eg. Tuscany modules cannot run in OSGi without
support
for
split-packages. Of course you can fix it later.
I'm not arguing for or against fixing it now or later, I'm trying to
get
the real use case to make a decision based on concrete grounds. Can you
point me to your OSGi use cases, or help me understand "Tuscany modules
cannot run in OSGi without support for split packages"?
Tuscany node and domain code are split into three modules each for API,
SPI
and Implementation eg. tuscany-node-api, tuscany-node and
tuscany-node-impl.
The API module defines a set of classes in org.apache.tuscany.sca.nodeand
the SPI module extends this package with more classes. So the package
org.apache.tuscany.sca.node is split across tuscany-node-api and
tuscany-node. If we used maven-bundle-plugin to generate OSGi manifest
entries for Tuscany modules, we would get three OSGi bundles
corresponding
to the node modules. And the API and SPI bundles have to specify that
they
use split-packages. It would obviously have been better if API and SPI
used
different packages, but the point I am trying to make is that splitting
packages across modules is not as crazy as it sounds, and split packages
do
appear in code written by experienced programmers.
IMO, supporting overlapping package import/exports is more important
with
SCA contributions than with OSGi bundles since SCA contributions can
specify
wildcards in import.java/export.java. eg. If you look at packaging
tuscany-contribution and tuscany-contribution-impl where
tuscany-contribution-impl depends on tuscany-contribution, there is no
clear
naming convention to separate the two modules using a single
import/export
statement pair. So if I could use wildcards, the simplest option that
would
avoid separate import/export statements for each subpackage (as required
in
OSGi) would be to export org.apache.tuscany.sca.contribution* from
tuscany-contribution and import org.apache.tuscany.sca.contribution* in
tuscany-contribution-impl. The sub-packages themselves are not shared
but
the import/export namespaces are. We need to avoid cycles in these
cases.
Again, there is a way to avoid sharing package spaces, but it is simpler
to
share, and there is nothing in the SCA spec which stops you sharing
packages
across contributions.
I dont think the current model resolver code which recursively searches
exporting contributions for artifacts is correct anyway - even for
artifacts
other than classes. IMO, when an exporting contribution is searched for
an
artifact, it should only search the exporting contribution itself, not
its
imports. And that would avoid cycles in classloading. I would still
prefer
not to intertwine classloading and model resolution because that would
unnecessarily make classloading stack traces which are complex anyway,
even
more complex that it needs to be. But at least if it works all the time,
rather than run into stack overflows, I might not have to look at those
stack traces....
and this will convince me to help fix it now :) Thanks.
It is not broken now - you have to break it first and then fix it :-).
I have reviewed the model resolution and classloading code and found the
following:
- Split namespaces are currently supported (for example by the WSDL and
XSD resolvers). The model resolver mechanism does not have an issue with
split namespaces.
- The Java import/export resolvers do not seem to support split packages
(if I understood that code which was quite tricky), but that's an issue
in that Java import/export specific code, which just needs to be fixed.
I'll work on it.
- The interactions between the Java import/export listener, the model
resolvers and the ContributionClassLoader are way too complicated IMHO.
That complexity is mostly caused by ContributionClassLoader, I'll try to
show a simpler implementation in a few days.
- Dependency cycles are an exception in Java as build tools like Maven
don't support them, but can exist in XSD for example. Supporting cycles
just requires a simple fix to the import model resolvers, I'll help fix
that too.
Hope this helps.
--
Jean-Sebastien
