Re: [jetty-dev] latest NPN and start.jar

[Greg Wilkins <gregw@xxxxxxxxxxx>]

Simone,

moving this conversation to jetty-dev@eclipse.

On 13 September 2013 02:05, Simone Bordet <sbordet@xxxxxxxxxxx> wrote:

Hi,

see https://github.com/jetty-project/jetty-npn/commit/3bbb2cecab271411b1cddc32b4d4e16087f9a27a#commitcomment-4075344.

This guy was bitten by the same problem Greg had.

If using reflection will make one version of the NPN jar work for older JVMs, then I'm good with that.  Otherwise we just have to come up with a good version mapping approach to get the right NPN jar for the right JVM.

On Thu, Sep 12, 2013 at 10:16 AM, Greg Wilkins <gregw@xxxxxxxxxxx> wrote:
>
> I had a little play with this and I think that the ${java.version} approach
> looks like it will be workable.
>
> However, I don't want to hack support for it into start.jar just yet... it
> needs a bit of rigour as currently we just expand ${jetty.version}.  Should
> we just add ${java.version} or should we do all system properties?  What
> files should be expanded? When?

I was under the impression we are already expanding all the system
properties because we support, for example, jetty.port to be
overridden on the command line.
It is not the case ?

Currently Properties like jetty.port are expanded by <Property .../> elements in the XML, but they are not expanded by default in module and ini files and other command line arguments, with the one exception that we expand ${jetty.version} when processing libraries from modules.

I think we should change so that ${name} expands to any System property on any command line or ini file argument.   This will allow us to use ${java.version} in selecting NPN jars etc.

> So I'm going to build 9.1.M0 now with what we have - we have to get it out
> there.  We can clean this up in an RC.
>
> so starting the build now.

The major problem I see is the lack of metadata support to map NPN
versions to JDK versions.
This metadata needs to be updated for every JDK.
Either we ship a new version of Jetty every time a JDK ships a new
release, or we need to maintain it in a shared place that Jettys
installed all over the world can look up (Maven Central, or something
like eclipse.org/jetty/npn.txt).
We can't put the metadata inside the NPN jar because otherwise we need
to release a new NPN jar version for every JDK (not a big deal
though).

Well an NPN jar can know about current JVMs and past JVMs.     If it sees a more recent JVM it could just give a warning.      The main thing is to at least give some output that the versions might not be right so that any subsequent strange exceptions are more understandable.  The current NoSuchMethod exception is not really sufficient.

This is going to be a pain until it is supported by the JVMs

A con of this approach is that for every JDK version we need to
release a new Jetty version, to put the additional NPN jar in the
lib/npn directory, or to update the agent to use an existing NPN
version for the new JDK.

That is a big con.      I much prefer just releasing a new NPN jar whenever the JVM impl changes.

 

Currently, this metadata is in the Jetty documentation
(http://www.eclipse.org/jetty/documentation/current/npn-chapter.html#npn-versions),
so humans have to look it up and do something.

For now I have put this meta data in the comments of the npn ini template, so at least it is at hand.  Should probably also put a link to this page in there.  A bit manual, but at least it is info.

 

All in all, perhaps having a download with an expanded ${java.version}
is the simpler solution: allows us to release NPN independently from
Jetty, and repackagers would not have problems. But this will only
work for 9.1 onwards.

I too think this is best.   It is not perfect but reasonable.

 

--
Greg Wilkins <gregw@xxxxxxxxxxx>
http://www.webtide.com
Developer advice and support from the Jetty & CometD experts.
Intalio, the modern way to build business applications.