Re: http/2

2016-08-02 Thread Tobias Soloschenko



Am 29.06.16 um 17:43 schrieb Martin Grigorov:

On Tue, Jun 28, 2016 at 11:02 PM, Tobias Soloschenko <
tobiassolosche...@googlemail.com> wrote:


Hi,

I just saw this old topic and want to give some information about HTTP/2
and Wicket.

First of all Wicket will have support for http/2 via PushBuilder API - A
PoC can be found here:

https://github.com/klopfdreh/jetty-http2-example

So before the actual page request is finished you can push several
resources to the client via header item.

The item itself is also compatible with http<2 because resources aren't
pushed to the client at all in this case.

There are some hints in the implementation that the client is going to
have the option to activate / deactivate the push functionality.

If a client has cached the resource already a RST_STREAM is send to the
server to skip the next pushed resource so that there is no high traffic at
all.

@stackoverflow I asked a question regarding the client side caching in
Jetty and a core dev already answered:


http://stackoverflow.com/questions/37211883/jetty-respond-with-status-200-instead-of-304-while-using-http2

I am waiting for further hints at this point.


There is no answer since May 20th.
I'd file an issue at Jetty bug tracker.
Ticket is now available here: 
https://github.com/eclipse/jetty.project/issues/801



If the JEE server supports HTTP/2 I think you are going to be able to ship
files within the WEB-INF with push, too (this is only an assumption)

Hope the dev regarding the JEE standard is continued soon.

kind regards

Tobias


Am 02.03.2016 um 19:43 schrieb Lars Törner <lars.tor...@gmail.com>:

Ok, thanks!

I hope to find the time to test it in the near future. :-)


2016-03-02 17:30 GMT+01:00 Martin Grigorov <mgrigo...@apache.org>:


That's correct!

Honestly I haven't checked the network traffic to verify that all or at
least several resources are served in the same connection but I have
verified that both Google Chrome and Firefox report that the site is

HTTP/2

enabled.

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov


On Wed, Mar 2, 2016 at 5:16 PM, Lars Törner <lars.tor...@gmail.com>

wrote:

Hi Martin,

that sounds interesting!

So what you´re saying is that if the server where the

wicket-applictation

is deployed supports http/2 then wicket itself doesn't need any
wicket-specific-extension to work. And that, for example, all

components

css/javascript-resources of a page will be fetched over one multiplexed
connection.

Cheers
Lasse



2016-03-02 16:40 GMT+01:00 Martin Grigorov <mgrigo...@apache.org>:


Hi Lasse,

I have successfully tested a Wicket application (my WebSockets demo

app)

on

Tomcat 9.0.0.M1/M2/M3 (
https://twitter.com/mtgrigorov/status/665916977957982208) with

HTTP/2.

Currently there is a discussion at Tomcat dev@ mailing list about

porting

back the changes to Tomcat 8.5.0. 8.5 will be what 9.0 is now without

the

Servlet 4.x APIs because Servlet 4.x release date is far in the

future.

I have also was able to run Wicket app with Jetty SPDY impl in the

past.

I haven't tested with WildFly 10 but I don't expect any problems from
Wicket side.
Please let us know if you face any issues and we will investigate

them!

Thanks!


Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov


On Wed, Mar 2, 2016 at 4:31 PM, Lars Törner <lars.tor...@gmail.com>

wrote:


Hi,

I have some (naive?) questions:

- Isn't it time to think about wicket and http/2?
- Must we wait for javaee8/servlet 4.0 and then wait for a new

version

of

wicket that supports it?
- Is it possible to implement an extension to support http/2 in

wicket?

- Is it a huge effort to make this happen?

I think (most of?) the latest versions of the major browsers support
http/2, Wildfly supports http/2 server side with undertow... etc.
Known implementations of HTTP/2:
https://github.com/http2/http2-spec/wiki/Implementations

I have read Martin G:s comment from a year back about this (see

below),

but

not found anything else... maybe there already is an ongoing

discussion

about this?

Cheers
Lasse

Martins reflections about http/2 and servlet 4.0
I'm afraid it is too early for this. We can make sure Wicket works

fine

in

a container supporting those but it is too early to require that.

Servlet

4.0 is still in design process. Apache Tomcat didn't started

implementing

any features from it. I am not sure about the status in Jetty. I know

that

Undertow (the web container for JBoss Wildfly) supports HTTP 2.0 but

I

haven't heard of any Servlet 4.0 features. It will take us some time

to

release 8.0.0 but I think it will be too
early to require Servlet 4.0 even then.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org





-

Re: http/2

2016-08-02 Thread Tobias Soloschenko

Hi Martin,

Am 29.06.16 um 17:43 schrieb Martin Grigorov:

On Tue, Jun 28, 2016 at 11:02 PM, Tobias Soloschenko <
tobiassolosche...@googlemail.com> wrote:


Hi,

I just saw this old topic and want to give some information about HTTP/2
and Wicket.

First of all Wicket will have support for http/2 via PushBuilder API - A
PoC can be found here:

https://github.com/klopfdreh/jetty-http2-example

So before the actual page request is finished you can push several
resources to the client via header item.

The item itself is also compatible with http<2 because resources aren't
pushed to the client at all in this case.

There are some hints in the implementation that the client is going to
have the option to activate / deactivate the push functionality.

If a client has cached the resource already a RST_STREAM is send to the
server to skip the next pushed resource so that there is no high traffic at
all.

@stackoverflow I asked a question regarding the client side caching in
Jetty and a core dev already answered:


http://stackoverflow.com/questions/37211883/jetty-respond-with-status-200-instead-of-304-while-using-http2

I am waiting for further hints at this point.


There is no answer since May 20th.
I'd file an issue at Jetty bug tracker.

I tried to file in a bug at:

https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Jetty

but:

"Sorry, entering a bug into the product Jetty has been disabled."

...



If the JEE server supports HTTP/2 I think you are going to be able to ship
files within the WEB-INF with push, too (this is only an assumption)

Hope the dev regarding the JEE standard is continued soon.

kind regards

Tobias


Am 02.03.2016 um 19:43 schrieb Lars Törner <lars.tor...@gmail.com>:

Ok, thanks!

I hope to find the time to test it in the near future. :-)


