Relationship to JSR 291 [was: Re: Bryan's comments]

[Richard S. Hall]

Andy Piper wrote:
> At 00:53 08/06/2007, Bryan Atsatt wrote:
>
>> I truly believe that the Java world will be far better served by having
>> 277 support ONLY import-by-package!
>>
>> But there has been this background fear that import-by-package is
>> somehow terribly complex. I can certainly believe that the union of all
>> the OSGi features *does* result in a lot of complexity.
>>
>
> Just to express a usage datapoint here. Having used OSGi for a while
> now I am finding import-by-package too hard to use in certain
> circumstances (but in general it is a nice flexible model), but its
> not an issue that import-by-name really fixes in my opinion.
>
> The basic issue is that to use something I am interested in the union
> of packages that make up the "feature". I actually don't care about
> the individual packages. Take my current bugbear, cglib in Spring for
> example, to use this "feature" the *proxied* class bundle needs to
> import the following packages:
>
>   net.sf.cglib.proxy,
>   net.sf.cglib.core,
>   net.sf.cglib.reflect,
>   org.aopalliance.aop,
>   org.springframework.aop.framework,
>   org.springframework.aop,
>
> not an obvious set, nor a set of packages that I care much about.
> Worse, the proxied class does not know ahead of time that it needs to
> import these packages (this is I believe because cglib tries to
> create the proxy in the classloader of the proxied class by default).
>
> Ideally to solve this I would like two things:
>
> 1. The ability to express a feature in terms of its constituent
> packages. Note that import-by-name doesn't really help here since the
> actual packages are distributed across multiple modules. What I
> really want is some kind of feature module that exports these
> packages to you when you ask for the feature.
>
> 2. Some way of augmenting a module *after* the fact with a particular
> set of packages, so that the module doesn't need to do dynamic-import
> * everywhere.
>
> I don't think either if these is possible in OSGi right now (I would
> be happy to be corrected!). I don't think JSR 277 solves these either
> (but again I would be happy to be corrected).
>

Yes, you are correct that both of these are not currently
possible...well, I guess (2) is technically possible since you could
grab the original bundle JAR file and rewrite its manifest then install
it, but I know this is not what you want.

Both of these have been discussed at one point in time or the other.
Peter Kriens was recently talking to me about something similar to (1),
so we might be doing some experiments in this area. I think something
like (1) could fit in the OSGi model fairly well, but more investigation
is needed to be sure.

-> richard

> Just a datapoint from real-world usage.
>
> andy
>
>
> Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
>