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