2016-03-02 17:30 GMT+01:00 Martin Grigorov <mgrigo...@apache.org>:


That's correct!

Honestly I haven't checked the network traffic to verify that all or at
least several resources are served in the same connection but I have
verified that both Google Chrome and Firefox report that the site is

HTTP/2

enabled.

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov


On Wed, Mar 2, 2016 at 5:16 PM, Lars Törner <lars.tor...@gmail.com>

wrote:

Hi Martin,

that sounds interesting!

So what you´re saying is that if the server where the

wicket-applictation

is deployed supports http/2 then wicket itself doesn't need any
wicket-specific-extension to work. And that, for example, all

components

css/javascript-resources of a page will be fetched over one multiplexed
connection.

Cheers
Lasse



2016-03-02 16:40 GMT+01:00 Martin Grigorov <mgrigo...@apache.org>:


Hi Lasse,

I have successfully tested a Wicket application (my WebSockets demo

app)

on

Tomcat 9.0.0.M1/M2/M3 (
https://twitter.com/mtgrigorov/status/665916977957982208) with

HTTP/2.

Currently there is a discussion at Tomcat dev@ mailing list about

porting

back the changes to Tomcat 8.5.0. 8.5 will be what 9.0 is now without

the

Servlet 4.x APIs because Servlet 4.x release date is far in the

future.

I have also was able to run Wicket app with Jetty SPDY impl in the

past.

I haven't tested with WildFly 10 but I don't expect any problems from
Wicket side.
Please let us know if you face any issues and we will investigate

them!

Thanks!


Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov


On Wed, Mar 2, 2016 at 4:31 PM, Lars Törner <lars.tor...@gmail.com>

wrote:


Hi,

I have some (naive?) questions:

- Isn't it time to think about wicket and http/2?
- Must we wait for javaee8/servlet 4.0 and then wait for a new

version

of

wicket that supports it?
- Is it possible to implement an extension to support http/2 in

wicket?

- Is it a huge effort to make this happen?

I think (most of?) the latest versions of the major browsers support
http/2, Wildfly supports http/2 server side with undertow... etc.
Known implementations of HTTP/2:
https://github.com/http2/http2-spec/wiki/Implementations

I have read Martin G:s comment from a year back about this (see

below),

but

not found anything else... maybe there already is an ongoing

discussion

about this?

Cheers
Lasse

Martins reflections about http/2 and servlet 4.0
I'm afraid it is too early for this. We can make sure Wicket works

fine

in

a container supporting those but it is too early to require that.

Servlet

4.0 is still in design process. Apache Tomcat didn't started

implementing

any features from it. I am not sure about the status in Jetty. I know

that

Undertow (the web container for JBoss Wildfly) supports HTTP 2.0 but

I

haven't heard of any Servlet 4.0 features. It will take us some time

to

release 8.0.0 but I think it will be too
early to require Servlet 4.0 even then.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.ap

Re: http/2

2016-06-29 Thread Tobias Soloschenko
When I find some time I am going to file in a ticket.

kind regards

Tobias

> Am 29.06.2016 um 17:43 schrieb Martin Grigorov <mgrigo...@apache.org>:
> 
> On Tue, Jun 28, 2016 at 11:02 PM, Tobias Soloschenko <
> tobiassolosche...@googlemail.com> wrote:
> 
>> Hi,
>> 
>> I just saw this old topic and want to give some information about HTTP/2
>> and Wicket.
>> 
>> First of all Wicket will have support for http/2 via PushBuilder API - A
>> PoC can be found here:
>> 
>> https://github.com/klopfdreh/jetty-http2-example
>> 
>> So before the actual page request is finished you can push several
>> resources to the client via header item.
>> 
>> The item itself is also compatible with http<2 because resources aren't
>> pushed to the client at all in this case.
>> 
>> There are some hints in the implementation that the client is going to
>> have the option to activate / deactivate the push functionality.
>> 
>> If a client has cached the resource already a RST_STREAM is send to the
>> server to skip the next pushed resource so that there is no high traffic at
>> all.
>> 
>> @stackoverflow I asked a question regarding the client side caching in
>> Jetty and a core dev already answered:
>> 
>> 
>> http://stackoverflow.com/questions/37211883/jetty-respond-with-status-200-instead-of-304-while-using-http2
>> 
>> I am waiting for further hints at this point.
> 
> There is no answer since May 20th.
> I'd file an issue at Jetty bug tracker.
> 
> 
>> 
>> If the JEE server supports HTTP/2 I think you are going to be able to ship
>> files within the WEB-INF with push, too (this is only an assumption)
>> 
>> Hope the dev regarding the JEE standard is continued soon.
>> 
>> kind regards
>> 
>> Tobias
>> 
>>> Am 02.03.2016 um 19:43 schrieb Lars Törner <lars.tor...@gmail.com>:
>>> 
>>> Ok, thanks!
>>> 
>>> I hope to find the time to test it in the near future. :-)
>>> 
>>> 
>>> 2016-03-02 17:30 GMT+01:00 Martin Grigorov <mgrigo...@apache.org>:
>>> 
>>>> That's correct!
>>>> 
>>>> Honestly I haven't checked the network traffic to verify that all or at
>>>> least several resources are served in the same connection but I have
>>>> verified that both Google Chrome and Firefox report that the site is
>> HTTP/2
>>>> enabled.
>>>> 
>>>> Martin Grigorov
>>>> Wicket Training and Consulting
>>>> https://twitter.com/mtgrigorov
>>>> 
>>>>> On Wed, Mar 2, 2016 at 5:16 PM, Lars Törner <lars.tor...@gmail.com>
>> wrote:
>>>>> 
>>>>> Hi Martin,
>>>>> 
>>>>> that sounds interesting!
>>>>> 
>>>>> So what you´re saying is that if the server where the
>> wicket-applictation
>>>>> is deployed supports http/2 then wicket itself doesn't need any
>>>>> wicket-specific-extension to work. And that, for example, all
>> components
>>>>> css/javascript-resources of a page will be fetched over one multiplexed
>>>>> connection.
>>>>> 
>>>>> Cheers
>>>>> Lasse
>>>>> 
>>>>> 
>>>>> 
>>>>> 2016-03-02 16:40 GMT+01:00 Martin Grigorov <mgrigo...@apache.org>:
>>>>> 
>>>>>> Hi Lasse,
>>>>>> 
>>>>>> I have successfully tested a Wicket application (my WebSockets demo
>>>> app)
>>>>> on
>>>>>> Tomcat 9.0.0.M1/M2/M3 (
>>>>>> https://twitter.com/mtgrigorov/status/665916977957982208) with
>> HTTP/2.
>>>>>> Currently there is a discussion at Tomcat dev@ mailing list about
>>>>> porting
>>>>>> back the changes to Tomcat 8.5.0. 8.5 will be what 9.0 is now without
>>>> the
>>>>>> Servlet 4.x APIs because Servlet 4.x release date is far in the
>> future.
>>>>>> 
>>>>>> I have also was able to run Wicket app with Jetty SPDY impl in the
>>>> past.
>>>>>> 
>>>>>> I haven't tested with WildFly 10 but I don't expect any problems from
>>>>>> Wicket side.
>>>>>> Please let us know if you face any issues and we will investigate
>> them!
>>>>>> 
>>>>>> Thanks!
>>>>>> 
>>>>>&

Re: http/2

2016-06-29 Thread Martin Grigorov
On Tue, Jun 28, 2016 at 11:02 PM, Tobias Soloschenko <
tobiassolosche...@googlemail.com> wrote:

> Hi,
>
> I just saw this old topic and want to give some information about HTTP/2
> and Wicket.
>
> First of all Wicket will have support for http/2 via PushBuilder API - A
> PoC can be found here:
>
> https://github.com/klopfdreh/jetty-http2-example
>
> So before the actual page request is finished you can push several
> resources to the client via header item.
>
> The item itself is also compatible with http<2 because resources aren't
> pushed to the client at all in this case.
>
> There are some hints in the implementation that the client is going to
> have the option to activate / deactivate the push functionality.
>
> If a client has cached the resource already a RST_STREAM is send to the
> server to skip the next pushed resource so that there is no high traffic at
> all.
>
> @stackoverflow I asked a question regarding the client side caching in
> Jetty and a core dev already answered:
>
>
> http://stackoverflow.com/questions/37211883/jetty-respond-with-status-200-instead-of-304-while-using-http2
>
> I am waiting for further hints at this point.
>

There is no answer since May 20th.
I'd file an issue at Jetty bug tracker.


>
> If the JEE server supports HTTP/2 I think you are going to be able to ship
> files within the WEB-INF with push, too (this is only an assumption)
>
> Hope the dev regarding the JEE standard is continued soon.
>
> kind regards
>
> Tobias
>
> > Am 02.03.2016 um 19:43 schrieb Lars Törner <lars.tor...@gmail.com>:
> >
> > Ok, thanks!
> >
> > I hope to find the time to test it in the near future. :-)
> >
> >
> > 2016-03-02 17:30 GMT+01:00 Martin Grigorov <mgrigo...@apache.org>:
> >
> >> That's correct!
> >>
> >> Honestly I haven't checked the network traffic to verify that all or at
> >> least several resources are served in the same connection but I have
> >> verified that both Google Chrome and Firefox report that the site is
> HTTP/2
> >> enabled.
> >>
> >> Martin Grigorov
> >> Wicket Training and Consulting
> >> https://twitter.com/mtgrigorov
> >>
> >>> On Wed, Mar 2, 2016 at 5:16 PM, Lars Törner <lars.tor...@gmail.com>
> wrote:
> >>>
> >>> Hi Martin,
> >>>
> >>> that sounds interesting!
> >>>
> >>> So what you´re saying is that if the server where the
> wicket-applictation
> >>> is deployed supports http/2 then wicket itself doesn't need any
> >>> wicket-specific-extension to work. And that, for example, all
> components
> >>> css/javascript-resources of a page will be fetched over one multiplexed
> >>> connection.
> >>>
> >>> Cheers
> >>> Lasse
> >>>
> >>>
> >>>
> >>> 2016-03-02 16:40 GMT+01:00 Martin Grigorov <mgrigo...@apache.org>:
> >>>
> >>>> Hi Lasse,
> >>>>
> >>>> I have successfully tested a Wicket application (my WebSockets demo
> >> app)
> >>> on
> >>>> Tomcat 9.0.0.M1/M2/M3 (
> >>>> https://twitter.com/mtgrigorov/status/665916977957982208) with
> HTTP/2.
> >>>> Currently there is a discussion at Tomcat dev@ mailing list about
> >>> porting
> >>>> back the changes to Tomcat 8.5.0. 8.5 will be what 9.0 is now without
> >> the
> >>>> Servlet 4.x APIs because Servlet 4.x release date is far in the
> future.
> >>>>
> >>>> I have also was able to run Wicket app with Jetty SPDY impl in the
> >> past.
> >>>>
> >>>> I haven't tested with WildFly 10 but I don't expect any problems from
> >>>> Wicket side.
> >>>> Please let us know if you face any issues and we will investigate
> them!
> >>>>
> >>>> Thanks!
> >>>>
> >>>>
> >>>> Martin Grigorov
> >>>> Wicket Training and Consulting
> >>>> https://twitter.com/mtgrigorov
> >>>>
> >>>>> On Wed, Mar 2, 2016 at 4:31 PM, Lars Törner <lars.tor...@gmail.com>
> >>>> wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> I have some (naive?) questions:
> >>>>>
> >>>>> - Isn't it time to think about wicket and http/2?
> >>>>> - Must we wait for javaee8/servlet 4.0 and then wai

Re: http/2

2016-06-28 Thread Tobias Soloschenko
Hi,

I just saw this old topic and want to give some information about HTTP/2 and 
Wicket.

First of all Wicket will have support for http/2 via PushBuilder API - A PoC 
can be found here:

https://github.com/klopfdreh/jetty-http2-example

So before the actual page request is finished you can push several resources to 
the client via header item.

The item itself is also compatible with http<2 because resources aren't pushed 
to the client at all in this case.

There are some hints in the implementation that the client is going to have the 
option to activate / deactivate the push functionality.

If a client has cached the resource already a RST_STREAM is send to the server 
to skip the next pushed resource so that there is no high traffic at all.

@stackoverflow I asked a question regarding the client side caching in Jetty 
and a core dev already answered:

http://stackoverflow.com/questions/37211883/jetty-respond-with-status-200-instead-of-304-while-using-http2

I am waiting for further hints at this point.

If the JEE server supports HTTP/2 I think you are going to be able to ship 
files within the WEB-INF with push, too (this is only an assumption)

Hope the dev regarding the JEE standard is continued soon.

kind regards

Tobias

> Am 02.03.2016 um 19:43 schrieb Lars Törner <lars.tor...@gmail.com>:
> 
> Ok, thanks!
> 
> I hope to find the time to test it in the near future. :-)
> 
> 
> 2016-03-02 17:30 GMT+01:00 Martin Grigorov <mgrigo...@apache.org>:
> 
>> That's correct!
>> 
>> Honestly I haven't checked the network traffic to verify that all or at
>> least several resources are served in the same connection but I have
>> verified that both Google Chrome and Firefox report that the site is HTTP/2
>> enabled.
>> 
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>> 
>>> On Wed, Mar 2, 2016 at 5:16 PM, Lars Törner <lars.tor...@gmail.com> wrote:
>>> 
>>> Hi Martin,
>>> 
>>> that sounds interesting!
>>> 
>>> So what you´re saying is that if the server where the wicket-applictation
>>> is deployed supports http/2 then wicket itself doesn't need any
>>> wicket-specific-extension to work. And that, for example, all components
>>> css/javascript-resources of a page will be fetched over one multiplexed
>>> connection.
>>> 
>>> Cheers
>>> Lasse
>>> 
>>> 
>>> 
>>> 2016-03-02 16:40 GMT+01:00 Martin Grigorov <mgrigo...@apache.org>:
>>> 
>>>> Hi Lasse,
>>>> 
>>>> I have successfully tested a Wicket application (my WebSockets demo
>> app)
>>> on
>>>> Tomcat 9.0.0.M1/M2/M3 (
>>>> https://twitter.com/mtgrigorov/status/665916977957982208) with HTTP/2.
>>>> Currently there is a discussion at Tomcat dev@ mailing list about
>>> porting
>>>> back the changes to Tomcat 8.5.0. 8.5 will be what 9.0 is now without
>> the
>>>> Servlet 4.x APIs because Servlet 4.x release date is far in the future.
>>>> 
>>>> I have also was able to run Wicket app with Jetty SPDY impl in the
>> past.
>>>> 
>>>> I haven't tested with WildFly 10 but I don't expect any problems from
>>>> Wicket side.
>>>> Please let us know if you face any issues and we will investigate them!
>>>> 
>>>> Thanks!
>>>> 
>>>> 
>>>> Martin Grigorov
>>>> Wicket Training and Consulting
>>>> https://twitter.com/mtgrigorov
>>>> 
>>>>> On Wed, Mar 2, 2016 at 4:31 PM, Lars Törner <lars.tor...@gmail.com>
>>>> wrote:
>>>> 
>>>>> Hi,
>>>>> 
>>>>> I have some (naive?) questions:
>>>>> 
>>>>> - Isn't it time to think about wicket and http/2?
>>>>> - Must we wait for javaee8/servlet 4.0 and then wait for a new
>> version
>>> of
>>>>> wicket that supports it?
>>>>> - Is it possible to implement an extension to support http/2 in
>> wicket?
>>>>> - Is it a huge effort to make this happen?
>>>>> 
>>>>> I think (most of?) the latest versions of the major browsers support
>>>>> http/2, Wildfly supports http/2 server side with undertow... etc.
>>>>> Known implementations of HTTP/2:
>>>>> https://github.com/http2/http2-spec/wiki/Implementations
>>>>> 
>>>>> I have read Martin G:s comment from a year back about this (see
>> below),
>>>> 

Re: Setup Tomcat 9.0.0-M4 with http/2 on Mac OS X 10.11.4

2016-04-04 Thread Martin Grigorov
Hi Tobias,

I use 8.5.1-SNAPSHOT for my experiments. 8.5.0 has a known bug (
https://bz.apache.org/bugzilla/show_bug.cgi?id=59210).

This is the important stuff in conf/server.conf:




**





This is all I do to use HTTP2 with NIO2 impl + OpenSSL (i.e. not JSSE).


Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Sat, Apr 2, 2016 at 9:37 AM, Tobias Soloschenko <
tobiassolosche...@googlemail.com> wrote:

> Hi,
>
> I am trying to get http/2 working on Mac OS X 10.11.4 - these are the
> steps I used:
>
> 1. Install Brew: http://brew.sh/
>
> 2. Download Apache Tomcat 9 https://tomcat.apache.org/download-90.cgi
>
> 3. Download Xcode command line tools by opening the terminal and execute
> “xcode-select  —install”
>
> 4. Download Xcode from the AppStore
>
> 5. Create a symlink for the xctoolchain:
>
> sudo ln -s
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain
> /Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.11.xctoolchain
>
> 6. Install APR and OPENSSL with “brew install openssl” and “brew install
> apr”
>
> 7. Install tomcat native by extracting bin/tomcat-native.tar.gz and run
> “./configure --with-ssl=/usr/local/Cellar/openssl/1.0.2g
> --prefix=/Applications/apache-tomcat-9.0.0.M4
> --with-apr=/usr/local/Cellar/apr/1.5.2 && make && make install” in
> tomcat-native-1.2.5-src/native - see
>
> https://tomcat.apache.org/tomcat-9.0-doc/apr.html
>
> 8. export JAVA_OPTS=-Djava.library.path=/usr/local/apr/lib
>
> 9. Create pem files in conf folder:
>
> /usr/local/Cellar/openssl/1.0.2g/bin/openssl genrsa -des3 -out
> localhost-rsa-key 1024
>
> /usr/local/Cellar/openssl/1.0.2g/bin/openssl genrsa -out localhost-key 1024
>
> /usr/local/Cellar/openssl/1.0.2g/bin/openssl rsa -in localhost-rsa-key
> -out localhost-key
>
> /usr/local/Cellar/openssl/1.0.2g/bin/openssl req -new -key localhost-key
> -out localhost-csr
>
> /usr/local/Cellar/openssl/1.0.2g/bin/openssl x509 -req -days 365 -in
> localhost-csr -signkey localhost-key -out localhost-crt
>
> cat localhost-key localhost-crt > localhost-rsa-cert.pem
>
> cat localhost-rsa-cert.pem > localhost-rsa-chain.pem
>
> cat localhost-rsa-key > localhost-rsa-key.pem
>
> 10. Uncomment the http/2 connector in the server.xml
>
>
> I am currently facing those issues (out of the log):
>
>
> 02-Apr-2016 09:15:13.415 INFO [main]
> org.apache.catalina.startup.VersionLoggerListener.log Command line
> argument: -Djava.io.tmpdir=/Applications/apache-tomcat-9.0.0.M4/temp
>
> 02-Apr-2016 09:15:13.415 INFO [main]
> org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded APR
> based Apache Tomcat Native library 1.2.5 using APR version 1.4.8.
>
> 02-Apr-2016 09:15:13.415 INFO [main]
> org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR
> capabilities: IPv6 [true], sendfile [true], accept filters [false], random
> [true].
>
> 02-Apr-2016 09:15:13.418 SEVERE [main]
> org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Failed to
> initialize the SSLEngine.
>
>  org.apache.tomcat.jni.Error: 70023: This function has not been
> implemented on this platform
>
> at org.apache.tomcat.jni.SSL.initialize(Native Method)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>
> at java.lang.reflect.Method.invoke(Method.java:497)
>
> at
> org.apache.catalina.core.AprLifecycleListener.initializeSSL(AprLifecycleListener.java:284)
>
> at
> org.apache.catalina.core.AprLifecycleListener.lifecycleEvent(AprLifecycleListener.java:136)
>
> at
> org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:94)
>
> at
> org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:401)
>
> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:104)
>
> at org.apache.catalina.startup.Catalina.load(Catalina.java:606)
>
> at org.apache.catalina.startup.Catalina.load(Catalina.java:629)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>
> at java.lang.reflect.Method.invoke(Method.java:497)
>
> at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:311)
>
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:494)
>
>
> 02-Apr-2016 09:15:1

