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]
