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 <cziege...@apache.org>: > 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 <david.a.jen...@gmail.com> > > 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 <eric.d.nor...@gmail.com> > >> 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 > >>> effects may be lurking? > >>> > >>> The eclipse equinox impl of the http service works in the "thin" way > >> like I > >>> have proposed and looks to me like a better solution. Is there much > >>> collaboration between equinox and felix on the parts that seem to be > >> common > >>> to both? > >>> > >>> Regarding your suggestions: I still don't see a good solution with > your > >>> hybrid approach either since the same problems I raised in the July > >> message > >>> thread about the activation timing remain. For example. the bundle > >>> activator where jetty is started synchronously happens before the > spifly > >>> bundle extender makes the ServiceLoader stuff available so any > >>> ServiceLoader configuration embedded inside of the felix.http bundle > >> would > >>> not be available yet when jetty is starting up. > >>> > >>> Plus I'm not sure I like the impression that http/2 support would have > >> the > >>> appearance of being a second-class feature when wider adoption of > http/2 > >>> would be better for everyone. > >>> > >>> Regards, > >>> -Eric > >>> > >>> On Sat, Oct 20, 2018 at 5:25 AM Carsten Ziegeler <cziege...@apache.org > > > >>> wrote: > >>> > >>>> Let's focus for a minute on having jetty as separate bundles. This > will > >>>> potentially create a lot of problems as people will use the wrong > jetty > >>>> version. I just recently updated from on 9.4.x version to the next > >>>> 9.4.(x+1) version and our code was not even compiling anymore. > Therefore > >>>> ultimately our code is tied to a very specific version of Jetty. > >>>> From that PoV it's dangerous to not bundle jetty. > >>>> My suggestion is still: > >>>> - we bundle Jetty as today but add the missing service loader files. > >>>> This bundle has code to support http2 if the additional stuff is > >> installed. > >>>> - for people needing http2 they install a number of more bundles and > >>>> voila everything works. > >>>> > >>>> Unless this plan is not possible, I don't see a reason why we > shouldn't > >>>> go there? > >>>> > >>>> Carsten > >>>> > >>>> > >>>> Am 19.10.2018 um 17:34 schrieb Raymond Auge: > >>>>> > >>>>> > >>>>> On Fri, Oct 19, 2018 at 11:11 AM Carsten Ziegeler < > >> cziege...@apache.org > >>>>> <mailto:cziege...@apache.org>> wrote: > >>>>> > >>>>> > >>>>> > >>>>> Am 19.10.2018 um 17:06 schrieb Raymond Auge: > >>>>>> On Fri, Oct 19, 2018 at 10:55 AM Carsten Ziegeler > >>>>> <cziege...@apache.org <mailto:cziege...@apache.org>> > >>>>>> wrote: > >>>>>> > >>>>>>> Well, you are assuming that people are using a tool which does > >>>> the > >>>>>>> resolving. Today you can simply download the Apache Felix Jetty > >>>>> bundle, > >>>>>>> install and enjoy. No tooling required. With such a proposal > >>>> we're > >>>>>>> breaking this experience > >>>>>>> > >>>>>> > >>>>>> Can I get a vote as to how many people actually get this > >>>> experience? > >>>>>> > >>>>>> I feel this only works when you already know _exactly_ what you > >>>>> want, which > >>>>>> I do not feel is the norm. > >>>>> > >>>>> Not sure if I can follow here, people know that they want the > Jetty > >>>>> module, download it, install it and have a party. We've > constantly > >>>>> seeing people in our mailing lists saying that. > >>>>> > >>>>> > >>>>> I understand this. Perhaps we should simply offer an additional > >>>>> packaging which relies on the jetty BOM as a dependency. The benefit > >>>>> being we don't have to wait for Jetty to provide something special, > >>>>> since they already provide the BOM for exactly this purpose. > >>>>> > >>>>> I feel most people do not go to the Felix website and download jars > >>>>> except as part of experiments. It is my own experience that people > use > >> a > >>>>> build tool which relies on dependencies stored in maven central > (using > >>>>> maven or gradle or some other build tool). > >>>>> > >>>>> In that way, and because felix.http.jetty is a implementation, they > >>>>> don't care about how the transitive dependencies are handled or > >>>>> provided; as long as the parts they need get into their deployment. > >>>>> > >>>>> - Ray > >>>>> > >>>>> > >>>>> While resolver based tooling is awesome, it's not the way all > people > >>>>> work. Whether that is good or bad, does not matter. Requiring > over > >> 20 > >>>>> bundles to be installed to get a single functionality working > seems > >>>>> really like overkill. > >>>>> > >>>>> Regards > >>>>> Carsten > >>>>> > >>>>>> > >>>>>> - Ray > >>>>>> > >>>>>> > >>>>>>> > >>>>>>> Carsten > >>>>>>> > >>>>>>> Am 19.10.2018 um 16:10 schrieb Raymond Auge: > >>>>>>>> I know in the past I argued against exposing all the jetty > >>>>> bundles. But I > >>>>>>>> feel I was probably wrong back then. I think that with the > >>>>> jetty BOM and > >>>>>>>> the OSGi resolver, figuring out which bundles you need, and > >>>>> then adding > >>>>>>>> additional ones to suite your case, is not so hard. > >>>>>>>> > >>>>>>>> Furthermore, Service Loader Mediator is not as painful anymore, > >>>>> just use > >>>>>>> an > >>>>>>>> R7 framework with the SpiFly framework extension. > >>>>>>>> > >>>>>>>> - Ray > >>>>>>>> > >>>>>>>> On Fri, Oct 19, 2018 at 9:30 AM Raymond Auge > >>>>> <raymond.a...@liferay.com <mailto:raymond.a...@liferay.com>> > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>>> Why not start relying on the Jetty BOM and let people depend > >>>>> on the > >>>>>>>>> bundles what they want, at least this way they can let the > >>>>> resolver > >>>>>>>>> assemble the bundles they need? > >>>>>>>>> > >>>>>>>>> - Ray > >>>>>>>>> > >>>>>>>>> On Fri, Oct 19, 2018 at 3:39 AM Carsten Ziegeler > >>>>> <cziege...@apache.org <mailto:cziege...@apache.org>> > >>>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>>> The other option would be if jetty could provide us one fat > >>>>> bundle, to > >>>>>>>>>> avoid having users to install N bundles, it would just be one > >>>>>>> additional. > >>>>>>>>>> > >>>>>>>>>> Regards > >>>>>>>>>> Carsten > >>>>>>>>>> > >>>>>>>>>> Am 19.10.2018 um 09:35 schrieb Carsten Ziegeler: > >>>>>>>>>>> Hi Eric, > >>>>>>>>>>> > >>>>>>>>>>> I would like to come back to this discussion; I somehow > >>>>> forgot to > >>>>>>>>>> follow > >>>>>>>>>>> up on the old thread. > >>>>>>>>>>> If we go with a thin Apache Felix Jetty bundle, then you > >>>> need to > >>>>>>>>>> install > >>>>>>>>>>> a lot of other bundles even if you don't use http2. So > >>>>> updating from a > >>>>>>>>>>> current version to this new version is not nice. > >>>>>>>>>>> > >>>>>>>>>>> How about we still include the jetty bundles inside, fix the > >>>>> service > >>>>>>>>>>> loader configuration by including it - but do not include > >>>>> the other > >>>>>>>>>>> things needed for http2 support. So if you're not using > >>>>> http2, it > >>>>>>> works > >>>>>>>>>>> like today. > >>>>>>>>>>> If you use http2 you install additionally spifly and what > >>>>> else is > >>>>>>>>>>> required to make it work. > >>>>>>>>>>> > >>>>>>>>>>> Would that work? > >>>>>>>>>>> > >>>>>>>>>>> Regards > >>>>>>>>>>> Carsten > >>>>>>>>>>> > >>>>>>>>>>> Am 18.10.2018 um 19:59 schrieb Eric Norman: > >>>>>>>>>>>> Yes, with a few changes to the felix.http code it is > >>>>> possible to make > >>>>>>>>>> it > >>>>>>>>>>>> work. > >>>>>>>>>>>> > >>>>>>>>>>>> I stashed the code changes in my github fork at > >>>>>>>>>>>> https://github.com/enapps-enorman/felix which I think you > >>>> have > >>>>>>> already > >>>>>>>>>>>> discovered? > >>>>>>>>>>>> > >>>>>>>>>>>> I would be willing to initiate a PR from the fork, but > >>>>> unfortunately > >>>>>>>>>> the > >>>>>>>>>>>> http/2 support doesn't work without changing how the > >>>> felix.http > >>>>>>> bundle > >>>>>>>>>> is > >>>>>>>>>>>> packaged as discussed on the felix mailing list at: > >>>>>>>>>>>> > >>>>> > https://www.mail-archive.com/users@felix.apache.org/msg18187.html > >>>>>>>>>>>> > >>>>>>>>>>>> The felix community seemed reluctant to make the packaging > >>>>> changes to > >>>>>>>>>> the > >>>>>>>>>>>> felix.http bundle so I didn't send the PR at the time. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Regards, > >>>>>>>>>>>> > >>>>>>>>>>>> Eric > >>>>>>>>>>>> > >>>>>>>>>>>> On Thu, Oct 18, 2018 at 10:04 AM Naftali <nvdl...@gmail.com > >>>>> <mailto:nvdl...@gmail.com>> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>>> Hi, is there any way to enable enable HTTP/2 support in > >>>>> the embedded > >>>>>>>>>>>>> felix > >>>>>>>>>>>>> jetty? > >>>>>>>>>>>>> > >>>>>>>>>>>>> Greetz Naftali > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> -- > >>>>>>>>>> Carsten Ziegeler > >>>>>>>>>> Adobe Research Switzerland > >>>>>>>>>> cziege...@apache.org <mailto:cziege...@apache.org> > >>>>>>>>>> > >>>>>>>>>> > >>>>> > >> --------------------------------------------------------------------- > >>>>>>>>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > >>>>> <mailto:users-unsubscr...@felix.apache.org> > >>>>>>>>>> For additional commands, e-mail: users-h...@felix.apache.org > >>>>> <mailto:users-h...@felix.apache.org> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> -- > >>>>>>>>> *Raymond Augé* < > >>>> http://www.liferay.com/web/raymond.auge/profile> > >>>>>>>>> (@rotty3000) > >>>>>>>>> Senior Software Architect *Liferay, Inc.* < > >>>> http://www.liferay.com> > >>>>>>>>> (@Liferay) > >>>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> > >>>>>>>>> (@OSGiAlliance) > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> Carsten Ziegeler > >>>>>>> Adobe Research Switzerland > >>>>>>> cziege...@apache.org <mailto:cziege...@apache.org> > >>>>>>> > >>>>>>> > >>>>> > >> --------------------------------------------------------------------- > >>>>>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > >>>>> <mailto:users-unsubscr...@felix.apache.org> > >>>>>>> For additional commands, e-mail: users-h...@felix.apache.org > >>>>> <mailto:users-h...@felix.apache.org> > >>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>>> -- > >>>>> Carsten Ziegeler > >>>>> Adobe Research Switzerland > >>>>> cziege...@apache.org <mailto:cziege...@apache.org> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> *Raymond Augé* > >>>>> <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) > >>>>> Senior Software Architect *Liferay, Inc.* > >>>>> <http://www.liferay.com> (@Liferay) > >>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> > >>>> (@OSGiAlliance) > >>>> > >>>> -- > >>>> Carsten Ziegeler > >>>> Adobe Research Switzerland > >>>> cziege...@apache.org > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > >>>> For additional commands, e-mail: users-h...@felix.apache.org > >>>> > >>>> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > >> For additional commands, e-mail: users-h...@felix.apache.org > >> > >> > > > > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > > -- Met vriendelijke groet, Naftali van der Loon