Setup Tomcat 9.0.0-M4 with http/2 on Mac OS X 10.11.4

2016-04-02 Thread Tobias Soloschenko
Hi,

I am trying to get http/2 working on Mac OS X 10.11.4 - these are the steps
I used:

1. Install Brew: http://brew.sh/

2. Download Apache Tomcat 9 https://tomcat.apache.org/download-90.cgi

3. Download Xcode command line tools by opening the terminal and execute
“xcode-select  —install”

4. Download Xcode from the AppStore

5. Create a symlink for the xctoolchain:

sudo ln -s
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain
/Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.11.xctoolchain

6. Install APR and OPENSSL with “brew install openssl” and “brew install
apr”

7. Install tomcat native by extracting bin/tomcat-native.tar.gz and run
“./configure --with-ssl=/usr/local/Cellar/openssl/1.0.2g
--prefix=/Applications/apache-tomcat-9.0.0.M4
--with-apr=/usr/local/Cellar/apr/1.5.2 && make && make install” in
tomcat-native-1.2.5-src/native - see

https://tomcat.apache.org/tomcat-9.0-doc/apr.html

8. export JAVA_OPTS=-Djava.library.path=/usr/local/apr/lib

9. Create pem files in conf folder:

/usr/local/Cellar/openssl/1.0.2g/bin/openssl genrsa -des3 -out
localhost-rsa-key 1024

