This is straying from the original topic On 23 August 2016 at 21:58, Philippe Mouawad <philippe.moua...@gmail.com> wrote: > Regarding jetty-alpn: > > The ALPN implementation relies on modification of a few OpenJDK classes and > on a few new classes that need to live in the sun.security.ssl package. > These classes are released under the same GPLv2+exception license of > OpenJDK. The ALPN class and its nested classes are released under same > license as the classes of the Jetty project.
Which means it is not suitable for JMeter, because the sun.* classes don't exist in all JVMs. We cannot rely on a particular implementation of Java. > Regards > > On Tue, Aug 23, 2016 at 9:05 PM, Philippe Mouawad < > philippe.moua...@gmail.com> wrote: > >> Hello, >> AFAICR all mentioned dependencies are Apache Licensed: >> - Open SSL >> - netty-tcnative >> >> I opened an issue for the jetty-alpn (which AFAIU is not the most >> performing one): >> https://github.com/jetty-project/jetty-alpn/issues/10 >> >> Regards >> Philippe >> >> On Fri, Aug 19, 2016 at 12:32 PM, sebb <seb...@gmail.com> wrote: >> >>> It looks like Netty has additional requirements for HTTP/2 with TLS >>> >>> http://netty.io/wiki/requirements-for-4.x.html >>> >>> We need to ensure that these additional dependencies are available >>> under a suitable license before considering whether to use it for >>> JMeter. >>> >>> On 19 August 2016 at 10:24, Philippe Mouawad <philippe.moua...@gmail.com> >>> wrote: >>> > For info: >>> > Http2Client : >>> > - http://netty.io/5.0/xref/io/netty/example/http2/client/Http2 >>> Client.html >>> > >>> > Regards >>> > >>> > On Fri, Aug 19, 2016 at 9:45 AM, Philippe Mouawad < >>> > philippe.moua...@gmail.com> wrote: >>> > >>> >> >>> >> >>> >> On Fri, Aug 19, 2016 at 12:19 AM, sebb <seb...@gmail.com> wrote: >>> >> >>> >>> On 18 August 2016 at 22:47, Philippe Mouawad < >>> philippe.moua...@gmail.com> >>> >>> wrote: >>> >>> > Hello, >>> >>> > @sebb, as chief of PMC, could you expose your vision of JMeter's >>> roadmap >>> >>> > and future ? >>> >>> >>> >>> Yes, I am the chair of the PMC, but that is not the same as a chief. >>> >>> The chair is not a technical role, it is purely administrative. >>> >>> As such the chair has the same standing as any other PMC member. >>> >>> >>> >>> == >>> >>> >>> >> It is good to know that >>> >> >>> >> >>> >>> >>> >>> In the short term, I would like to see the HC4 code fixed to remove >>> >>> all the deprecations. >>> >>> >>> >> +1 >>> >> >>> >>> >>> >>> HTTP2 can wait until there is a suitable library. >>> >>> >>> >> >>> >> There is already some, see: >>> >> >>> >> https://github.com/http2/http2-spec/wiki/Implementations >>> >> >>> >> the most famous being netty no ? >>> >> >>> >> >>> >> >>> >>> It would be nice to fix undo/redo, but as I suspected this is going to >>> >>> be really difficult. >>> >>> >>> >> +1 >>> >> >>> >>> >>> >>> As a general rule, we should be cautious about adding code to support >>> >>> infrequent use cases, especially where there is a reasonable >>> >>> alternative. >>> >>> >>> >> >>> >> Ok if it's not a matter of living with broken features just to avoid >>> >> breaking changes. >>> >> It's not because there is a workaround or a complex way to do something >>> >> that we should not try to make it easier. >>> >> >>> >> >>> >>> >>> >>> > Thank you >>> >>> > >>> >>> > On Thursday, July 28, 2016, Philippe Mouawad < >>> >>> philippe.moua...@gmail.com> >>> >>> > wrote: >>> >>> > >>> >>> >> >>> >>> >> >>> >>> >> On Thursday, July 28, 2016, Felix Schumacher <felix.schumacher@ >>> >>> >> internetallee.de >>> >>> >> <javascript:_e(%7B%7D,'cvml','felix.schumac...@internetallee.de >>> ');>> >>> >>> >> wrote: >>> >>> >> >>> >>> >>> Am 27.07.2016 um 14:41 schrieb Philippe Mouawad: >>> >>> >>> >>> >>> >>>> Hello, >>> >>> >>>> I think we should work on a roadmap for JMeter to ensure: >>> >>> >>>> - we prioritize some urgent work on it. >>> >>> >>>> - we give visibility on future of JMeter to users >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> I see the following things from most to less urgent: >>> >>> >>>> >>> >>> >>>> - http2 support. We depend on httpclient for this >>> >>> >>>> >>> >>> >>> +1 but I think it is httpclient or jdk where the work is. >>> >>> >> >>> >>> >> >>> >>> >> Afaik, it's a priority of Httpclient no? >>> >>> >> If not, maybe we should look at other options although my >>> preference >>> >>> >> clearly goes to hc for simplicity and uniformity. >>> >>> >> >>> >>> >> - possible rework of core architecture to at least introduce a >>> pool of >>> >>> >>>> threads or switch to async model allowing us to take advantage of >>> >>> async >>> >>> >>>> io >>> >>> >>>> >>> >>> >>> lot of work (I think really a lot of work), but it is probably a >>> >>> worthy >>> >>> >>> goal for the long run >>> >>> >> >>> >>> >> I think so >>> >>> >> >>> >>> >>> >>> >>> >>> - start a migration to JavaFX , a good opportunity would be to >>> >>> replace the >>> >>> >>>> old browser used for html rendering >>> >>> >>>> >>> >>> >>> replacement of the browser component with javafx is a good thing. >>> >>> >> >>> >>> >> Yes that was my main intention. I don't think it's a big deal. >>> >>> >> >>> >>> >>> >>> >>> >>> Replacement of every thing? I don't know. Will javafx really be >>> the >>> >>> next >>> >>> >>> big java gui? Would it be worth trying to get to a html/http gui >>> and >>> >>> get >>> >>> >>> rid of swing completely? >>> >>> >> >>> >>> >> >>> >>> >> It would be a webapp ? How do you see it ? >>> >>> >> >>> >>> >>> >>> >>> >>> For the near future: >>> >>> >>> >>> >>> >>> * get a bugfix release of 3.0 >>> >>> >> >>> >>> >> I would like to commit an enhancement to generate reports from gui >>> >>> before. >>> >>> >> >>> >>> >> >>> >>> >>> * complete migration to httpclients new api >>> >>> >> >>> >>> >> +1 >>> >>> >> >>> >>> >>> * make recording of jsf sites easier >>> >>> >> >>> >>> >> maybe introduce more generally a Framework correlator where jsf >>> would >>> >>> be 1 >>> >>> >> implementation. >>> >>> >> >>> >>> >> >>> >>> >>> * discuss replacement of logging framework >>> >>> >> >>> >>> >> +1 >>> >>> >> >>> >>> >>> * look at memory consumption of the tree view listener >>> >>> >>> ideas where: >>> >>> >>> - store only the last/first X entries >>> >>> >>> - store only marked entries (might be a header field) >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>> As side features: >>> >>> >>>> - DSL ? >>> >>> >>>> >>> >>> >>> nice idea, but this is a lot of work >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >>> - JSON format instead of XMLfor jmx plans if dsl is too heavy >>> change ? >>> >>> >>>> >>> >>> >>> I think xml has served us well. Every other format has to prove, >>> that >>> >>> it >>> >>> >>> really can compete. >>> >>> >>> >>> >>> >>>> - Fix undo /redo feature >>> >>> >>>> >>> >>> >>> +1 for looking at undo/redo >>> >>> >> >>> >>> >> I would really love to see this one fixed or dropped. >>> >>> >> But I don't want to spend too much energy on it. >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >>> >>> >>> >>> Regards, >>> >>> >>> Felix >>> >>> >>> >>> >>> >>>> - ... >>> >>> >>>> >>> >>> >>>> Ideas welcome >>> >>> >>>> Regards >>> >>> >>>> Philippe M. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>> >>> >>> >> >>> >>> >> -- >>> >>> >> Cordialement. >>> >>> >> Philippe Mouawad. >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> > >>> >>> > -- >>> >>> > Cordialement. >>> >>> > Philippe Mouawad. >>> >>> >>> >> >>> >> >>> >> >>> >> -- >>> >> Cordialement. >>> >> Philippe Mouawad. >>> >> >>> >> >>> >> >>> > >>> > >>> > -- >>> > Cordialement. >>> > Philippe Mouawad. >>> >> >> >> >> -- >> Cordialement. >> Philippe Mouawad. >> >> >> > > > -- > Cordialement. > Philippe Mouawad.
