Generating a bundle at runtime, and removing it when the 'parent'-bundle stops is pretty doable. The only special case that remains is removing the parent-bundle (and the generated bundle), without refreshing the framework, which causes jax-rs users to be wired to the now-obsolete package.
I don't like the idea of linking the delegation to deployment, since it poses an additional constraint on the environment of the (regular) bundles. Angelo On Dec 16, 2010, at 10:37 AM, Ivo Ladage-van Doorn wrote: > I wonder how you would implement '(since we cannot change the exported > packages at run time, we could e.g. generate a new bundle that exports these > packages)'. You will need to make sure that you uninstall the bundle before > the framework shuts down, otherwise after a restart the problem reappears. > But how do you ensure that? In case of power outage for example, the bundle > will not be reinstalled. > There might be a third option; I think the AMA starts the OSGi container, > right? If so, it could start a small boot app that initializes the > RuntimeDelegation in that VM before the OSGi container is started. Is that an > option? > > Regards, Ivo > > > -----Original Message----- > From: amdatu-developers-bounces at amdatu.org > [mailto:amdatu-developers-bounces at amdatu.org] On Behalf Of Bram de Kruijff > Sent: woensdag 15 december 2010 15:52 > To: amdatu-developers at amdatu.org > Subject: Re: [Amdatu-developers] JAX-RS in our OSGi environment > > 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 >> > > _______________________________________________ > Amdatu-developers mailing list > Amdatu-developers at amdatu.org > http://lists.amdatu.org/mailman/listinfo/amdatu-developers > > _______________________________________________ > Amdatu-developers mailing list > Amdatu-developers at amdatu.org > http://lists.amdatu.org/mailman/listinfo/amdatu-developers
