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
