You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Naftali <nv...@gmail.com> on 2018/10/18 17:04:21 UTC
how to enable http2 in jetty
Hi, is there any way to enable enable HTTP/2 support in the embedded felix
jetty?
Greetz Naftali
Re: how to enable http2 in jetty
Posted by Raymond Auge <ra...@liferay.com>.
I'm of the mind that the Service Loader Mediator spec (implemented by
SpiFly) is an excellent (if not the only reasonable one) approach to handle
exactly the case that jetty uses it for which is to allow them to remain
plain JARs while also being usable OSGi bundles. The fact that it relies on
requirements and capabilities means that resolution just works, not only at
runtime, but also at build time.
We should be so lucky if other big projects would follow jetty's lead. All
we need is to convince jetty to shift their bundle versions to the left
(drop the leading segment) and pretty much all would be well.
Sincerely,
- Ray
On Sat, Oct 20, 2018, 20:33 Eric Norman, <er...@gmail.com> wrote:
> 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 <da...@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 <er...@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 <cziegeler@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 <
> > cziegeler@apache.org
> > >>> <ma...@apache.org>> wrote:
> > >>>
> > >>>
> > >>>
> > >>> Am 19.10.2018 um 17:06 schrieb Raymond Auge:
> > >>>> On Fri, Oct 19, 2018 at 10:55 AM Carsten Ziegeler
> > >>> <cziegeler@apache.org <ma...@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.auge@liferay.com <ma...@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
> > >>> <cziegeler@apache.org <ma...@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 <nvdloon@gmail.com
> > >>> <ma...@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
> > >>>>>>>> cziegeler@apache.org <ma...@apache.org>
> > >>>>>>>>
> > >>>>>>>>
> > >>>
> > ---------------------------------------------------------------------
> > >>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > >>> <ma...@felix.apache.org>
> > >>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
> > >>> <ma...@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
> > >>>>> cziegeler@apache.org <ma...@apache.org>
> > >>>>>
> > >>>>>
> > >>>
> > ---------------------------------------------------------------------
> > >>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > >>> <ma...@felix.apache.org>
> > >>>>> For additional commands, e-mail: users-help@felix.apache.org
> > >>> <ma...@felix.apache.org>
> > >>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>> --
> > >>> Carsten Ziegeler
> > >>> Adobe Research Switzerland
> > >>> cziegeler@apache.org <ma...@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
> > >> cziegeler@apache.org
> > >>
> > >> ---------------------------------------------------------------------
> > >> 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: how to enable http2 in jetty
Posted by Carsten Ziegeler <cz...@apache.org>.
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 <cz...@apache.org>
> 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 <da...@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 <er...@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 <cziegeler@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 <
>>>> cziegeler@apache.org
>>>>>>> <ma...@apache.org>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Am 19.10.2018 um 17:06 schrieb Raymond Auge:
>>>>>>>> On Fri, Oct 19, 2018 at 10:55 AM Carsten Ziegeler
>>>>>>> <cziegeler@apache.org <ma...@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.auge@liferay.com <ma...@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
>>>>>>> <cziegeler@apache.org <ma...@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 <nvdloon@gmail.com
>>>>>>> <ma...@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
>>>>>>>>>>>> cziegeler@apache.org <ma...@apache.org>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>> <ma...@felix.apache.org>
>>>>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>> <ma...@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
>>>>>>>>> cziegeler@apache.org <ma...@apache.org>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>> <ma...@felix.apache.org>
>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>> <ma...@felix.apache.org>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Carsten Ziegeler
>>>>>>> Adobe Research Switzerland
>>>>>>> cziegeler@apache.org <ma...@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
>>>>>> cziegeler@apache.org
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>>>>
>>>>
>>>
>>
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziegeler@apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: how to enable http2 in jetty
Posted by Bram Pouwelse <br...@pouwelse.com>.
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 <cz...@apache.org>
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 <da...@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 <er...@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 <cziegeler@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 <
> >> cziegeler@apache.org
> >>>>> <ma...@apache.org>> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>> Am 19.10.2018 um 17:06 schrieb Raymond Auge:
> >>>>>> On Fri, Oct 19, 2018 at 10:55 AM Carsten Ziegeler
> >>>>> <cziegeler@apache.org <ma...@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.auge@liferay.com <ma...@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
> >>>>> <cziegeler@apache.org <ma...@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 <nvdloon@gmail.com
> >>>>> <ma...@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
> >>>>>>>>>> cziegeler@apache.org <ma...@apache.org>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>
> >> ---------------------------------------------------------------------
> >>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >>>>> <ma...@felix.apache.org>
> >>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
> >>>>> <ma...@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
> >>>>>>> cziegeler@apache.org <ma...@apache.org>
> >>>>>>>
> >>>>>>>
> >>>>>
> >> ---------------------------------------------------------------------
> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >>>>> <ma...@felix.apache.org>
> >>>>>>> For additional commands, e-mail: users-help@felix.apache.org
> >>>>> <ma...@felix.apache.org>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>> --
> >>>>> Carsten Ziegeler
> >>>>> Adobe Research Switzerland
> >>>>> cziegeler@apache.org <ma...@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
> >>>> cziegeler@apache.org
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> 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
> >>
> >>
> >
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: how to enable http2 in jetty
Posted by Bram Pouwelse <br...@pouwelse.com>.
I managed to find the results of my old http2 experiment and pushed it to
https://bitbucket.org/brampouwelse/felix-jetty-http2
Looking at it again it's a bit more than just a single bundle as the ALPN
stuff needs to be on the boot classpath but it's close. But there is a
nasty detail in how the service loader is used by
Jetty's PreEncodedHttpField. As that's using the ServiceLoader in a static
initializer and the result is stored in a final field, so adding the http2
support from another bundle will be hard.
I think that it could work ok when org.eclipse.jetty.http2.hpack (which has
no dependencies on other http2 packages) could be part of the main bundle
so PreEncodedHttpField would always be initialized in a way that http2 is
supported.
To be able to use http2 a separate bundle could be installed that will
depend on the alpn stuff on from boot classpath, that bundle could then
provide the http2 connector.
Cheers,
Bram
On Wed, Oct 24, 2018 at 10:06 AM Timothy Ward <ti...@apache.org>
wrote:
> I would also like to support the notion of continuing to “embed” Jetty in
> the Felix Http bundle. The whole point of the Felix Jetty bundle is to
> provide an Http Whiteboard implementation, forcing people to install tens
> of Jetty bundles to make that work would be a nightmare (particularly with
> Jetty’s non OSGi friendly use of “extensions” to locate core features). The
> resolver can help to an extent, but actually it’s not possible to work out
> which modules to include when so many of them depend on configuration (for
> example I only need the SSL connector if I want to use SSL). Another good
> example of this pattern is the Aries JAX-RS whiteboard, this embeds a whole
> bunch of CXF bundles because otherwise it’s really hard to make sure you
> get the correct bundles pulled in.
>
> Ideally Felix Jetty would be enhanced to allow for additional
> connectors/plugins to be provided using OSGi services (to get around the
> ServiceLoader problem) and provide packages for things like http2, session
> replication, and other cool Jetty extensions. There are still the issues of
> getting the resolver to pick the features that you want (they’re only
> needed by configuration) and making sure that you get good feedback from
> the Felix Jetty bundle about missing extensions (i.e. you configured me to
> need the http2 connector but the service isn’t available), but at least it
> provides a vaguely consumable solution for end users.
>
> Best Regards,
>
> Tim
>
> > On 22 Oct 2018, at 19:35, Naftali van der Loon <na...@vanderloon.nl>
> wrote:
> >
> > 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 <
> cziegeler@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.jencks@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 <er...@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 <
> cziegeler@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 <
> >>>> cziegeler@apache.org
> >>>>>>> <ma...@apache.org>> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Am 19.10.2018 um 17:06 schrieb Raymond Auge:
> >>>>>>>> On Fri, Oct 19, 2018 at 10:55 AM Carsten Ziegeler
> >>>>>>> <cziegeler@apache.org <ma...@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.auge@liferay.com <ma...@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
> >>>>>>> <cziegeler@apache.org <ma...@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 <nvdloon@gmail.com
> >>>>>>> <ma...@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
> >>>>>>>>>>>> cziegeler@apache.org <ma...@apache.org>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>
> >>>> ---------------------------------------------------------------------
> >>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >>>>>>> <ma...@felix.apache.org>
> >>>>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
> >>>>>>> <ma...@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
> >>>>>>>>> cziegeler@apache.org <ma...@apache.org>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>> ---------------------------------------------------------------------
> >>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >>>>>>> <ma...@felix.apache.org>
> >>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
> >>>>>>> <ma...@felix.apache.org>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Carsten Ziegeler
> >>>>>>> Adobe Research Switzerland
> >>>>>>> cziegeler@apache.org <ma...@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
> >>>>>> cziegeler@apache.org
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> 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
> >>>>
> >>>>
> >>>
> >>
> >> --
> >> Carsten Ziegeler
> >> Adobe Research Switzerland
> >> cziegeler@apache.org
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >> For additional commands, e-mail: users-help@felix.apache.org
> >>
> >>
> >
> > --
> > Met vriendelijke groet,
> >
> > Naftali van der Loon
>
>
Re: how to enable http2 in jetty
Posted by Timothy Ward <ti...@apache.org>.
I would also like to support the notion of continuing to “embed” Jetty in the Felix Http bundle. The whole point of the Felix Jetty bundle is to provide an Http Whiteboard implementation, forcing people to install tens of Jetty bundles to make that work would be a nightmare (particularly with Jetty’s non OSGi friendly use of “extensions” to locate core features). The resolver can help to an extent, but actually it’s not possible to work out which modules to include when so many of them depend on configuration (for example I only need the SSL connector if I want to use SSL). Another good example of this pattern is the Aries JAX-RS whiteboard, this embeds a whole bunch of CXF bundles because otherwise it’s really hard to make sure you get the correct bundles pulled in.
Ideally Felix Jetty would be enhanced to allow for additional connectors/plugins to be provided using OSGi services (to get around the ServiceLoader problem) and provide packages for things like http2, session replication, and other cool Jetty extensions. There are still the issues of getting the resolver to pick the features that you want (they’re only needed by configuration) and making sure that you get good feedback from the Felix Jetty bundle about missing extensions (i.e. you configured me to need the http2 connector but the service isn’t available), but at least it provides a vaguely consumable solution for end users.
Best Regards,
Tim
> On 22 Oct 2018, at 19:35, Naftali van der Loon <na...@vanderloon.nl> wrote:
>
> 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 <cz...@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 <da...@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 <er...@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 <cziegeler@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 <
>>>> cziegeler@apache.org
>>>>>>> <ma...@apache.org>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Am 19.10.2018 um 17:06 schrieb Raymond Auge:
>>>>>>>> On Fri, Oct 19, 2018 at 10:55 AM Carsten Ziegeler
>>>>>>> <cziegeler@apache.org <ma...@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.auge@liferay.com <ma...@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
>>>>>>> <cziegeler@apache.org <ma...@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 <nvdloon@gmail.com
>>>>>>> <ma...@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
>>>>>>>>>>>> cziegeler@apache.org <ma...@apache.org>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>> <ma...@felix.apache.org>
>>>>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>> <ma...@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
>>>>>>>>> cziegeler@apache.org <ma...@apache.org>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>> <ma...@felix.apache.org>
>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>> <ma...@felix.apache.org>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Carsten Ziegeler
>>>>>>> Adobe Research Switzerland
>>>>>>> cziegeler@apache.org <ma...@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
>>>>>> cziegeler@apache.org
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>>>>
>>>>
>>>
>>
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziegeler@apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
> --
> Met vriendelijke groet,
>
> Naftali van der Loon
Re: how to enable http2 in jetty
Posted by Naftali van der Loon <na...@vanderloon.nl>.
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 <cz...@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 <da...@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 <er...@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 <cziegeler@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 <
> >> cziegeler@apache.org
> >>>>> <ma...@apache.org>> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>> Am 19.10.2018 um 17:06 schrieb Raymond Auge:
> >>>>>> On Fri, Oct 19, 2018 at 10:55 AM Carsten Ziegeler
> >>>>> <cziegeler@apache.org <ma...@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.auge@liferay.com <ma...@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
> >>>>> <cziegeler@apache.org <ma...@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 <nvdloon@gmail.com
> >>>>> <ma...@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
> >>>>>>>>>> cziegeler@apache.org <ma...@apache.org>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>
> >> ---------------------------------------------------------------------
> >>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >>>>> <ma...@felix.apache.org>
> >>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
> >>>>> <ma...@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
> >>>>>>> cziegeler@apache.org <ma...@apache.org>
> >>>>>>>
> >>>>>>>
> >>>>>
> >> ---------------------------------------------------------------------
> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >>>>> <ma...@felix.apache.org>
> >>>>>>> For additional commands, e-mail: users-help@felix.apache.org
> >>>>> <ma...@felix.apache.org>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>> --
> >>>>> Carsten Ziegeler
> >>>>> Adobe Research Switzerland
> >>>>> cziegeler@apache.org <ma...@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
> >>>> cziegeler@apache.org
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> 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
> >>
> >>
> >
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Met vriendelijke groet,
Naftali van der Loon
Re: how to enable http2 in jetty
Posted by Carsten Ziegeler <cz...@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 <da...@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 <er...@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 <cz...@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 <
>> cziegeler@apache.org
>>>>> <ma...@apache.org>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> Am 19.10.2018 um 17:06 schrieb Raymond Auge:
>>>>>> On Fri, Oct 19, 2018 at 10:55 AM Carsten Ziegeler
>>>>> <cziegeler@apache.org <ma...@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.auge@liferay.com <ma...@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
>>>>> <cziegeler@apache.org <ma...@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 <nvdloon@gmail.com
>>>>> <ma...@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
>>>>>>>>>> cziegeler@apache.org <ma...@apache.org>
>>>>>>>>>>
>>>>>>>>>>
>>>>>
>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> <ma...@felix.apache.org>
>>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>> <ma...@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
>>>>>>> cziegeler@apache.org <ma...@apache.org>
>>>>>>>
>>>>>>>
>>>>>
>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> <ma...@felix.apache.org>
>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>> <ma...@felix.apache.org>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Carsten Ziegeler
>>>>> Adobe Research Switzerland
>>>>> cziegeler@apache.org <ma...@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
>>>> cziegeler@apache.org
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>
>>
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: how to enable http2 in jetty
Posted by Eric Norman <er...@gmail.com>.
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 <da...@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 <er...@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 <cz...@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 <
> cziegeler@apache.org
> >>> <ma...@apache.org>> wrote:
> >>>
> >>>
> >>>
> >>> Am 19.10.2018 um 17:06 schrieb Raymond Auge:
> >>>> On Fri, Oct 19, 2018 at 10:55 AM Carsten Ziegeler
> >>> <cziegeler@apache.org <ma...@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.auge@liferay.com <ma...@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
> >>> <cziegeler@apache.org <ma...@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 <nvdloon@gmail.com
> >>> <ma...@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
> >>>>>>>> cziegeler@apache.org <ma...@apache.org>
> >>>>>>>>
> >>>>>>>>
> >>>
> ---------------------------------------------------------------------
> >>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >>> <ma...@felix.apache.org>
> >>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
> >>> <ma...@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
> >>>>> cziegeler@apache.org <ma...@apache.org>
> >>>>>
> >>>>>
> >>>
> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >>> <ma...@felix.apache.org>
> >>>>> For additional commands, e-mail: users-help@felix.apache.org
> >>> <ma...@felix.apache.org>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>> --
> >>> Carsten Ziegeler
> >>> Adobe Research Switzerland
> >>> cziegeler@apache.org <ma...@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
> >> cziegeler@apache.org
> >>
> >> ---------------------------------------------------------------------
> >> 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: how to enable http2 in jetty
Posted by David Jencks <da...@gmail.com>.
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 <er...@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 <cz...@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 <cziegeler@apache.org
>>> <ma...@apache.org>> wrote:
>>>
>>>
>>>
>>> Am 19.10.2018 um 17:06 schrieb Raymond Auge:
>>>> On Fri, Oct 19, 2018 at 10:55 AM Carsten Ziegeler
>>> <cziegeler@apache.org <ma...@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.auge@liferay.com <ma...@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
>>> <cziegeler@apache.org <ma...@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 <nvdloon@gmail.com
>>> <ma...@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
>>>>>>>> cziegeler@apache.org <ma...@apache.org>
>>>>>>>>
>>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> <ma...@felix.apache.org>
>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>> <ma...@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
>>>>> cziegeler@apache.org <ma...@apache.org>
>>>>>
>>>>>
>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> <ma...@felix.apache.org>
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>> <ma...@felix.apache.org>
>>>>>
>>>>>
>>>>
>>>
>>> --
>>> Carsten Ziegeler
>>> Adobe Research Switzerland
>>> cziegeler@apache.org <ma...@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
>> cziegeler@apache.org
>>
>> ---------------------------------------------------------------------
>> 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: how to enable http2 in jetty
Posted by Eric Norman <er...@gmail.com>.
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 <cz...@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 <cziegeler@apache.org
> > <ma...@apache.org>> wrote:
> >
> >
> >
> > Am 19.10.2018 um 17:06 schrieb Raymond Auge:
> > > On Fri, Oct 19, 2018 at 10:55 AM Carsten Ziegeler
> > <cziegeler@apache.org <ma...@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.auge@liferay.com <ma...@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
> > <cziegeler@apache.org <ma...@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 <nvdloon@gmail.com
> > <ma...@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
> > >>>>> cziegeler@apache.org <ma...@apache.org>
> > >>>>>
> > >>>>>
> > ---------------------------------------------------------------------
> > >>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > <ma...@felix.apache.org>
> > >>>>> For additional commands, e-mail: users-help@felix.apache.org
> > <ma...@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
> > >> cziegeler@apache.org <ma...@apache.org>
> > >>
> > >>
> > ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > <ma...@felix.apache.org>
> > >> For additional commands, e-mail: users-help@felix.apache.org
> > <ma...@felix.apache.org>
> > >>
> > >>
> > >
> >
> > --
> > Carsten Ziegeler
> > Adobe Research Switzerland
> > cziegeler@apache.org <ma...@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
> cziegeler@apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: how to enable http2 in jetty
Posted by Raymond Auge <ra...@liferay.com>.
Cool, it's a start!
- Ray
On Sat, Oct 20, 2018 at 8:38 AM Naftali <nv...@gmail.com> wrote:
> I agree, this solution would suffice for now and impact would be nihil.
>
> Op za 20 okt. 2018 om 14:25 schreef Carsten Ziegeler <cziegeler@apache.org
> >:
>
> > 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 <
> cziegeler@apache.org
> > > <ma...@apache.org>> wrote:
> > >
> > >
> > >
> > > Am 19.10.2018 um 17:06 schrieb Raymond Auge:
> > > > On Fri, Oct 19, 2018 at 10:55 AM Carsten Ziegeler
> > > <cziegeler@apache.org <ma...@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.auge@liferay.com <ma...@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
> > > <cziegeler@apache.org <ma...@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 <
> nvdloon@gmail.com
> > > <ma...@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
> > > >>>>> cziegeler@apache.org <ma...@apache.org>
> > > >>>>>
> > > >>>>>
> > >
> ---------------------------------------------------------------------
> > > >>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > > <ma...@felix.apache.org>
> > > >>>>> For additional commands, e-mail:
> users-help@felix.apache.org
> > > <ma...@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
> > > >> cziegeler@apache.org <ma...@apache.org>
> > > >>
> > > >>
> > >
> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > > <ma...@felix.apache.org>
> > > >> For additional commands, e-mail: users-help@felix.apache.org
> > > <ma...@felix.apache.org>
> > > >>
> > > >>
> > > >
> > >
> > > --
> > > Carsten Ziegeler
> > > Adobe Research Switzerland
> > > cziegeler@apache.org <ma...@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
> > cziegeler@apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@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)
Re: how to enable http2 in jetty
Posted by Naftali <nv...@gmail.com>.
I agree, this solution would suffice for now and impact would be nihil.
Op za 20 okt. 2018 om 14:25 schreef Carsten Ziegeler <cz...@apache.org>:
> 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 <cziegeler@apache.org
> > <ma...@apache.org>> wrote:
> >
> >
> >
> > Am 19.10.2018 um 17:06 schrieb Raymond Auge:
> > > On Fri, Oct 19, 2018 at 10:55 AM Carsten Ziegeler
> > <cziegeler@apache.org <ma...@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.auge@liferay.com <ma...@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
> > <cziegeler@apache.org <ma...@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 <nvdloon@gmail.com
> > <ma...@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
> > >>>>> cziegeler@apache.org <ma...@apache.org>
> > >>>>>
> > >>>>>
> > ---------------------------------------------------------------------
> > >>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > <ma...@felix.apache.org>
> > >>>>> For additional commands, e-mail: users-help@felix.apache.org
> > <ma...@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
> > >> cziegeler@apache.org <ma...@apache.org>
> > >>
> > >>
> > ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > <ma...@felix.apache.org>
> > >> For additional commands, e-mail: users-help@felix.apache.org
> > <ma...@felix.apache.org>
> > >>
> > >>
> > >
> >
> > --
> > Carsten Ziegeler
> > Adobe Research Switzerland
> > cziegeler@apache.org <ma...@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
> cziegeler@apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: how to enable http2 in jetty
Posted by Carsten Ziegeler <cz...@apache.org>.
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 <cziegeler@apache.org
> <ma...@apache.org>> wrote:
>
>
>
> Am 19.10.2018 um 17:06 schrieb Raymond Auge:
> > On Fri, Oct 19, 2018 at 10:55 AM Carsten Ziegeler
> <cziegeler@apache.org <ma...@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.auge@liferay.com <ma...@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
> <cziegeler@apache.org <ma...@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 <nvdloon@gmail.com
> <ma...@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
> >>>>> cziegeler@apache.org <ma...@apache.org>
> >>>>>
> >>>>>
> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> <ma...@felix.apache.org>
> >>>>> For additional commands, e-mail: users-help@felix.apache.org
> <ma...@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
> >> cziegeler@apache.org <ma...@apache.org>
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> <ma...@felix.apache.org>
> >> For additional commands, e-mail: users-help@felix.apache.org
> <ma...@felix.apache.org>
> >>
> >>
> >
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org <ma...@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
cziegeler@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: how to enable http2 in jetty
Posted by Carsten Ziegeler <cz...@apache.org>.
Am 19.10.2018 um 17:06 schrieb Raymond Auge:
> On Fri, Oct 19, 2018 at 10:55 AM Carsten Ziegeler <cz...@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.
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 <ra...@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 <cz...@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 <nv...@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
>>>>> cziegeler@apache.org
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@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
>> cziegeler@apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: how to enable http2 in jetty
Posted by Raymond Auge <ra...@liferay.com>.
On Fri, Oct 19, 2018 at 10:55 AM Carsten Ziegeler <cz...@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.
- 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 <ra...@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 <cz...@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 <nv...@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
> >>> cziegeler@apache.org
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >>> For additional commands, e-mail: users-help@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
> cziegeler@apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@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)
Re: how to enable http2 in jetty
Posted by Carsten Ziegeler <cz...@apache.org>.
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
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 <ra...@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 <cz...@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 <nv...@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
>>> cziegeler@apache.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@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
cziegeler@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: how to enable http2 in jetty
Posted by Raymond Auge <ra...@liferay.com>.
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 <ra...@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 <cz...@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 <nv...@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
>> cziegeler@apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@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)
>
--
*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)
Re: how to enable http2 in jetty
Posted by Raymond Auge <ra...@liferay.com>.
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 <cz...@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 <nv...@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
> cziegeler@apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@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)
Re: how to enable http2 in jetty
Posted by Carsten Ziegeler <cz...@apache.org>.
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 <nv...@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
cziegeler@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: how to enable http2 in jetty
Posted by Carsten Ziegeler <cz...@apache.org>.
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 <nv...@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
cziegeler@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: how to enable http2 in jetty
Posted by Eric Norman <er...@gmail.com>.
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 <nv...@gmail.com> wrote:
> Hi, is there any way to enable enable HTTP/2 support in the embedded felix
> jetty?
>
> Greetz Naftali
>