My point is that "removing it when the 'parent'-bundle stops" doesn't provide a full proof solution either. If power goes down (or system crashes, or an unchecked exception appears while shutting down, etc. etc.), the point where this bundle is supposed to be uninstalled is never reached and so the bundle remains installed. When that happens the bundle is already installed when you (re)start the server causing the original problem.
Regards, Ivo -----Original Message----- From: amdatu-developers-bounces at amdatu.org [mailto:[email protected]] On Behalf Of Angelo van der Sijpt Sent: donderdag 16 december 2010 13:44 To: amdatu-developers at amdatu.org Subject: Re: [Amdatu-developers] JAX-RS in our OSGi environment 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 _______________________________________________ Amdatu-developers mailing list Amdatu-developers at amdatu.org http://lists.amdatu.org/mailman/listinfo/amdatu-developers
