On 07/16/2009 01:56 PM, Kris Pruden wrote:
On Jul 16, 2009, at 6:17 AM, Richard S. Hall wrote:
Yes, it has gone away. You could create a fragment for the client to
add the imports. Still not very clean, but better than the
alternatives perhaps (e.g., making the packages available via boot
delegation).
Is it possible for a "client" bundle to request that a fragment be
attached to it? According to the spec, it appears that the fragment
must declare their hosts via the Framework-Host manifest header. This
won't work because there may be multiple client (host) bundles, and
the clients aren't known at the time the fragment is defined.
If the clients aren't known in advance, then yes it will be difficult.
Also, it seems like requiring clients to attach a fragment bundle
isn't really any different than requiring the package imports since in
either case I'm leaking some implementation details of the service
bundle. If I replace the implementation with another which doesn't
use cglib, a different fragment would need to be attached. This isn't
tragic; I'm just testing my understanding.
It is different in as much as the client need not know about those
imports, so you could have different fragments to add different imports
in different scenarios, such as if you has different proxy generators
requiring different imports. However, it still sucks, I agree.
It looks like I could make it work cleanly (from the client bundle
implementors' perspective anyway) by putting the cglib code in a
"bootclasspath" extension fragment. Is this what you were referring
to by "boot delegation?"
I don't think any framework implements the boot class path extension
fragment, but yes that would be the approach. In absence of that, I was
referring to adding the packages to the app class path when launching
and setting the org.osgi.framework.bootdelegation property to include
the package. If you are using trunk, you will also need to set
org.osgi.framework.bundle.parent=app, which is part of the new standard
launching and embedding API for R4.2.
-> richard
Thanks for your help - if nothing else, I know to stop chasing the
x-implicitwire angle :)
Kris
-> richard
On 07/16/2009 12:37 PM, Kris Pruden wrote:
Hello,
I have an OSGi-based application which uses cglib. I'm running into
a problem that seems very similar to what's described here:
http://www.osgi.org/blog/2007/07/to-declare-or-not-to-declare.html
Basically, I have one bundle which calls a method on a service
provided by another bundle, passing it a class. The service
implementation uses cglib to generate an alternative implementation
of the passed-in class, and return an instance of it.
This all works fine in unit tests (not in an OSGi container), but
fails when run inside of felix with a ClassNotFoundException on
net.sf.cglib.proxy.Factory.
I was able to make this work by adding several cglib-specific
imports on my client bundle manifest, but I'd rather not do that
since the use of cglib is an implementation detail that I don't want
to leak to clients.
The above article suggests that the user of the x-implicitwire
directive will accomplish what I need, but it doesn't seem to work.
I came across this post:
http://mail-archives.apache.org/mod_mbox/felix-users/200801.mbox/%[email protected]%3e
Which indicates that this directive is just an experiment and may go
away. Has it been removed? If so, is there any viable alternative
to adding the explicit import in the client bundle(s)?
Thanks,
Kris
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
