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 > >
