For now I'd consider embedding / attching the bundle as the way to go
"for now". It changes nothing for clients (except) solving the issue
and I think we can safely assume WINK is our default (and only)
implementation for now.

Other thoughts on the issue..

* Aries SPI fly adresses (but not yet solve?) the issue:
http://incubator.apache.org/aries/spi-fly.html
* What about an SPIProviderDependecy extension to the DependecyManager?


Regards,
Bram


On Wed, Dec 15, 2010 at 3:01 PM, Angelo van der Sijpt
<angelo.vandersijpt at luminis.eu> wrote:
> Hi List,
>
> Working with Amdatu-200 ( http://jira.amdatu.org/jira/browse/AMDATU-200 ), I 
> came across and old friend, who has already been described at 
> http://www.amdatu.org/confluence/display/Amdatu/OSGiification .
>
> In short, if the bundle containing Wink gets started _after_ some other 
> bundles tries to use JAX-RS classes, this user will find himself with a
> ?java.lang.ClassNotFoundException: com.sun.ws.rs.ext.RuntimeDelegateImpl
> because JAX-RS tries to use the VM-specific implementation, in stead of the 
> ones provided by Wink. This is made worse by the fact that a lot of endpoints 
> now use some cache settings. Since bundles using JAX-RS get resolved, and can 
> happily start up because they are resolved, there is no way we can stop them 
> until the Wink delegate is set.
>
> I can see a number of solutions that don't really solve the problem, such as
> * creating a JaxRSIsReady interface, on which Rest-using components should 
> depend,
> or don't solve the problem at all, such as
> * moving the JAX-RS classes to the Wink bundle.
>
> There are two 'real' solutions that spring to mind.
> 1. Make the framework bundle export the implementation classes for the VM 
> we're currently running on, or
> 2. Only exporting the JAX-RS packages _after_ Wink has started (since we 
> cannot change the exported packages at run time, we could e.g. generate a new 
> bundle that exports these packages).
>
> 1. has the drawback that it puts an additional burden on someone who wants to 
> run Amdatu, and 2. feels a little hacky .
>
> Any other thought?
>
> Angelo
> _______________________________________________
> Amdatu-developers mailing list
> Amdatu-developers at amdatu.org
> http://lists.amdatu.org/mailman/listinfo/amdatu-developers
>

Reply via email to