my suggestion, first try something that is already present in the OSS ecosystem, if this doesn't fit your needs either adapt your needs or help improve the OSS part. regarding your needs of a OSGi compatible webcontainer, there is the Felix Approach for the HTTP-Service and there is for example Pax Web, also using Jetty. I think in the Virgo/Gemeni ecosystem there is also some sort of OSGi-Compatible WebContainer available.
I'd start there and see if this is already what I want. :) 2012/5/2 Jochen Wiedmann <[email protected]>: > No suggestions? > > On Wed, Apr 18, 2012 at 8:55 AM, Jochen Wiedmann > <[email protected]> wrote: >> 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 >> >> >> On Fri, Mar 30, 2012 at 8:04 PM, Nick Baker <[email protected]> wrote: >>> On 3/30/12 12:41 PM, "Bram de Kruijff" <[email protected]> wrote: >>> >>>>On Fri, Mar 30, 2012 at 5:54 PM, Jochen Wiedmann >>>><[email protected]> wrote: >>>>> 2012/3/30 Holger Hoffstätte <[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 >>> >>> 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] >>> >> >> >> >> -- >> "Bildung kommt von Bildschirm und nicht von Buch, sonst hieße es ja Buchung." >> Dieter Hildebrandt > > > > -- > "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] > -- 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/> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
