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 <cziege...@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.jen...@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.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
--
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
--
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
