felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <cziege...@apache.org>
Subject Re: how to enable http2 in jetty
Date Mon, 22 Oct 2018 12:20:34 GMT
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 <cziegeler@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 <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 <eric.d.norman@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
>>>>>>> <mailto:cziegeler@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 <mailto:cziegeler@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 <mailto:raymond.auge@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 <mailto:cziegeler@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
>>>>>>>      <mailto:nvdloon@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 <mailto:cziegeler@apache.org>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>>      <mailto:users-unsubscribe@felix.apache.org>
>>>>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>      <mailto: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 <mailto:cziegeler@apache.org>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>>      <mailto:users-unsubscribe@felix.apache.org>
>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>      <mailto:users-help@felix.apache.org>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>      --
>>>>>>>      Carsten Ziegeler
>>>>>>>      Adobe Research Switzerland
>>>>>>>      cziegeler@apache.org <mailto:cziegeler@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


Mime
View raw message