/usr/local/Cellar/openssl/1.0.2g/bin/openssl genrsa -out localhost-key 1024

/usr/local/Cellar/openssl/1.0.2g/bin/openssl rsa -in localhost-rsa-key -out
localhost-key

/usr/local/Cellar/openssl/1.0.2g/bin/openssl req -new -key localhost-key
-out localhost-csr

/usr/local/Cellar/openssl/1.0.2g/bin/openssl x509 -req -days 365 -in
localhost-csr -signkey localhost-key -out localhost-crt

cat localhost-key localhost-crt > localhost-rsa-cert.pem

cat localhost-rsa-cert.pem > localhost-rsa-chain.pem

cat localhost-rsa-key > localhost-rsa-key.pem

10. Uncomment the http/2 connector in the server.xml


I am currently facing those issues (out of the log):


02-Apr-2016 09:15:13.415 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Command line
argument: -Djava.io.tmpdir=/Applications/apache-tomcat-9.0.0.M4/temp

02-Apr-2016 09:15:13.415 INFO [main]
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded APR
based Apache Tomcat Native library 1.2.5 using APR version 1.4.8.

02-Apr-2016 09:15:13.415 INFO [main]
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR
capabilities: IPv6 [true], sendfile [true], accept filters [false], random
[true].

02-Apr-2016 09:15:13.418 SEVERE [main]
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Failed to
initialize the SSLEngine.

 org.apache.tomcat.jni.Error: 70023: This function has not been implemented
