You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by "Richard S. Hall" <he...@ungoverned.org> on 2009/07/16 15:17:54 UTC
Re: x-implicitwire still available?
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).
-> 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/%3C47824E8E.6040706@ungoverned.org%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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: x-implicitwire still available?
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 07/16/2009 03:18 PM, Kris Pruden wrote:
> On Jul 16, 2009, at 7:03 AM, Richard S. Hall wrote:
>
>>> 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.
>
> Hm, thanks for the info. I'll have to give some thought into which
> option I dislike the least :)
>
> Out of curiosity: I know the the boot class path extension feature is
> not required by the spec, but are there any plans to provide that
> feature in felix?
It is more a feature of a launcher, not the framework, probably, but I
haven't given too much thought about how it would be implemented.
I don't see it on the horizon, but never say never. :-)
-> richard
>
>> -> richard
>
> Thanks again,
>
> Kris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: x-implicitwire still available?
Posted by Kris Pruden <kp...@gmail.com>.
On Jul 16, 2009, at 7:03 AM, Richard S. Hall wrote:
>> 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.
Hm, thanks for the info. I'll have to give some thought into which
option I dislike the least :)
Out of curiosity: I know the the boot class path extension feature is
not required by the spec, but are there any plans to provide that
feature in felix?
> -> richard
Thanks again,
Kris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: x-implicitwire still available?
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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/%3C47824E8E.6040706@ungoverned.org%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: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: x-implicitwire still available?
Posted by Kris Pruden <kp...@gmail.com>.
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.
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 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?"
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/%3C47824E8E.6040706@ungoverned.org%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: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org