Re: shared lib in Geronimo 3.0
On Mar 24, 2010, at 5:30 PM, David Jencks wrote: > > While I always thought shared lib was a bad idea, at least pre-osgi the > concept of a classloader that you could just toss things in made sense. I > don't think it makes any sense in osgi. There is no dynamic-export header so > whatever implementation you came up with would have to know exactly what > packages to export... making the idea of adding more stuff to it useless. If > you just make sure your jar is bundleized so the packages you want to use are > exported, and install the bundle in the osgi framework, the osgi wiring > mechanism will take care of making it available to your app, in a simpler, > uniform way that is much more flexible than shared lib was. > > In other words, plain vanilla osgi all by itself does what shared lib was for > much much better. The only inconvenience is that you have to make your > libraries into bundles somehow. We can certainly talk about how to help > people do that, but that will be generally useful and/or impossible to do > well. Understood. And I'm not claiming that we'd end up with the same runtime efficiencies of a common shared lib ClassLoader, in previous versions of Geronimo. However, we're processing WARs and EARs with packaged jar files. And we'd better be pretty good at that. And we're certainly not going to require users to convert these jars into bundles. So, is extending this capability to a sharedlib dirctory (outside of the archive) such a big stretch? It might not be as runtime efficient as it could be, but a class of users might well appreciate its simplicity. We also want to be making it easy for users to bundleize jars and incorporate them into Geronimo. However, I'm not convinced that users should always be required to bundlize their jars... --kevan
Re: shared lib in Geronimo 3.0
I wholeheartedly agree that if you're going to be in the OSGi runtime the shared lib approach doesn't make sense. You would be denying yourself all the benefits that OSGi brings in terms of classloading and flexibility. I just wanted to be clear that at a high level in 3.0 OSGi is not only a capability but also a requirement. Default conversions may work fine for some, but it might not work so well in practice if you have a large number of jars, in which case you (application developers) may have to bite the bullet and do the bundlization yourself. So this was really a question of transition/migration cost. The shared lib use case is/was useful when you have multiple wars that share a fair amount of jars. The wars themselves tend to be fairly small and lend themselves easily to automatic bundlization. What would be interesting is bundlizing the portion that was sitting in the shared lib. If the number of jars is significant, bundlizing each jar may prove to be quite time consuming (and not very automatic)... I suppose one possible idea to ease the transition is to make the shared lib optionally available via something like extra packages, but I admit that approach is neither clean nor desirable in the long term. Thanks, Sangjin On Wed, Mar 24, 2010 at 2:30 PM, David Jencks wrote: > > On Mar 24, 2010, at 2:10 PM, Kevan Miller wrote: > > > > > On Mar 24, 2010, at 4:57 PM, David Jencks wrote: > > > >> > >> On Mar 24, 2010, at 12:58 PM, Sangjin Lee wrote: > >> > >>> Thanks. So it sounds like it will be pretty much a *requirement* that > applications on 3.0 need to be fully OSGi bundles, > >> > >> Well, the idea is that the geronimo deployment process will turn your > javaee app into one or more bundles. We set up defaults for the osgi > manifest headers but you can modify them in your geronimo plans. > > > > Right. So traditional EE apps need not change. You can continue to deploy > EE defined artifacts (e.g. WAR/EAR/JAR). Users don't need to turn them into > bundles. Applications that used Geronimo deployment plan dependencies are > likely to require some changes... > > > >> > >>> and if you were using the shared lib as part of your classloading > scheme you will have to convert them all to OSGi bundles. > >> > >> Jars that aren't part of a javaee application need to be converted to > bundles before installing them. I guess we could provide a default > conversion but usually this doesn't seem to be adequate in practice. Do you > think this is going to be a problem for users? > > > > David never really liked shared-lib, to begin with... ;-) > > > > If you have compelling use cases, now is definitely a good time to speak > up... There's certainly a set of users that have found shared lib to be > convenient. > > While I always thought shared lib was a bad idea, at least pre-osgi the > concept of a classloader that you could just toss things in made sense. I > don't think it makes any sense in osgi. There is no dynamic-export header > so whatever implementation you came up with would have to know exactly what > packages to export... making the idea of adding more stuff to it useless. > If you just make sure your jar is bundleized so the packages you want to > use are exported, and install the bundle in the osgi framework, the osgi > wiring mechanism will take care of making it available to your app, in a > simpler, uniform way that is much more flexible than shared lib was. > > In other words, plain vanilla osgi all by itself does what shared lib was > for much much better. The only inconvenience is that you have to make your > libraries into bundles somehow. We can certainly talk about how to help > people do that, but that will be generally useful and/or impossible to do > well. > > thanks > david jencks > > > > > --kevan > >
Re: shared lib in Geronimo 3.0
On Mar 24, 2010, at 2:10 PM, Kevan Miller wrote: > > On Mar 24, 2010, at 4:57 PM, David Jencks wrote: > >> >> On Mar 24, 2010, at 12:58 PM, Sangjin Lee wrote: >> >>> Thanks. So it sounds like it will be pretty much a *requirement* that >>> applications on 3.0 need to be fully OSGi bundles, >> >> Well, the idea is that the geronimo deployment process will turn your javaee >> app into one or more bundles. We set up defaults for the osgi manifest >> headers but you can modify them in your geronimo plans. > > Right. So traditional EE apps need not change. You can continue to deploy EE > defined artifacts (e.g. WAR/EAR/JAR). Users don't need to turn them into > bundles. Applications that used Geronimo deployment plan dependencies are > likely to require some changes... > >> >>> and if you were using the shared lib as part of your classloading scheme >>> you will have to convert them all to OSGi bundles. >> >> Jars that aren't part of a javaee application need to be converted to >> bundles before installing them. I guess we could provide a default >> conversion but usually this doesn't seem to be adequate in practice. Do you >> think this is going to be a problem for users? > > David never really liked shared-lib, to begin with... ;-) > > If you have compelling use cases, now is definitely a good time to speak > up... There's certainly a set of users that have found shared lib to be > convenient. While I always thought shared lib was a bad idea, at least pre-osgi the concept of a classloader that you could just toss things in made sense. I don't think it makes any sense in osgi. There is no dynamic-export header so whatever implementation you came up with would have to know exactly what packages to export... making the idea of adding more stuff to it useless. If you just make sure your jar is bundleized so the packages you want to use are exported, and install the bundle in the osgi framework, the osgi wiring mechanism will take care of making it available to your app, in a simpler, uniform way that is much more flexible than shared lib was. In other words, plain vanilla osgi all by itself does what shared lib was for much much better. The only inconvenience is that you have to make your libraries into bundles somehow. We can certainly talk about how to help people do that, but that will be generally useful and/or impossible to do well. thanks david jencks > > --kevan
Re: shared lib in Geronimo 3.0
On Mar 24, 2010, at 4:57 PM, David Jencks wrote: > > On Mar 24, 2010, at 12:58 PM, Sangjin Lee wrote: > >> Thanks. So it sounds like it will be pretty much a *requirement* that >> applications on 3.0 need to be fully OSGi bundles, > > Well, the idea is that the geronimo deployment process will turn your javaee > app into one or more bundles. We set up defaults for the osgi manifest > headers but you can modify them in your geronimo plans. Right. So traditional EE apps need not change. You can continue to deploy EE defined artifacts (e.g. WAR/EAR/JAR). Users don't need to turn them into bundles. Applications that used Geronimo deployment plan dependencies are likely to require some changes... > >> and if you were using the shared lib as part of your classloading scheme you >> will have to convert them all to OSGi bundles. > > Jars that aren't part of a javaee application need to be converted to bundles > before installing them. I guess we could provide a default conversion but > usually this doesn't seem to be adequate in practice. Do you think this is > going to be a problem for users? David never really liked shared-lib, to begin with... ;-) If you have compelling use cases, now is definitely a good time to speak up... There's certainly a set of users that have found shared lib to be convenient. --kevan
Re: shared lib in Geronimo 3.0
On Mar 24, 2010, at 12:58 PM, Sangjin Lee wrote: > Thanks. So it sounds like it will be pretty much a *requirement* that > applications on 3.0 need to be fully OSGi bundles, Well, the idea is that the geronimo deployment process will turn your javaee app into one or more bundles. We set up defaults for the osgi manifest headers but you can modify them in your geronimo plans. > and if you were using the shared lib as part of your classloading scheme you > will have to convert them all to OSGi bundles. Jars that aren't part of a javaee application need to be converted to bundles before installing them. I guess we could provide a default conversion but usually this doesn't seem to be adequate in practice. Do you think this is going to be a problem for users? thanks david jencks > > Regards, > Sangjin > > On Wed, Mar 24, 2010 at 11:56 AM, David Jencks wrote: > > On Mar 24, 2010, at 9:20 AM, Sangjin Lee wrote: > > My apologies if this has been discussed before, but what is the thinking on > the shared lib on Geronimo 3.0? As Geronimo moves to the OSGi based > infrastructure, will it make it into G 3.0? If so, how would it be exposed in > terms of classloading? Thanks... > > I don't think this has been discussed. I don't think that shared lib makes > any sense in 3.0. Any jar you install needs to be a bundle already and once > the osgi kernel knows about it it can be used in wiring however it got > installed. We might want more tooling to help bundle-ify plain jars and to > clarify how to install bundles but I don't think shared lib makes sense. > > thanks for bringing this up > david jencks > > > Sangjin > > >
Re: shared lib in Geronimo 3.0
Thanks. So it sounds like it will be pretty much a *requirement* that applications on 3.0 need to be fully OSGi bundles, and if you were using the shared lib as part of your classloading scheme you will have to convert them all to OSGi bundles. Regards, Sangjin On Wed, Mar 24, 2010 at 11:56 AM, David Jencks wrote: > > On Mar 24, 2010, at 9:20 AM, Sangjin Lee wrote: > > My apologies if this has been discussed before, but what is the thinking >> on the shared lib on Geronimo 3.0? As Geronimo moves to the OSGi based >> infrastructure, will it make it into G 3.0? If so, how would it be exposed >> in terms of classloading? Thanks... >> > > I don't think this has been discussed. I don't think that shared lib makes > any sense in 3.0. Any jar you install needs to be a bundle already and once > the osgi kernel knows about it it can be used in wiring however it got > installed. We might want more tooling to help bundle-ify plain jars and to > clarify how to install bundles but I don't think shared lib makes sense. > > thanks for bringing this up > david jencks > > >> Sangjin >> >> >
Re: shared lib in Geronimo 3.0
On Mar 24, 2010, at 9:20 AM, Sangjin Lee wrote: My apologies if this has been discussed before, but what is the thinking on the shared lib on Geronimo 3.0? As Geronimo moves to the OSGi based infrastructure, will it make it into G 3.0? If so, how would it be exposed in terms of classloading? Thanks... I don't think this has been discussed. I don't think that shared lib makes any sense in 3.0. Any jar you install needs to be a bundle already and once the osgi kernel knows about it it can be used in wiring however it got installed. We might want more tooling to help bundle-ify plain jars and to clarify how to install bundles but I don't think shared lib makes sense. thanks for bringing this up david jencks Sangjin
shared lib in Geronimo 3.0
My apologies if this has been discussed before, but what is the thinking on the shared lib on Geronimo 3.0? As Geronimo moves to the OSGi based infrastructure, will it make it into G 3.0? If so, how would it be exposed in terms of classloading? Thanks... Sangjin
