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