Richard, thanks a lot for taking the time to explain all of that to me. Makes much more sense now.
Happy weekend Tobias On 10.09.2010, at 15:21, "Richard S. Hall" <[email protected]> wrote: > On 9/10/10 5:15, Wunden Tobias wrote: >> The only thing that I don't understand is that if Felix really is only >> loading bundles, then why should a bundle make assumptions about it's >> runtime environment (daemon vs. interactive) and shut down the whole >> framework if these assumptions don't hold. t just seems strange to me, which >> is likely to mean that I don't understand the design rather than the design >> being wrong :-) > > The Felix framework is only loading bundles. Actually, the launcher is > creating a framework instance and installing/starting any bundles contained > in the bundle/ directory. The framework by itself won't load any bundles at > all. > > In this particular case, I don't believe that Gogo is shutting down the > entire framework, it is just grabbing stdin. In general, you are correct, > bundles shouldn't make assumptions about what they are allowed to do; for > example, you can't stop bundles from calling System.exit() unless you plan to > enable security. > > But the shell bundle is somewhat special in this case. The distribution we > provide of the Felix framework is intended to be a developer distribution, > which will typically be used in an interactive way by a developer. If you > don't want Gogo grabbing stdin, then you should either a) not deploy it or b) > configure it not to do so. But from a development perspective, it is doing > exactly what we want, since we don't want a headless developer distribution. > > Keep in mind, the situation would be no different for a bundle wanting to > display a GUI. In your case, you also wouldn't want this. The OSGi framework > is a generic module layer, you can build any type of application with it > (interactive or not, server or client, etc.), so everything a bundle does is > based on some assumption about how it is going to be used. > > -> richard > >> Again, thanks for your quick (and patient) help! >> >> Tobias >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