on this platform

at org.apache.tomcat.jni.SSL.initialize(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:497)

at
org.apache.catalina.core.AprLifecycleListener.initializeSSL(AprLifecycleListener.java:284)

at
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent(AprLifecycleListener.java:136)

at
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:94)

at
org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:401)

at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:104)

at org.apache.catalina.startup.Catalina.load(Catalina.java:606)

at org.apache.catalina.startup.Catalina.load(Catalina.java:629)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:497)

at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:311)

at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:494)


02-Apr-2016 09:15:13.655 INFO [main]
org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler
["http-nio-8080"]

02-Apr-2016 09:15:13.683 INFO [main]
org.apache.tomcat.util.net.NioSelectorPool.getSharedSelector Using a shared
selector for servlet write/read

02-Apr-2016 09:15:13.686 INFO [main]
org.apache.coyote.http11.AbstractHttp11Protocol.configureUpgradeProtocol
The ["https-apr-8443"] connector has been configured to support negotiation
to [h2] via ALPN

02-Apr-2016 09:15:13.686 INFO [main]
org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler
["https-apr-8443"]

02-Apr-2016 09:15:13.706 WARNING [main]
org.apache.tomcat.util.net.openssl.OpenSSLEngine. Failed getting
cipher list

 java.lang.Exception: Not implemented

