Deployment Admin Service always throwing Exception because of missing Manifest
Hey, i want to use your implementation of the deployment admin service for my osgi framework. I can start and get the service instance. But after calling the method "installDeploymentPackage" i get always the exception, that no manifest is present in the deployment package. I tested it, i can print the manifest entries in the programm code. I also copied the class "ContentCopyingJarInputStream" into my project for debugging and it also works. So i have no idea why the service is throwing this exception. Maybe i have to set some permissions to write the manifest copy while running in the osgi framework? Please help me... Greetings, Jörn Schumann
Re: how to enable http2 in jetty
As a user I really like the single bundle distribution that's currently provided. And I feel a bit foolish as I have a hard time locating my http2 experiment workspace... in that workspace I created a single bundle providing a ConnectorFactory and the additional Jetty dependencies that are required for http2. Would that be of any value? In that I'll search a bit more Regards, Bram On Mon, Oct 22, 2018 at 1:14 PM Carsten Ziegeler wrote: > I think delivering a module that has no way to be used on its own, is > not very useful. If you always need at least the same 8 (or whatever > number) of bundles just to get a base functionality running, then why > are these 8 separate bundles? Especially as you have to use the same > version across these bundles? > > I don't buy that the current way of bundling Jetty in Felix is just for > a demo-case. Thats at least to my experience not true at all. We > actually had requests from users to bundle everything into a single > piece. We used to have the http base as a separate bundle, but merged it > in on request. I personally find it very natural that if I want to get > an implementation of the http service, I get a single bundle. In fact, > today these are already two, the servlet api and the jetty bundle. But > at least thats all you need. Telling me that I would need 25 bundle > would make me look for a different solution. While that might be the > theoretical way of doing things, its definitely not the most practical > or useful way. > > I agree that we should try to make http2 a first class citizen and > preferable - at least preferable in my opinion - would be a single > bundle for this. If we end up with three or four that's fine as well, if > we end up with a two digit number this does look like a user friendly > way to me. > > Carsten > > > Am 21.10.2018 um 02:33 schrieb Eric Norman: > > David, > > > > I don't believe that the OSGi support in jetty is just an afterthought > and > > those modules are used in many high profile OSGi environments, such as > the > > eclipse IDE. In fact, Jetty is hosted by the eclipse foundation who is > all > > about OSGi. > > > > I think a reasonable explanation of the usage of ServiceLoader in their > > codebase is that jetty modules are not exclusively for OSGi so they are > > designed to work with or without OSGi involved. > > > > If I recall correctly, the ServiceLoader code was not used extensively in > > the jetty code. I think usage was only in a handful of places and most > had > > reasonable defaults if no ServiceLoader services were found which is why > it > > hasn't been a problem until now. > > > > My experience with the jetty project is that they are reasonable people > who > > are open to a patch to make it work without the spi-fly shim. > > > > But even if the jetty code is refactored and improved to no long require > > spi-fly, I still don't think a fat bundle packaging of jetty is > appropriate. > > > > But that's just my opinion, and I am perfectly content using my own fork > > for my projects if the community isn't interested. > > > > Regards, > > -Eric > > > > > > On Sat, Oct 20, 2018 at 3:24 PM David Jencks > > wrote: > > > >> Jetty may be modular, and each of their jars may include OSGI metadata > so > >> they are bundles, but the use of service loader (implied I think by the > >> discussion of spi-fly; I haven’t looked at jetty myself) carries an > >> extremely strong presumption that the jetty modularity is not very > >> compatible with osgi modularity. I’d regard the jetty modularity as > very > >> compatible with osgi if they provided “service” wiring that could use > >> either the OSGI registry directly or service loader directly. Relying > on > >> service loader only has a bias towards everything being in the same > class > >> loader, so it’s more likely to work correctly with a fat bundle than > with > >> spi-fly. > >> > >> These are rather abstract or philosophical arguments, so they may or may > >> not match the reality of using jetty in any particular way. > >> > >> david jencks > >> > >>> On Oct 20, 2018, at 1:20 PM, Eric Norman > >> wrote: > >>> > >>> Carsten and others, > >>> > >>> Well, if the newer jetty version of the jetty artifacts causes the code > >> to > >>> not compile then perhaps that is an issue you would want to raise with > >> the > >>> jetty folks to not make incompatible changes to the public APIs without > >>> incrementing the major version numbers of their exports? > >>> > >>> For me, the claim that the new jetty version breaks something isn't a > >>> compelling reason do continue on as before as the same argument could > be > >>> made for any third party artifact. If the third party releases a new > >>> version that doesn't work with your bundles then it seems to me that > the > >>> proper remedy would be to raise the issue with the third party, declare > >> the > >>> known issue in your own documentation and/or declare a more specific > >>> version range for the
Re: how to enable http2 in jetty
I think delivering a module that has no way to be used on its own, is not very useful. If you always need at least the same 8 (or whatever number) of bundles just to get a base functionality running, then why are these 8 separate bundles? Especially as you have to use the same version across these bundles? I don't buy that the current way of bundling Jetty in Felix is just for a demo-case. Thats at least to my experience not true at all. We actually had requests from users to bundle everything into a single piece. We used to have the http base as a separate bundle, but merged it in on request. I personally find it very natural that if I want to get an implementation of the http service, I get a single bundle. In fact, today these are already two, the servlet api and the jetty bundle. But at least thats all you need. Telling me that I would need 25 bundle would make me look for a different solution. While that might be the theoretical way of doing things, its definitely not the most practical or useful way. I agree that we should try to make http2 a first class citizen and preferable - at least preferable in my opinion - would be a single bundle for this. If we end up with three or four that's fine as well, if we end up with a two digit number this does look like a user friendly way to me. Carsten Am 21.10.2018 um 02:33 schrieb Eric Norman: David, I don't believe that the OSGi support in jetty is just an afterthought and those modules are used in many high profile OSGi environments, such as the eclipse IDE. In fact, Jetty is hosted by the eclipse foundation who is all about OSGi. I think a reasonable explanation of the usage of ServiceLoader in their codebase is that jetty modules are not exclusively for OSGi so they are designed to work with or without OSGi involved. If I recall correctly, the ServiceLoader code was not used extensively in the jetty code. I think usage was only in a handful of places and most had reasonable defaults if no ServiceLoader services were found which is why it hasn't been a problem until now. My experience with the jetty project is that they are reasonable people who are open to a patch to make it work without the spi-fly shim. But even if the jetty code is refactored and improved to no long require spi-fly, I still don't think a fat bundle packaging of jetty is appropriate. But that's just my opinion, and I am perfectly content using my own fork for my projects if the community isn't interested. Regards, -Eric On Sat, Oct 20, 2018 at 3:24 PM David Jencks wrote: Jetty may be modular, and each of their jars may include OSGI metadata so they are bundles, but the use of service loader (implied I think by the discussion of spi-fly; I haven’t looked at jetty myself) carries an extremely strong presumption that the jetty modularity is not very compatible with osgi modularity. I’d regard the jetty modularity as very compatible with osgi if they provided “service” wiring that could use either the OSGI registry directly or service loader directly. Relying on service loader only has a bias towards everything being in the same class loader, so it’s more likely to work correctly with a fat bundle than with spi-fly. These are rather abstract or philosophical arguments, so they may or may not match the reality of using jetty in any particular way. david jencks On Oct 20, 2018, at 1:20 PM, Eric Norman wrote: Carsten and others, Well, if the newer jetty version of the jetty artifacts causes the code to not compile then perhaps that is an issue you would want to raise with the jetty folks to not make incompatible changes to the public APIs without incrementing the major version numbers of their exports? For me, the claim that the new jetty version breaks something isn't a compelling reason do continue on as before as the same argument could be made for any third party artifact. If the third party releases a new version that doesn't work with your bundles then it seems to me that the proper remedy would be to raise the issue with the third party, declare the known issue in your own documentation and/or declare a more specific version range for the bundle/package imports in the affected consumer bundles that you have control over. Perhaps, the felix http bundle documentation could have some statement that says which versions of jetty were tested and certified against if that would make you more comfortable about the de-coupling. It seems to me that the jetty project has made a lot of efforts to make a modular system where you can chose which parts to include and they have made sure all their modules are OSGi bundles. Going back to jamming it all the jetty code into a fat bundle for the convenience of some demo-ware seems to be the wrong direction and I'm surprised that OSGi based project like felix would still be promoting such things. Also, this fat way of packaging jetty isn't tested by jetty proper, so who can say what side
Re: how to enable http2 in jetty
That sounds pretty interesting to me :) Regards Carsten Am 22.10.2018 um 13:36 schrieb Bram Pouwelse: As a user I really like the single bundle distribution that's currently provided. And I feel a bit foolish as I have a hard time locating my http2 experiment workspace... in that workspace I created a single bundle providing a ConnectorFactory and the additional Jetty dependencies that are required for http2. Would that be of any value? In that I'll search a bit more Regards, Bram On Mon, Oct 22, 2018 at 1:14 PM Carsten Ziegeler wrote: I think delivering a module that has no way to be used on its own, is not very useful. If you always need at least the same 8 (or whatever number) of bundles just to get a base functionality running, then why are these 8 separate bundles? Especially as you have to use the same version across these bundles? I don't buy that the current way of bundling Jetty in Felix is just for a demo-case. Thats at least to my experience not true at all. We actually had requests from users to bundle everything into a single piece. We used to have the http base as a separate bundle, but merged it in on request. I personally find it very natural that if I want to get an implementation of the http service, I get a single bundle. In fact, today these are already two, the servlet api and the jetty bundle. But at least thats all you need. Telling me that I would need 25 bundle would make me look for a different solution. While that might be the theoretical way of doing things, its definitely not the most practical or useful way. I agree that we should try to make http2 a first class citizen and preferable - at least preferable in my opinion - would be a single bundle for this. If we end up with three or four that's fine as well, if we end up with a two digit number this does look like a user friendly way to me. Carsten Am 21.10.2018 um 02:33 schrieb Eric Norman: David, I don't believe that the OSGi support in jetty is just an afterthought and those modules are used in many high profile OSGi environments, such as the eclipse IDE. In fact, Jetty is hosted by the eclipse foundation who is all about OSGi. I think a reasonable explanation of the usage of ServiceLoader in their codebase is that jetty modules are not exclusively for OSGi so they are designed to work with or without OSGi involved. If I recall correctly, the ServiceLoader code was not used extensively in the jetty code. I think usage was only in a handful of places and most had reasonable defaults if no ServiceLoader services were found which is why it hasn't been a problem until now. My experience with the jetty project is that they are reasonable people who are open to a patch to make it work without the spi-fly shim. But even if the jetty code is refactored and improved to no long require spi-fly, I still don't think a fat bundle packaging of jetty is appropriate. But that's just my opinion, and I am perfectly content using my own fork for my projects if the community isn't interested. Regards, -Eric On Sat, Oct 20, 2018 at 3:24 PM David Jencks wrote: Jetty may be modular, and each of their jars may include OSGI metadata so they are bundles, but the use of service loader (implied I think by the discussion of spi-fly; I haven’t looked at jetty myself) carries an extremely strong presumption that the jetty modularity is not very compatible with osgi modularity. I’d regard the jetty modularity as very compatible with osgi if they provided “service” wiring that could use either the OSGI registry directly or service loader directly. Relying on service loader only has a bias towards everything being in the same class loader, so it’s more likely to work correctly with a fat bundle than with spi-fly. These are rather abstract or philosophical arguments, so they may or may not match the reality of using jetty in any particular way. david jencks On Oct 20, 2018, at 1:20 PM, Eric Norman wrote: Carsten and others, Well, if the newer jetty version of the jetty artifacts causes the code to not compile then perhaps that is an issue you would want to raise with the jetty folks to not make incompatible changes to the public APIs without incrementing the major version numbers of their exports? For me, the claim that the new jetty version breaks something isn't a compelling reason do continue on as before as the same argument could be made for any third party artifact. If the third party releases a new version that doesn't work with your bundles then it seems to me that the proper remedy would be to raise the issue with the third party, declare the known issue in your own documentation and/or declare a more specific version range for the bundle/package imports in the affected consumer bundles that you have control over. Perhaps, the felix http bundle documentation could have some statement that says which versions of jetty were tested and certified against if that would make
[ANN] Felix Dependency Manager R13 Released
Dear Felix users; The Felix team is pleased to announce the release of Dependency Manager R13 version. You will find a quick summary of the changes here: http://felix.apache.org/documentation/subprojects/apache-felix-dependency-manager/guides/whatsnew-r13.html This release is available from http://felix.apache.org/downloads.cgi Release Notes: ** Bug * [FELIX-5683] - getServiceProperties returns null instead of empty dictionary * [FELIX-5716] - Dead Lock in DM * [FELIX-5768] - DM Lambda stop callback not being called * [FELIX-5955] - Move changelog.txt to toplevel project dir * [FELIX-5956] - NPE when invoking a lifecycle runnable method from init method ** New Feature * [FELIX-5336] - Add support for prototype scope services in DM4 ** Improvement * [FELIX-5967] - DM does not support java9+ * [FELIX-5937] - Refactor DM bndtools/gradle project * [FELIX-5939] - DM annotations enhancements * [FELIX-5941] - DM APi enhancements * [FELIX-5957] - Check if a default implementation is used only on optional dependencies ** Task * [FELIX-5960] - Do not supply MD5 checksum List of bundles being part of the release: * org.apache.felix.dependencymanager; version=4.5.0 * org.apache.felix.dependencymanager.shell; version=4.0.7 * org.apache.felix.dependencymanager.runtime; version=4.0.6 * org.apache.felix.dependencymanager.annotation; version=5.0.0 * org.apache.felix.dependencymanager.lambda; version=1.2.0 Enjoy! -The Felix team
Re: how to enable http2 in jetty
I agree with Carsten, if we want to help the adoption of OSGI these kind of bundles should be "plug 'n play" ;-) It should also be simple to use another http service implementation (e.g. glassfish) but this also is not very simple, there are also no tutorials of any kind (that I know of) how to do this. So for now we are pretty limited in this regard... Op ma 22 okt. 2018 om 13:14 schreef Carsten Ziegeler : > I think delivering a module that has no way to be used on its own, is > not very useful. If you always need at least the same 8 (or whatever > number) of bundles just to get a base functionality running, then why > are these 8 separate bundles? Especially as you have to use the same > version across these bundles? > > I don't buy that the current way of bundling Jetty in Felix is just for > a demo-case. Thats at least to my experience not true at all. We > actually had requests from users to bundle everything into a single > piece. We used to have the http base as a separate bundle, but merged it > in on request. I personally find it very natural that if I want to get > an implementation of the http service, I get a single bundle. In fact, > today these are already two, the servlet api and the jetty bundle. But > at least thats all you need. Telling me that I would need 25 bundle > would make me look for a different solution. While that might be the > theoretical way of doing things, its definitely not the most practical > or useful way. > > I agree that we should try to make http2 a first class citizen and > preferable - at least preferable in my opinion - would be a single > bundle for this. If we end up with three or four that's fine as well, if > we end up with a two digit number this does look like a user friendly > way to me. > > Carsten > > > Am 21.10.2018 um 02:33 schrieb Eric Norman: > > David, > > > > I don't believe that the OSGi support in jetty is just an afterthought > and > > those modules are used in many high profile OSGi environments, such as > the > > eclipse IDE. In fact, Jetty is hosted by the eclipse foundation who is > all > > about OSGi. > > > > I think a reasonable explanation of the usage of ServiceLoader in their > > codebase is that jetty modules are not exclusively for OSGi so they are > > designed to work with or without OSGi involved. > > > > If I recall correctly, the ServiceLoader code was not used extensively in > > the jetty code. I think usage was only in a handful of places and most > had > > reasonable defaults if no ServiceLoader services were found which is why > it > > hasn't been a problem until now. > > > > My experience with the jetty project is that they are reasonable people > who > > are open to a patch to make it work without the spi-fly shim. > > > > But even if the jetty code is refactored and improved to no long require > > spi-fly, I still don't think a fat bundle packaging of jetty is > appropriate. > > > > But that's just my opinion, and I am perfectly content using my own fork > > for my projects if the community isn't interested. > > > > Regards, > > -Eric > > > > > > On Sat, Oct 20, 2018 at 3:24 PM David Jencks > > wrote: > > > >> Jetty may be modular, and each of their jars may include OSGI metadata > so > >> they are bundles, but the use of service loader (implied I think by the > >> discussion of spi-fly; I haven’t looked at jetty myself) carries an > >> extremely strong presumption that the jetty modularity is not very > >> compatible with osgi modularity. I’d regard the jetty modularity as > very > >> compatible with osgi if they provided “service” wiring that could use > >> either the OSGI registry directly or service loader directly. Relying > on > >> service loader only has a bias towards everything being in the same > class > >> loader, so it’s more likely to work correctly with a fat bundle than > with > >> spi-fly. > >> > >> These are rather abstract or philosophical arguments, so they may or may > >> not match the reality of using jetty in any particular way. > >> > >> david jencks > >> > >>> On Oct 20, 2018, at 1:20 PM, Eric Norman > >> wrote: > >>> > >>> Carsten and others, > >>> > >>> Well, if the newer jetty version of the jetty artifacts causes the code > >> to > >>> not compile then perhaps that is an issue you would want to raise with > >> the > >>> jetty folks to not make incompatible changes to the public APIs without > >>> incrementing the major version numbers of their exports? > >>> > >>> For me, the claim that the new jetty version breaks something isn't a > >>> compelling reason do continue on as before as the same argument could > be > >>> made for any third party artifact. If the third party releases a new > >>> version that doesn't work with your bundles then it seems to me that > the > >>> proper remedy would be to raise the issue with the third party, declare > >> the > >>> known issue in your own documentation and/or declare a more specific > >>> version range for the bundle/package imports in the
