You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Jochen Wiedmann <jo...@gmail.com> on 2012/04/18 08:55:13 UTC
Re: ClassLoader creation
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 <nb...@pentaho.com> wrote:
> On 3/30/12 12:41 PM, "Bram de Kruijff" <bd...@gmail.com> wrote:
>
>>On Fri, Mar 30, 2012 at 5:54 PM, Jochen Wiedmann
>><jo...@gmail.com> wrote:
>>> 2012/3/30 Holger Hoffstätte <ho...@googlemail.com>:
>>>
>>>> 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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
--
"Bildung kommt von Bildschirm und nicht von Buch, sonst hieße es ja Buchung."
Dieter Hildebrandt
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: ClassLoader creation
Posted by Achim Nierbeck <bc...@googlemail.com>.
+1, forgot to mention this :)
2012/5/2 Neil Bartlett <nj...@gmail.com>
> 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 <jo...@gmail.com>
> 2 May 2012 12:06
> No suggestions?
>
> On Wed, Apr 18, 2012 at 8:55 AM, Jochen Wiedmann
>
>
>
> Jochen Wiedmann <jo...@gmail.com>
> 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 <nb...@pentaho.com>
> 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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
> Bram de Kruijff <bd...@gmail.com>
> 30 March 2012 17:41
>
> On Fri, Mar 30, 2012 at 5:54 PM, Jochen Wiedmann<jo...@gmail.com> <jo...@gmail.com> wrote:
>
> 2012/3/30 Holger Hoffstätte <ho...@googlemail.com> <ho...@googlemail.com>:
>
>
> 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: users-unsubscribe@felix.apache.org
>
> For additional commands, e-mail: users-help@felix.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
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/>
Re: ClassLoader creation
Posted by Neil Bartlett <nj...@gmail.com>.
Jochen,
As Achim points out, implementations of the WAB specification are
already available, such as PAX-Web. However if you are interested in
implementing such a container yourself then the specification also
describes how that is done.
Regards,
Neil
> Achim Nierbeck <ma...@googlemail.com>
> 2 May 2012 12:43
> Then take a look at pax-web it's one of the available containers for
> WAB ...
>
> 2012/5/2 Jochen Wiedmann <jo...@gmail.com>
>
>
>
> Jochen Wiedmann <ma...@gmail.com>
> 2 May 2012 12:42
> 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
>
>
>
>
>
> --
> "Bildung kommt von Bildschirm und nicht von Buch, sonst hieße es ja
> Buchung."
> Dieter Hildebrandt
>
>
> Neil Bartlett <ma...@gmail.com>
> 2 May 2012 12:12
> 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 <ma...@gmail.com>
> 2 May 2012 12:06
> No suggestions?
>
> On Wed, Apr 18, 2012 at 8:55 AM, Jochen Wiedmann
>
>
>
> Jochen Wiedmann <ma...@gmail.com>
> 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
>
>
>
>
Re: ClassLoader creation
Posted by Achim Nierbeck <bc...@googlemail.com>.
Then take a look at pax-web it's one of the available containers for WAB ...
2012/5/2 Jochen Wiedmann <jo...@gmail.com>
> 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 <nj...@gmail.com>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 <jo...@gmail.com>
>> 2 May 2012 12:06
>> No suggestions?
>>
>> On Wed, Apr 18, 2012 at 8:55 AM, Jochen Wiedmann
>>
>>
>>
>> Jochen Wiedmann <jo...@gmail.com>
>> 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 <nb...@pentaho.com>
>> 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: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>> Bram de Kruijff <bd...@gmail.com>
>> 30 March 2012 17:41
>>
>> On Fri, Mar 30, 2012 at 5:54 PM, Jochen Wiedmann<jo...@gmail.com> <jo...@gmail.com> wrote:
>>
>> 2012/3/30 Holger Hoffstätte <ho...@googlemail.com> <ho...@googlemail.com>:
>>
>>
>> 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: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
>
> --
> "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/>
Re: ClassLoader creation
Posted by Jochen Wiedmann <jo...@gmail.com>.
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 <nj...@gmail.com> 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 <jo...@gmail.com>
> 2 May 2012 12:06
> No suggestions?
>
> On Wed, Apr 18, 2012 at 8:55 AM, Jochen Wiedmann
>
>
>
> Jochen Wiedmann <jo...@gmail.com>
> 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 <nb...@pentaho.com>
> 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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
> Bram de Kruijff <bd...@gmail.com>
> 30 March 2012 17:41
>
> On Fri, Mar 30, 2012 at 5:54 PM, Jochen Wiedmann<jo...@gmail.com> <jo...@gmail.com> wrote:
>
> 2012/3/30 Holger Hoffstätte <ho...@googlemail.com> <ho...@googlemail.com>:
>
>
> 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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
"Bildung kommt von Bildschirm und nicht von Buch, sonst hieße es ja
Buchung."
Dieter Hildebrandt
Re: ClassLoader creation
Posted by Neil Bartlett <nj...@gmail.com>.
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 <ma...@gmail.com>
> 2 May 2012 12:06
> No suggestions?
>
> On Wed, Apr 18, 2012 at 8:55 AM, Jochen Wiedmann
>
>
>
> Jochen Wiedmann <ma...@gmail.com>
> 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 <ma...@pentaho.com>
> 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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
> Bram de Kruijff <ma...@gmail.com>
> 30 March 2012 17:41
> On Fri, Mar 30, 2012 at 5:54 PM, Jochen Wiedmann
> <jo...@gmail.com> wrote:
>> 2012/3/30 Holger Hoffstätte<ho...@googlemail.com>:
>>
>>> 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: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
Re: ClassLoader creation
Posted by Achim Nierbeck <bc...@googlemail.com>.
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 <jo...@gmail.com>:
> No suggestions?
>
> On Wed, Apr 18, 2012 at 8:55 AM, Jochen Wiedmann
> <jo...@gmail.com> 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 <nb...@pentaho.com> wrote:
>>> On 3/30/12 12:41 PM, "Bram de Kruijff" <bd...@gmail.com> wrote:
>>>
>>>>On Fri, Mar 30, 2012 at 5:54 PM, Jochen Wiedmann
>>>><jo...@gmail.com> wrote:
>>>>> 2012/3/30 Holger Hoffstätte <ho...@googlemail.com>:
>>>>>
>>>>>> 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: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>>
>>
>> --
>> "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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
--
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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: ClassLoader creation
Posted by Jochen Wiedmann <jo...@gmail.com>.
No suggestions?
On Wed, Apr 18, 2012 at 8:55 AM, Jochen Wiedmann
<jo...@gmail.com> 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 <nb...@pentaho.com> wrote:
>> On 3/30/12 12:41 PM, "Bram de Kruijff" <bd...@gmail.com> wrote:
>>
>>>On Fri, Mar 30, 2012 at 5:54 PM, Jochen Wiedmann
>>><jo...@gmail.com> wrote:
>>>> 2012/3/30 Holger Hoffstätte <ho...@googlemail.com>:
>>>>
>>>>> 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: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
>
>
> --
> "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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org