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 11:14:43 GMT
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


Mime
View raw message