[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-j] ISSUE 60 - Sharing Java artifacts across contributions - proposal
| Hi Dave, I'm definitely sympathetic with this approach, particularly as our runtime supports Java import/export based on the OSGi specification. If we want to specify Java import/export, my inclination would be to do this fully which would include the following: 1. Reference the OSGi core modularity specification as the basis, similar to how we refer to the JAX-WS specification. I don't think we should replicate a portion of the specification, leaving out some key parts (see my next points). 2. The SCA specification needs to address Java artifact sharing in terms of a classloader architecture. This can be done by referring to the OSGi modularity specification, which is written that way. QName sharing doesn't need to do this as artifacts can be referenced "by value". However, with Java we need to capture the significant difference between guaranteeing a shared artifact (i.e. a class) is loaded by the same classloader and an approach which simply makes a contribution JAR available on the classpath of another contribution. 3. In line with #2, do not support a location attribute or at least figure out how it is consistent with the classloader architecture specified by OSGi. My understanding of the location attribute is that it uses the value to dereference a JAR (are other formats such as file:// supported?) and places it on the contribution classpath. That is a lot different than sharing classloaders between contributions. 4. Include support for the OSGi uses directive 5. Include support for OSGi version range semantics, i.e. [, ], (, and ). 6. Specify the structure of version numbering using OSGi 7. Change how imports and exports are specified in Java. Allowing multiple packages and versions to be specified in the package attribute (singular) seems a bit strange and it is more difficult to validate. My preference would be to have one package per import/export element and separate out version numbers into separate attributes. I would also like to support OSGi JAR manifest headers where people can specify imports and exports using OSGi syntax and have those "merged" into the sca-contribution manifest. This will allow SCA runtimes to use OSGi bundles and tooling (e.g. bnd) as-is. 8. The above would describe the contribution classloader architecture. We need to describe how that classloader structure is manifested at runtime when executing components. I believe this amounts to saying components run in the context of a classloader associated with their originating contribution (this may not be the same classloader as that which loaded the contribution since the component may be running on a different machine than where the contribution is "installed"). In line with this, we should define consistent behavior for the thread context classloader (that is also an issue in OSGi). 9. Make Java import/export an optional compliance point. Some runtimes may not be able to support OSGi or want to. Jim On Jan 17, 2009, at 5:36 AM, David Booz wrote:
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]