Then take a look at pax-web it's one of the available containers for WAB ...
2012/5/2 Jochen Wiedmann <[email protected]> > 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 > > > -- Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead blog <http://notizblog.nierbeck.de/>
