> I think the first main problem with these frameworks is how intrusive > they are, esp compared with whet they provide :( I suppose there's no > problem with doing a tomcat-osgi in the sandbox if people want to. As I > said I really don't care. We tried awfully hard to be not intrusive :-(
Actually, any JAR is an OSGi bundle by definition. Even if you do not add any extra information you will load and in certain cases, can be useful. However, it is really hard to provide functionality without providing any API ... By providing OSGi specific manifest headers you will make your code run in OSGi platforms unchanged. Today, many people are duplicating the effort to add these manifest headers for their products (Apache Felix commons, Eclipse Orbit, and hundreds of companies). Because this is not their core business they tend to use simple rules to modularize these libraries which works, but is not optimal because they are not intricately aware of the inter-package dependencies as you are. This kind of knowledge is required to properly modularize a complex system like Tomcat. When analyzing dependencies, one also usually finds reason to break the bigger chunks in smaller parts to remove many dependencies. Obviously, this is infeasible for outsiders to do right and even if they could, they would have to repeat this work for every release. OSGi imports and exports are package based. That is why it is important to separate API and implementation. The manifest headers allow you to shield the implementation code from outside usage and only expose API packages. There is no need to put these packages in separate bundles, on the contrary it is usually very advantageous to combine them. Even if you have multiple bundles that implement the same API, there is no issue with exporting those API packages multiple times. The OSGi resolvers can handle that case and even handle the case when versions differ. In the spirit of modularity, the OSGi API has only one mandatory part: the framework API. ALL other aspects are services (objects registered and unregistered dynamically in a service registry) and by their nature can be there or not. The framework API is quite small, it is one package with 26 classes/interfaces. This API is for management applications (install/start/stop/update/uninstall, introspection, etc) and for the use of the service registry. This low level API is often abstracted with "programming models" like Spring DM, Apache iPOJO, Declarative Services, SAT, etc. These models actually interact because they use the same underlying (dynamic) service model while not making the application handle the overhead of the service model. In an ideal situation (well for me and other OSGi users), Tomcat would provide an Http Service when running on an OSGi platform. However, just providing the right manifest headers would allow others to provide this service because it is not much code and I know many people have already done this with Tomcat. Kind regards, Peter Kriens remm wrote: > > On Wed, 2008-04-23 at 16:00 +0200, Florent.BENOIT wrote: >> Also, for OSGi, as all is done by package (import/export) the first step >> is to be sure that API and Implementation are never in the same package >> name. So we can export APIs and keep private the implementation. > > I think the first main problem with these frameworks is how intrusive > they are, esp compared with whet they provide :( I suppose there's no > problem with doing a tomcat-osgi in the sandbox if people want to. As I > said I really don't care. > > Rémy > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Osgifing-Tomcat-tp16830131p16930348.html Sent from the Tomcat - Dev mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
