I may be misunderstanding you, Neil. But, I do see the WAB having the role of a packaged web application, whereas I am thinking about the container that runs the WAB.
Thanks, Jochen On Wed, May 2, 2012 at 1:12 PM, Neil Bartlett <[email protected]> wrote: > Why not just create a Web Application Bundle (WAB)? > > If you read the Web Container chapter from the OSGi Enterprise 4.2 > specification, you will see how a WAR-type artefact can be mapped to a > bundle, with WEB-INF/classes and WEB-INF/lib/*.jar becoming part of the > Bundle-ClassPath. Since OSGi already creates a ClassLoader for each bundle, > this appears to match your requirements. > > Neil > > Jochen Wiedmann <[email protected]> > 2 May 2012 12:06 > No suggestions? > > On Wed, Apr 18, 2012 at 8:55 AM, Jochen Wiedmann > > > > Jochen Wiedmann <[email protected]> > 18 April 2012 07:55 > Okay, let's try a new start: > > Suggest, that I am implementing a J2EE container, like Tomcat, or > Jetty (in fact, Tomcat is the background I am asking) and would like > to see it running as an OSGI container. > > This means that I have to honour the J2EE specification, which > requires that a new ClassLoader is being created for any web > application, with all the jar files in WEB-INF/lib > and WEB-INF/classes. Additionally, the standard jar files (like > servlet.jar, or jsp.jar) must > still be present. > > How would I do that, if Felix were used to implement the "OSGI container" > part? > > Thanks, > > Jochen > > > > > Nick Baker <[email protected]> > 30 March 2012 19:04 > > It is possible to have jars private to a bundle by way of the > "Bundle-ClassPath" entry. Is there a way to do this programmatically? You > still wouldn't be able to parent it the way you want. > > My advice, after years of this, is that every time you're going against > the grain of the OSGI framework, you're better off changing your behavior > to adapting the existing system to better confirm to the OSGI system. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > Bram de Kruijff <[email protected]> > 30 March 2012 17:41 > > On Fri, Mar 30, 2012 at 5:54 PM, Jochen Wiedmann<[email protected]> > <[email protected]> wrote: > > 2012/3/30 Holger Hoffstätte <[email protected]> > <[email protected]>: > > > I don't know if that is "what you want" (or not), but it is certainly not > what would happen. :) The Bundles will be installed into the framework as > if installed "manually", and each will have its own classloader. > Essentially you will play the role of a deployment agent, which means you > will also be responsible for starting, stopping and eventually > uninstalling the bundles, as necessary. > > What I want is a new ClassLoader with all those bundles and the given parent. > > You can't do that. When you install a bundle it gets a > BundleClassloader that gets wired to other bundle's classloaders > according to it's import directives and the Parent/System classloader > for boot delegation. Having one specified parent classloader kind of > defies the purpose. Have a look at the OSGi specification for an > explanation of the class loading architecture. > > What you can do is use an approach like the PAX swissbox > BundleClassLoader [0] which takes a parent to consult first, but that > still will not make the bundles classloader delegate back to it when > it needs to load a class not physically inside the jar. > > Regards, > Bram > > [0] > https://github.com/ops4j/org.ops4j.pax.swissbox/blob/master/pax-swissbox-core/src/main/java/org/ops4j/pax/swissbox/core/BundleClassLoader.java > > > > > > using Bundle as the framework will wire them up to the > > > Jochen > > > -- > "Bildung kommt von Bildschirm und nicht von Buch, sonst hieße es ja Buchung." > Dieter Hildebrandt > > --------------------------------------------------------------------- > 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] > > -- "Bildung kommt von Bildschirm und nicht von Buch, sonst hieße es ja Buchung." Dieter Hildebrandt