at org.apache.tomcat.jni.SSL.newSSL(Native Method)

at
org.apache.tomcat.util.net.openssl.OpenSSLEngine.(OpenSSLEngine.java:81)

at org.apache.tomcat.util.net.AprEndpoint.bind(AprEndpoint.java:363)

at
org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:798)

at org.apache

Re: http/2

2016-03-02 Thread Lars Törner
Ok, thanks!

I hope to find the time to test it in the near future. :-)


2016-03-02 17:30 GMT+01:00 Martin Grigorov <mgrigo...@apache.org>:

> That's correct!
>
> Honestly I haven't checked the network traffic to verify that all or at
> least several resources are served in the same connection but I have
> verified that both Google Chrome and Firefox report that the site is HTTP/2
> enabled.
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Wed, Mar 2, 2016 at 5:16 PM, Lars Törner <lars.tor...@gmail.com> wrote:
>
> > Hi Martin,
> >
> > that sounds interesting!
> >
> > So what you´re saying is that if the server where the wicket-applictation
> > is deployed supports http/2 then wicket itself doesn't need any
> > wicket-specific-extension to work. And that, for example, all components
> > css/javascript-resources of a page will be fetched over one multiplexed
> > connection.
> >
> > Cheers
> > Lasse
> >
> >
> >
> > 2016-03-02 16:40 GMT+01:00 Martin Grigorov <mgrigo...@apache.org>:
> >
> > > Hi Lasse,
> > >
> > > I have successfully tested a Wicket application (my WebSockets demo
> app)
> > on
> > > Tomcat 9.0.0.M1/M2/M3 (
> > > https://twitter.com/mtgrigorov/status/665916977957982208) with HTTP/2.
> > > Currently there is a discussion at Tomcat dev@ mailing list about
> > porting
> > > back the changes to Tomcat 8.5.0. 8.5 will be what 9.0 is now without
> the
> > > Servlet 4.x APIs because Servlet 4.x release date is far in the future.
> > >
> > > I have also was able to run Wicket app with Jetty SPDY impl in the
> past.
> > >
> > > I haven't tested with WildFly 10 but I don't expect any problems from
> > > Wicket side.
> > > Please let us know if you face any issues and we will investigate them!
> > >
> > > Thanks!
> > >
> > >
> > > Martin Grigorov
> > > Wicket Training and Consulting
> > > https://twitter.com/mtgrigorov
> > >
> > > On Wed, Mar 2, 2016 at 4:31 PM, Lars Törner <lars.tor...@gmail.com>
> > wrote:
> > >
> > > > Hi,
> > > >
> > > > I have some (naive?) questions:
> > > >
> > > > - Isn't it time to think about wicket and http/2?
> > > > - Must we wait for javaee8/servlet 4.0 and then wait for a new
> version
> > of
> > > > wicket that supports it?
> > > > - Is it possible to implement an extension to support http/2 in
> wicket?
> > > > - Is it a huge effort to make this happen?
> > > >
> > > > I think (most of?) the latest versions of the major browsers support
> > > > http/2, Wildfly supports http/2 server side with undertow... etc.
> > > > Known implementations of HTTP/2:
> > > > https://github.com/http2/http2-spec/wiki/Implementations
> > > >
> > > > I have read Martin G:s comment from a year back about this (see
> below),
> > > but
> > > > not found anything else... maybe there already is an ongoing
> discussion
> > > > about this?
> > > >
> > > > Cheers
> > > > Lasse
> > > >
> > > > Martins reflections about http/2 and servlet 4.0
> > > > I'm afraid it is too early for this. We can make sure Wicket works
> fine
> > > in
> > > > a container supporting those but it is too early to require that.
> > Servlet
> > > > 4.0 is still in design process. Apache Tomcat didn't started
> > implementing
> > > > any features from it. I am not sure about the status in Jetty. I know
> > > that
> > > > Undertow (the web container for JBoss Wildfly) supports HTTP 2.0 but
> I
> > > > haven't heard of any Servlet 4.0 features. It will take us some time
> to
> > > > release 8.0.0 but I think it will be too
> > > > early to require Servlet 4.0 even then.
> > > >
> > >
> >
>


Re: http/2

2016-03-02 Thread Martin Grigorov
That's correct!

Honestly I haven't checked the network traffic to verify that all or at
least several resources are served in the same connection but I have
verified that both Google Chrome and Firefox report that the site is HTTP/2
enabled.

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Wed, Mar 2, 2016 at 5:16 PM, Lars Törner <lars.tor...@gmail.com> wrote:

> Hi Martin,
>
> that sounds interesting!
>
> So what you´re saying is that if the server where the wicket-applictation
> is deployed supports http/2 then wicket itself doesn't need any
> wicket-specific-extension to work. And that, for example, all components
> css/javascript-resources of a page will be fetched over one multiplexed
> connection.
>
> Cheers
> Lasse
>
>
>
> 2016-03-02 16:40 GMT+01:00 Martin Grigorov <mgrigo...@apache.org>:
>
> > Hi Lasse,
> >
> > I have successfully tested a Wicket application (my WebSockets demo app)
> on
> > Tomcat 9.0.0.M1/M2/M3 (
> > https://twitter.com/mtgrigorov/status/665916977957982208) with HTTP/2.
> > Currently there is a discussion at Tomcat dev@ mailing list about
> porting
> > back the changes to Tomcat 8.5.0. 8.5 will be what 9.0 is now without the
> > Servlet 4.x APIs because Servlet 4.x release date is far in the future.
> >
> > I have also was able to run Wicket app with Jetty SPDY impl in the past.
> >
> > I haven't tested with WildFly 10 but I don't expect any problems from
> > Wicket side.
> > Please let us know if you face any issues and we will investigate them!
> >
> > Thanks!
> >
> >
> > Martin Grigorov
> > Wicket Training and Consulting
> > https://twitter.com/mtgrigorov
> >
> > On Wed, Mar 2, 2016 at 4:31 PM, Lars Törner <lars.tor...@gmail.com>
> wrote:
> >
> > > Hi,
> > >
> > > I have some (naive?) questions:
> > >
> > > - Isn't it time to think about wicket and http/2?
> > > - Must we wait for javaee8/servlet 4.0 and then wait for a new version
> of
> > > wicket that supports it?
> > > - Is it possible to implement an extension to support http/2 in wicket?
> > > - Is it a huge effort to make this happen?
> > >
> > > I think (most of?) the latest versions of the major browsers support
> > > http/2, Wildfly supports http/2 server side with undertow... etc.
> > > Known implementations of HTTP/2:
> > > https://github.com/http2/http2-spec/wiki/Implementations
> > >
> > > I have read Martin G:s comment from a year back about this (see below),
> > but
> > > not found anything else... maybe there already is an ongoing discussion
> > > about this?
> > >
> > > Cheers
> > > Lasse
> > >
> > > Martins reflections about http/2 and servlet 4.0
> > > I'm afraid it is too early for this. We can make sure Wicket works fine
> > in
> > > a container supporting those but it is too early to require that.
> Servlet
> > > 4.0 is still in design process. Apache Tomcat didn't started
> implementing
> > > any features from it. I am not sure about the status in Jetty. I know
> > that
> > > Undertow (the web container for JBoss Wildfly) supports HTTP 2.0 but I
> > > haven't heard of any Servlet 4.0 features. It will take us some time to
> > > release 8.0.0 but I think it will be too
> > > early to require Servlet 4.0 even then.
> > >
> >
>


Re: http/2

2016-03-02 Thread Lars Törner
Hi Martin,

that sounds interesting!

So what you´re saying is that if the server where the wicket-applictation
is deployed supports http/2 then wicket itself doesn't need any
wicket-specific-extension to work. And that, for example, all components
css/javascript-resources of a page will be fetched over one multiplexed
connection.

Cheers
Lasse



2016-03-02 16:40 GMT+01:00 Martin Grigorov <mgrigo...@apache.org>:

> Hi Lasse,
>
> I have successfully tested a Wicket application (my WebSockets demo app) on
> Tomcat 9.0.0.M1/M2/M3 (
> https://twitter.com/mtgrigorov/status/665916977957982208) with HTTP/2.
> Currently there is a discussion at Tomcat dev@ mailing list about porting
> back the changes to Tomcat 8.5.0. 8.5 will be what 9.0 is now without the
> Servlet 4.x APIs because Servlet 4.x release date is far in the future.
>
> I have also was able to run Wicket app with Jetty SPDY impl in the past.
>
> I haven't tested with WildFly 10 but I don't expect any problems from
> Wicket side.
> Please let us know if you face any issues and we will investigate them!
>
> Thanks!
>
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Wed, Mar 2, 2016 at 4:31 PM, Lars Törner <lars.tor...@gmail.com> wrote:
>
> > Hi,
> >
> > I have some (naive?) questions:
> >
> > - Isn't it time to think about wicket and http/2?
> > - Must we wait for javaee8/servlet 4.0 and then wait for a new version of
> > wicket that supports it?
> > - Is it possible to implement an extension to support http/2 in wicket?
> > - Is it a huge effort to make this happen?
> >
> > I think (most of?) the latest versions of the major browsers support
> > http/2, Wildfly supports http/2 server side with undertow... etc.
> > Known implementations of HTTP/2:
> > https://github.com/http2/http2-spec/wiki/Implementations
> >
> > I have read Martin G:s comment from a year back about this (see below),
> but
> > not found anything else... maybe there already is an ongoing discussion
> > about this?
> >
> > Cheers
> > Lasse
> >
> > Martins reflections about http/2 and servlet 4.0
> > I'm afraid it is too early for this. We can make sure Wicket works fine
> in
> > a container supporting those but it is too early to require that. Servlet
> > 4.0 is still in design process. Apache Tomcat didn't started implementing
> > any features from it. I am not sure about the status in Jetty. I know
> that
> > Undertow (the web container for JBoss Wildfly) supports HTTP 2.0 but I
> > haven't heard of any Servlet 4.0 features. It will take us some time to
> > release 8.0.0 but I think it will be too
> > early to require Servlet 4.0 even then.
> >
>


Re: http/2

2016-03-02 Thread Martin Grigorov
Hi Lasse,

I have successfully tested a Wicket application (my WebSockets demo app) on
Tomcat 9.0.0.M1/M2/M3 (
https://twitter.com/mtgrigorov/status/665916977957982208) with HTTP/2.
Currently there is a discussion at Tomcat dev@ mailing list about porting
back the changes to Tomcat 8.5.0. 8.5 will be what 9.0 is now without the
Servlet 4.x APIs because Servlet 4.x release date is far in the future.

I have also was able to run Wicket app with Jetty SPDY impl in the past.

I haven't tested with WildFly 10 but I don't expect any problems from
Wicket side.
Please let us know if you face any issues and we will investigate them!

Thanks!


Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Wed, Mar 2, 2016 at 4:31 PM, Lars Törner <lars.tor...@gmail.com> wrote:

> Hi,
>
> I have some (naive?) questions:
>
> - Isn't it time to think about wicket and http/2?
> - Must we wait for javaee8/servlet 4.0 and then wait for a new version of
> wicket that supports it?
> - Is it possible to implement an extension to support http/2 in wicket?
> - Is it a huge effort to make this happen?
>
> I think (most of?) the latest versions of the major browsers support
> http/2, Wildfly supports http/2 server side with undertow... etc.
> Known implementations of HTTP/2:
> https://github.com/http2/http2-spec/wiki/Implementations
>
> I have read Martin G:s comment from a year back about this (see below), but
> not found anything else... maybe there already is an ongoing discussion
> about this?
>
> Cheers
> Lasse
>
> Martins reflections about http/2 and servlet 4.0
> I'm afraid it is too early for this. We can make sure Wicket works fine in
> a container supporting those but it is too early to require that. Servlet
> 4.0 is still in design process. Apache Tomcat didn't started implementing
> any features from it. I am not sure about the status in Jetty. I know that
> Undertow (the web container for JBoss Wildfly) supports HTTP 2.0 but I
> haven't heard of any Servlet 4.0 features. It will take us some time to
> release 8.0.0 but I think it will be too
> early to require Servlet 4.0 even then.
>


http/2

2016-03-02 Thread Lars Törner
Hi,

I have some (naive?) questions:

- Isn't it time to think about wicket and http/2?
- Must we wait for javaee8/servlet 4.0 and then wait for a new version of
wicket that supports it?
- Is it possible to implement an extension to support http/2 in wicket?
- Is it a huge effort to make this happen?

I think (most of?) the latest versions of the major browsers support
http/2, Wildfly supports http/2 server side with undertow... etc.
Known implementations of HTTP/2:
https://github.com/http2/http2-spec/wiki/Implementations

I have read Martin G:s comment from a year back about this (see below), but
not found anything else... maybe there already is an ongoing discussion
about this?

Cheers
Lasse

Martins reflections about http/2 and servlet 4.0
I'm afraid it is too early for this. We can make sure Wicket works fine in
a container supporting those but it is too early to require that. Servlet
4.0 is still in design process. Apache Tomcat didn't started implementing
any features from it. I am not sure about the status in Jetty. I know that
Undertow (the web container for JBoss Wildfly) supports HTTP 2.0 but I
haven't heard of any Servlet 4.0 features. It will take us some time to
release 8.0.0 but I think it will be too
early to require Servlet 4.0 even then.