From sdouglas at redhat.com  Sun Apr  2 19:24:21 2017
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 3 Apr 2017 09:24:21 +1000
Subject: [undertow-dev] Is it ok to do a blocking action from a Receiver
	callback?
In-Reply-To: <CAKqS+r2=2+_5iGOuCXKL5pa4g9VJ=DgVV=Z=UqWEK99gS4zR3w@mail.gmail.com>
References: <CAKqS+r3N9UQTv3VYCzd2MvSVh8mQBNEChbeKXAuOrOQdzfPiwg@mail.gmail.com>
	<CAD+L2cwo_a+TW-an9Dek7LPnU7PRt00ULmsoAUK8Ph2x7Fgxqg@mail.gmail.com>
	<CALc5U3EQio64=W1B2OUbeakQkY83Yfs7bs5iAWH8q2THdV5WFw@mail.gmail.com>
	<CAD+L2cx3v=wmevqoL3_Zw_fmVT=SfE5pddfUon=rBbZdHJA6Pw@mail.gmail.com>
	<CAKqS+r2=2+_5iGOuCXKL5pa4g9VJ=DgVV=Z=UqWEK99gS4zR3w@mail.gmail.com>
Message-ID: <CAD+L2cz2gEJkkcLy98TE=kLGwdkpCvbCHV2DJJ1=zJN4pL+E6A@mail.gmail.com>

Yes, although the writes to disk should also be handled by a worker
thread (as they can block).

Stuart

On Fri, Mar 31, 2017 at 11:10 PM, Michael Grove <mike at stardog.com> wrote:
> So what would be the right workflow using Receiver to read a large request,
> do something time-consuming, and send back a response? Use Receiver
> callbacks to write partial payloads to disk, and the last callback then
> dispatch to a worker thread?
>
> Cheers,
>
> Mike
>
> On Fri, Mar 31, 2017 at 6:30 AM, Stuart Douglas <sdouglas at redhat.com> wrote:
>>
>> It will generally be handled by an IO thread, although it can depend
>> on how large the request is. If a request is small enough that it gets
>> read immediately then the request will be handled in the same thread,
>> otherwise it will be handled by the IO thread to full read the
>> request.
>>
>> Stuart
>>
>> On Fri, Mar 31, 2017 at 8:05 PM, Antoine Girard
>> <antoine.girard at ymail.com> wrote:
>> > Correct me if I am wrong Stuart but if the request was already
>> > dispatched
>> > before calling the getRequestReceiver(), then the callback will be
>> > handled
>> > by a worker thread.
>> >
>> > Cheers,
>> > Antoine
>> >
>> > On Thu, Mar 30, 2017 at 11:48 PM, Stuart Douglas <sdouglas at redhat.com>
>> > wrote:
>> >>
>> >> No, the callback is invoked by the IO thread, so you would need to
>> >> dispatch to a worker thread.
>> >>
>> >> Stuart
>> >>
>> >> On Fri, Mar 31, 2017 at 6:58 AM, Michael Grove <mike at stardog.com>
>> >> wrote:
>> >> > If I have some code ala
>> >> >
>> >> > theRequest.getRequestReceiver().receiveFullString((theExchange, str)
>> >> > ->
>> >> > {
>> >> >   ...
>> >> > });
>> >> >
>> >> > Is it ok to perform a time consuming task w/ the body of the request
>> >> > in
>> >> > the
>> >> > callback, or is it better to move off the io thread and use
>> >> > `HttpServerExchange.getInputStream`?
>> >> >
>> >> > Cheers,
>> >> >
>> >> > Mike
>> >> >
>> >> > _______________________________________________
>> >> > undertow-dev mailing list
>> >> > undertow-dev at lists.jboss.org
>> >> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>> >> _______________________________________________
>> >> undertow-dev mailing list
>> >> undertow-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/undertow-dev
>> >
>> >
>
>

From gpietrusza at gmail.com  Wed Apr  5 08:57:00 2017
From: gpietrusza at gmail.com (Grzegorz Pietrusza)
Date: Wed, 5 Apr 2017 14:57:00 +0200
Subject: [undertow-dev] undertow 1.4.X docs
Message-ID: <CABTHQYDaQzn9XYynyXVS0HHPxy2T=O2BLK292VEqpfm8tXhcAA@mail.gmail.com>

Hi undertow-dev

Is undertow 1.4.X production ready? I see it's released in maven central,
but it's not documented or mentioned anywhere at undertow.io.

Regards
Grzegorz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170405/6a87fb81/attachment.html 

From sdouglas at redhat.com  Wed Apr  5 17:49:28 2017
From: sdouglas at redhat.com (Stuart Douglas)
Date: Thu, 6 Apr 2017 07:49:28 +1000
Subject: [undertow-dev] undertow 1.4.X docs
In-Reply-To: <CABTHQYDaQzn9XYynyXVS0HHPxy2T=O2BLK292VEqpfm8tXhcAA@mail.gmail.com>
References: <CABTHQYDaQzn9XYynyXVS0HHPxy2T=O2BLK292VEqpfm8tXhcAA@mail.gmail.com>
Message-ID: <CAD+L2cz94XUd0BUvhWu70q3QKOsK_w8P1409H2cikL65e7jcWg@mail.gmail.com>

Yes, although it is basically a continuation of the 1.3.x series with
better ALPN support (although as it currently stands it has a lot more
bug fixes that are not in 1.3.x).

In the near future I am going to redo the undertow.io site to make it
much easier to maintain.

Stuart

On Wed, Apr 5, 2017 at 10:57 PM, Grzegorz Pietrusza
<gpietrusza at gmail.com> wrote:
> Hi undertow-dev
>
> Is undertow 1.4.X production ready? I see it's released in maven central,
> but it's not documented or mentioned anywhere at undertow.io.
>
> Regards
> Grzegorz
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From gpietrusza at gmail.com  Thu Apr  6 01:45:31 2017
From: gpietrusza at gmail.com (Grzegorz Pietrusza)
Date: Thu, 6 Apr 2017 07:45:31 +0200
Subject: [undertow-dev] undertow 1.4.X docs
In-Reply-To: <CAD+L2cz94XUd0BUvhWu70q3QKOsK_w8P1409H2cikL65e7jcWg@mail.gmail.com>
References: <CABTHQYDaQzn9XYynyXVS0HHPxy2T=O2BLK292VEqpfm8tXhcAA@mail.gmail.com>
	<CAD+L2cz94XUd0BUvhWu70q3QKOsK_w8P1409H2cikL65e7jcWg@mail.gmail.com>
Message-ID: <CABTHQYCC1u55pB6ubLFd6q49ZxKRgFB3cHeWkS9tehh=iJuDsQ@mail.gmail.com>

Thanks

2017-04-05 23:49 GMT+02:00 Stuart Douglas <sdouglas at redhat.com>:

> Yes, although it is basically a continuation of the 1.3.x series with
> better ALPN support (although as it currently stands it has a lot more
> bug fixes that are not in 1.3.x).
>
> In the near future I am going to redo the undertow.io site to make it
> much easier to maintain.
>
> Stuart
>
> On Wed, Apr 5, 2017 at 10:57 PM, Grzegorz Pietrusza
> <gpietrusza at gmail.com> wrote:
> > Hi undertow-dev
> >
> > Is undertow 1.4.X production ready? I see it's released in maven central,
> > but it's not documented or mentioned anywhere at undertow.io.
> >
> > Regards
> > Grzegorz
> >
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170406/5104aa19/attachment-0001.html 

From matt at matthicks.com  Wed Apr 12 10:15:17 2017
From: matt at matthicks.com (Hicks, Matt)
Date: Wed, 12 Apr 2017 14:15:17 +0000
Subject: [undertow-dev] ClosedChannelException
Message-ID: <CAFeDf1-+SRSoiPfeWSx2qm8WudSyq+hFGLHLDsE868HD8dY4TA@mail.gmail.com>

I seem to be experiencing a lot of:

[XNIO-1 task-40] ERROR i.y.E.defaultHandler.???:23 -
java.nio.channels.ClosedChannelException
    at io.undertow.protocols.ssl.SslConduit.write(SslConduit.java:369)
    at
org.xnio.conduits.ConduitStreamSinkChannel.write(ConduitStreamSinkChannel.java:150)
    at
org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:385)
    at
org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:372)
    at
org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
    at
org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.writeReady(WriteReadyHandler.java:65)
    at
io.undertow.protocols.ssl.SslConduit$SslWriteReadyHandler.writeReady(SslConduit.java:1225)
    at io.undertow.protocols.ssl.SslConduit$3.run(SslConduit.java:275)
    at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:580)
    at org.xnio.nio.WorkerThread.run(WorkerThread.java:464)

I'm not positive this is connected to my update to 1.4.12.Final, but I
wanted to check to see if this is something anyone else is seeing?  It's
likely it's related to my code, although I have no idea what I would have
changed to cause this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170412/5d8e6a82/attachment.html 

From sdouglas at redhat.com  Wed Apr 12 18:26:57 2017
From: sdouglas at redhat.com (Stuart Douglas)
Date: Thu, 13 Apr 2017 08:26:57 +1000
Subject: [undertow-dev] ClosedChannelException
In-Reply-To: <CAFeDf1-+SRSoiPfeWSx2qm8WudSyq+hFGLHLDsE868HD8dY4TA@mail.gmail.com>
References: <CAFeDf1-+SRSoiPfeWSx2qm8WudSyq+hFGLHLDsE868HD8dY4TA@mail.gmail.com>
Message-ID: <CAD+L2cxoCE07i1aw8ZYq=BELBPCggvy=OwM5kJuy0kPN04hpUQ@mail.gmail.com>

I am guessing you are using the websocket client? This would be the
exception you get if the connection failed. I don't think Undertow
does any logging, so you must be logging this at the ERROR level.

As to why it is failing it is hard to say. How good is the network
between the client and the target server, and how often is a lot?

Also what version were you using before 1.4.12.Final?

Stuart

On Thu, Apr 13, 2017 at 12:15 AM, Hicks, Matt <matt at matthicks.com> wrote:
> I seem to be experiencing a lot of:
>
> [XNIO-1 task-40] ERROR i.y.E.defaultHandler.???:23 -
> java.nio.channels.ClosedChannelException
>     at io.undertow.protocols.ssl.SslConduit.write(SslConduit.java:369)
>     at
> org.xnio.conduits.ConduitStreamSinkChannel.write(ConduitStreamSinkChannel.java:150)
>     at
> org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:385)
>     at
> org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:372)
>     at
> org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
>     at
> org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.writeReady(WriteReadyHandler.java:65)
>     at
> io.undertow.protocols.ssl.SslConduit$SslWriteReadyHandler.writeReady(SslConduit.java:1225)
>     at io.undertow.protocols.ssl.SslConduit$3.run(SslConduit.java:275)
>     at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:580)
>     at org.xnio.nio.WorkerThread.run(WorkerThread.java:464)
>
> I'm not positive this is connected to my update to 1.4.12.Final, but I
> wanted to check to see if this is something anyone else is seeing?  It's
> likely it's related to my code, although I have no idea what I would have
> changed to cause this.
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From matt at matthicks.com  Wed Apr 12 19:04:07 2017
From: matt at matthicks.com (Hicks, Matt)
Date: Wed, 12 Apr 2017 23:04:07 +0000
Subject: [undertow-dev] ClosedChannelException
In-Reply-To: <CAD+L2cxoCE07i1aw8ZYq=BELBPCggvy=OwM5kJuy0kPN04hpUQ@mail.gmail.com>
References: <CAFeDf1-+SRSoiPfeWSx2qm8WudSyq+hFGLHLDsE868HD8dY4TA@mail.gmail.com>
	<CAD+L2cxoCE07i1aw8ZYq=BELBPCggvy=OwM5kJuy0kPN04hpUQ@mail.gmail.com>
Message-ID: <CAFeDf1_abAB+gGTO1__78whf3LH_0FhC=aAC2rUzxTbWfeebYg@mail.gmail.com>

Well, I seem to have narrowed down the cause to CloudFlare.  If I pause
CloudFlare then it stops happening.  The connection is incredibly stable
and was happening consistently.

On Wed, Apr 12, 2017 at 5:26 PM Stuart Douglas <sdouglas at redhat.com> wrote:

> I am guessing you are using the websocket client? This would be the
> exception you get if the connection failed. I don't think Undertow
> does any logging, so you must be logging this at the ERROR level.
>
> As to why it is failing it is hard to say. How good is the network
> between the client and the target server, and how often is a lot?
>
> Also what version were you using before 1.4.12.Final?
>
> Stuart
>
> On Thu, Apr 13, 2017 at 12:15 AM, Hicks, Matt <matt at matthicks.com> wrote:
> > I seem to be experiencing a lot of:
> >
> > [XNIO-1 task-40] ERROR i.y.E.defaultHandler.???:23 -
> > java.nio.channels.ClosedChannelException
> >     at io.undertow.protocols.ssl.SslConduit.write(SslConduit.java:369)
> >     at
> >
> org.xnio.conduits.ConduitStreamSinkChannel.write(ConduitStreamSinkChannel.java:150)
> >     at
> >
> org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:385)
> >     at
> >
> org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:372)
> >     at
> > org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> >     at
> >
> org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.writeReady(WriteReadyHandler.java:65)
> >     at
> >
> io.undertow.protocols.ssl.SslConduit$SslWriteReadyHandler.writeReady(SslConduit.java:1225)
> >     at io.undertow.protocols.ssl.SslConduit$3.run(SslConduit.java:275)
> >     at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:580)
> >     at org.xnio.nio.WorkerThread.run(WorkerThread.java:464)
> >
> > I'm not positive this is connected to my update to 1.4.12.Final, but I
> > wanted to check to see if this is something anyone else is seeing?  It's
> > likely it's related to my code, although I have no idea what I would have
> > changed to cause this.
> >
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170412/b99bb3de/attachment.html 

From sdouglas at redhat.com  Wed Apr 12 19:16:58 2017
From: sdouglas at redhat.com (Stuart Douglas)
Date: Thu, 13 Apr 2017 09:16:58 +1000
Subject: [undertow-dev] ClosedChannelException
In-Reply-To: <CAFeDf1_abAB+gGTO1__78whf3LH_0FhC=aAC2rUzxTbWfeebYg@mail.gmail.com>
References: <CAFeDf1-+SRSoiPfeWSx2qm8WudSyq+hFGLHLDsE868HD8dY4TA@mail.gmail.com>
	<CAD+L2cxoCE07i1aw8ZYq=BELBPCggvy=OwM5kJuy0kPN04hpUQ@mail.gmail.com>
	<CAFeDf1_abAB+gGTO1__78whf3LH_0FhC=aAC2rUzxTbWfeebYg@mail.gmail.com>
Message-ID: <CAD+L2cxivDy31mua0ooPqs+M+4Y4zFdP3VxALC_SpoZw8PD_1g@mail.gmail.com>

Maybe cloudflare is rejecting some of the websocket upgrades?

Stuart

On Thu, Apr 13, 2017 at 9:04 AM, Hicks, Matt <matt at matthicks.com> wrote:
> Well, I seem to have narrowed down the cause to CloudFlare.  If I pause
> CloudFlare then it stops happening.  The connection is incredibly stable and
> was happening consistently.
>
> On Wed, Apr 12, 2017 at 5:26 PM Stuart Douglas <sdouglas at redhat.com> wrote:
>>
>> I am guessing you are using the websocket client? This would be the
>> exception you get if the connection failed. I don't think Undertow
>> does any logging, so you must be logging this at the ERROR level.
>>
>> As to why it is failing it is hard to say. How good is the network
>> between the client and the target server, and how often is a lot?
>>
>> Also what version were you using before 1.4.12.Final?
>>
>> Stuart
>>
>> On Thu, Apr 13, 2017 at 12:15 AM, Hicks, Matt <matt at matthicks.com> wrote:
>> > I seem to be experiencing a lot of:
>> >
>> > [XNIO-1 task-40] ERROR i.y.E.defaultHandler.???:23 -
>> > java.nio.channels.ClosedChannelException
>> >     at io.undertow.protocols.ssl.SslConduit.write(SslConduit.java:369)
>> >     at
>> >
>> > org.xnio.conduits.ConduitStreamSinkChannel.write(ConduitStreamSinkChannel.java:150)
>> >     at
>> >
>> > org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:385)
>> >     at
>> >
>> > org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:372)
>> >     at
>> >
>> > org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
>> >     at
>> >
>> > org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.writeReady(WriteReadyHandler.java:65)
>> >     at
>> >
>> > io.undertow.protocols.ssl.SslConduit$SslWriteReadyHandler.writeReady(SslConduit.java:1225)
>> >     at io.undertow.protocols.ssl.SslConduit$3.run(SslConduit.java:275)
>> >     at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:580)
>> >     at org.xnio.nio.WorkerThread.run(WorkerThread.java:464)
>> >
>> > I'm not positive this is connected to my update to 1.4.12.Final, but I
>> > wanted to check to see if this is something anyone else is seeing?  It's
>> > likely it's related to my code, although I have no idea what I would
>> > have
>> > changed to cause this.
>> >
>> > _______________________________________________
>> > undertow-dev mailing list
>> > undertow-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/undertow-dev

From matt at matthicks.com  Wed Apr 12 19:28:25 2017
From: matt at matthicks.com (Hicks, Matt)
Date: Wed, 12 Apr 2017 23:28:25 +0000
Subject: [undertow-dev] ClosedChannelException
In-Reply-To: <CAD+L2cxivDy31mua0ooPqs+M+4Y4zFdP3VxALC_SpoZw8PD_1g@mail.gmail.com>
References: <CAFeDf1-+SRSoiPfeWSx2qm8WudSyq+hFGLHLDsE868HD8dY4TA@mail.gmail.com>
	<CAD+L2cxoCE07i1aw8ZYq=BELBPCggvy=OwM5kJuy0kPN04hpUQ@mail.gmail.com>
	<CAFeDf1_abAB+gGTO1__78whf3LH_0FhC=aAC2rUzxTbWfeebYg@mail.gmail.com>
	<CAD+L2cxivDy31mua0ooPqs+M+4Y4zFdP3VxALC_SpoZw8PD_1g@mail.gmail.com>
Message-ID: <CAFeDf1-0cYw=BU+j3B2V_hwm3qiPj8_YPJSCt8K0Lxj1u7JZuQ@mail.gmail.com>

I don't believe so...it seems to be happening when sending a message from
the server to the browser after the connection has already been established
successfully.  I'll do some additional research and see if I can further
narrow down the problem.

On Wed, Apr 12, 2017 at 6:16 PM Stuart Douglas <sdouglas at redhat.com> wrote:

> Maybe cloudflare is rejecting some of the websocket upgrades?
>
> Stuart
>
> On Thu, Apr 13, 2017 at 9:04 AM, Hicks, Matt <matt at matthicks.com> wrote:
> > Well, I seem to have narrowed down the cause to CloudFlare.  If I pause
> > CloudFlare then it stops happening.  The connection is incredibly stable
> and
> > was happening consistently.
> >
> > On Wed, Apr 12, 2017 at 5:26 PM Stuart Douglas <sdouglas at redhat.com>
> wrote:
> >>
> >> I am guessing you are using the websocket client? This would be the
> >> exception you get if the connection failed. I don't think Undertow
> >> does any logging, so you must be logging this at the ERROR level.
> >>
> >> As to why it is failing it is hard to say. How good is the network
> >> between the client and the target server, and how often is a lot?
> >>
> >> Also what version were you using before 1.4.12.Final?
> >>
> >> Stuart
> >>
> >> On Thu, Apr 13, 2017 at 12:15 AM, Hicks, Matt <matt at matthicks.com>
> wrote:
> >> > I seem to be experiencing a lot of:
> >> >
> >> > [XNIO-1 task-40] ERROR i.y.E.defaultHandler.???:23 -
> >> > java.nio.channels.ClosedChannelException
> >> >     at io.undertow.protocols.ssl.SslConduit.write(SslConduit.java:369)
> >> >     at
> >> >
> >> >
> org.xnio.conduits.ConduitStreamSinkChannel.write(ConduitStreamSinkChannel.java:150)
> >> >     at
> >> >
> >> >
> org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:385)
> >> >     at
> >> >
> >> >
> org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:372)
> >> >     at
> >> >
> >> >
> org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> >> >     at
> >> >
> >> >
> org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.writeReady(WriteReadyHandler.java:65)
> >> >     at
> >> >
> >> >
> io.undertow.protocols.ssl.SslConduit$SslWriteReadyHandler.writeReady(SslConduit.java:1225)
> >> >     at io.undertow.protocols.ssl.SslConduit$3.run(SslConduit.java:275)
> >> >     at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:580)
> >> >     at org.xnio.nio.WorkerThread.run(WorkerThread.java:464)
> >> >
> >> > I'm not positive this is connected to my update to 1.4.12.Final, but I
> >> > wanted to check to see if this is something anyone else is seeing?
> It's
> >> > likely it's related to my code, although I have no idea what I would
> >> > have
> >> > changed to cause this.
> >> >
> >> > _______________________________________________
> >> > undertow-dev mailing list
> >> > undertow-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170412/792ab7b9/attachment-0001.html 

From ebenzacar at gmail.com  Thu Apr 13 21:52:07 2017
From: ebenzacar at gmail.com (Eric B)
Date: Thu, 13 Apr 2017 21:52:07 -0400
Subject: [undertow-dev] ClassCastException when retrieving a beans from CDI
	with Weld Proxy beans
Message-ID: <CA+T+PjGa_Aho0iU-762igo4uWZkw1+U27vx39SCmPeyFUZU-kg@mail.gmail.com>

I posted this problem on StackOverflow, but after doing more research, I'm
not sure if this is a Weld, JBoss/WildFly or undertow issue.  Or whether
its a framework issue, or how the framework is being used.  If this is not
the correct list, can you please let me know which list/group I should be
directing the issue to?

I'm running into a strange problem and error message that I do not
understand. I'm running my application on JBoss 7 EAP.

Caused by: java.lang.ClassCastException: Cannot cast
ejbs.LoginManager$417755913$Proxy$_$$_Weld$EnterpriseProxy$ to
ejbs.LoginManager

I'm trying to programatically retrieve an EJB from the CDI context by using
its interface and am getting this error message. I've created a sample
proof-of-concept that is trying to retrieve EJB beans from the CDI context

public <T> T getSesionBean(Class<T> clazz, String name) {
    Properties properties = new Properties();

    try {
        InitialContext initContext = new InitialContext();

        return clazz.cast(CDI.current().select(clazz).get());
    } catch (Exception e) {
        // TODO Auto-generated catch block
        throw new RuntimeException(e);
    }}

It is being called as:

LoginManager login = getSesionBean(LoginManager.class);

with my EJB defined as:

@Stateless(name="LoginManager")@Local(LoginManager.class)@LocalBinding(jndiBinding="LoginManager")public
class LoginManagerBean implements LoginManager {.........}

I don't understand it. I'm expecting the bean being retrieved from the
context to be a proxy. Shouldn't it be castable to my interface? Otherwise,
how am I supposed to retrieve it?

More interestingly, this does not seem to be a consistent error; sometimes
the code works fine. Sometimes it fails. I haven't been able to determine
what makes it work or throw an exception.

I found a related issue here <https://issues.jboss.org/browse/WELD-1498>,
but not sure if this is the same problem and/or which version of Weld is
used in JB7EAP. I'm including the following dependency in my application:

    <dependency>
        <groupId>org.wildfly</groupId>
        <artifactId>wildfly-ejb-client-bom</artifactId>
        <version>10.1.0.Final</version>
        <type>pom</type>
    </dependency>

Am I doing something completely wrong? If this is a Weld bug, can I use a
different proxy system than Weld?  Is this even configurable in undertow?


Thanks,


Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170413/79e8d8ad/attachment-0001.html 

From sdouglas at redhat.com  Mon Apr 17 18:01:30 2017
From: sdouglas at redhat.com (Stuart Douglas)
Date: Tue, 18 Apr 2017 08:01:30 +1000
Subject: [undertow-dev] ClassCastException when retrieving a beans from
 CDI with Weld Proxy beans
In-Reply-To: <CA+T+PjGa_Aho0iU-762igo4uWZkw1+U27vx39SCmPeyFUZU-kg@mail.gmail.com>
References: <CA+T+PjGa_Aho0iU-762igo4uWZkw1+U27vx39SCmPeyFUZU-kg@mail.gmail.com>
Message-ID: <CAD+L2cx3uPw5Jrd4TqhkUDRF8DZF9a0+r8eTUSMRK9TiNyZdOg@mail.gmail.com>

It sounds like a class loading problem. You likely have two copies of
ejbs.LoginManager, and somehow you are using the wrong one. If you
look at the output of
System.out.println(LoginManager.class.getClassLoader()) and
System.out.println(CDI.current().select(clazz).get().getClass().getClassLoader())
it should give you a clue.

This is not an Undertow issue.

Stuart

On Fri, Apr 14, 2017 at 11:52 AM, Eric B <ebenzacar at gmail.com> wrote:
> I posted this problem on StackOverflow, but after doing more research, I'm
> not sure if this is a Weld, JBoss/WildFly or undertow issue.  Or whether its
> a framework issue, or how the framework is being used.  If this is not the
> correct list, can you please let me know which list/group I should be
> directing the issue to?
>
> I'm running into a strange problem and error message that I do not
> understand. I'm running my application on JBoss 7 EAP.
>
> Caused by: java.lang.ClassCastException: Cannot cast
> ejbs.LoginManager$417755913$Proxy$_$$_Weld$EnterpriseProxy$ to
> ejbs.LoginManager
>
> I'm trying to programatically retrieve an EJB from the CDI context by using
> its interface and am getting this error message. I've created a sample
> proof-of-concept that is trying to retrieve EJB beans from the CDI context
>
> public <T> T getSesionBean(Class<T> clazz, String name) {
>     Properties properties = new Properties();
>
>     try {
>         InitialContext initContext = new InitialContext();
>
>         return clazz.cast(CDI.current().select(clazz).get());
>     } catch (Exception e) {
>         // TODO Auto-generated catch block
>         throw new RuntimeException(e);
>     }
> }
>
> It is being called as:
>
> LoginManager login = getSesionBean(LoginManager.class);
>
> with my EJB defined as:
>
> @Stateless(name="LoginManager")
> @Local(LoginManager.class)
> @LocalBinding(jndiBinding="LoginManager")
> public class LoginManagerBean implements LoginManager {
> ...
> ...
> ...
> }
>
> I don't understand it. I'm expecting the bean being retrieved from the
> context to be a proxy. Shouldn't it be castable to my interface? Otherwise,
> how am I supposed to retrieve it?
>
> More interestingly, this does not seem to be a consistent error; sometimes
> the code works fine. Sometimes it fails. I haven't been able to determine
> what makes it work or throw an exception.
>
> I found a related issue here, but not sure if this is the same problem
> and/or which version of Weld is used in JB7EAP. I'm including the following
> dependency in my application:
>
>     <dependency>
>         <groupId>org.wildfly</groupId>
>         <artifactId>wildfly-ejb-client-bom</artifactId>
>         <version>10.1.0.Final</version>
>         <type>pom</type>
>     </dependency>
>
> Am I doing something completely wrong? If this is a Weld bug, can I use a
> different proxy system than Weld?  Is this even configurable in undertow?
>
>
> Thanks,
>
>
> Eric
>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From mkouba at redhat.com  Tue Apr 18 10:09:29 2017
From: mkouba at redhat.com (Martin Kouba)
Date: Tue, 18 Apr 2017 16:09:29 +0200
Subject: [undertow-dev] ClassCastException when retrieving a beans from
 CDI with Weld Proxy beans
In-Reply-To: <CAD+L2cx3uPw5Jrd4TqhkUDRF8DZF9a0+r8eTUSMRK9TiNyZdOg@mail.gmail.com>
References: <CA+T+PjGa_Aho0iU-762igo4uWZkw1+U27vx39SCmPeyFUZU-kg@mail.gmail.com>
	<CAD+L2cx3uPw5Jrd4TqhkUDRF8DZF9a0+r8eTUSMRK9TiNyZdOg@mail.gmail.com>
Message-ID: <ad1d0e4a-02e0-166f-5c7d-348b3d41b843@redhat.com>

Hi Eric,

feel free to ask on Weld ML, irc, gitter or forums - 
http://weld.cdi-spec.org/community

And if possible provide a simple test app/reproducer.

Martin

Dne 18.4.2017 v 00:01 Stuart Douglas napsal(a):
> It sounds like a class loading problem. You likely have two copies of
> ejbs.LoginManager, and somehow you are using the wrong one. If you
> look at the output of
> System.out.println(LoginManager.class.getClassLoader()) and
> System.out.println(CDI.current().select(clazz).get().getClass().getClassLoader())
> it should give you a clue.
>
> This is not an Undertow issue.
>
> Stuart
>
> On Fri, Apr 14, 2017 at 11:52 AM, Eric B <ebenzacar at gmail.com> wrote:
>> I posted this problem on StackOverflow, but after doing more research, I'm
>> not sure if this is a Weld, JBoss/WildFly or undertow issue.  Or whether its
>> a framework issue, or how the framework is being used.  If this is not the
>> correct list, can you please let me know which list/group I should be
>> directing the issue to?
>>
>> I'm running into a strange problem and error message that I do not
>> understand. I'm running my application on JBoss 7 EAP.
>>
>> Caused by: java.lang.ClassCastException: Cannot cast
>> ejbs.LoginManager$417755913$Proxy$_$$_Weld$EnterpriseProxy$ to
>> ejbs.LoginManager
>>
>> I'm trying to programatically retrieve an EJB from the CDI context by using
>> its interface and am getting this error message. I've created a sample
>> proof-of-concept that is trying to retrieve EJB beans from the CDI context
>>
>> public <T> T getSesionBean(Class<T> clazz, String name) {
>>     Properties properties = new Properties();
>>
>>     try {
>>         InitialContext initContext = new InitialContext();
>>
>>         return clazz.cast(CDI.current().select(clazz).get());
>>     } catch (Exception e) {
>>         // TODO Auto-generated catch block
>>         throw new RuntimeException(e);
>>     }
>> }
>>
>> It is being called as:
>>
>> LoginManager login = getSesionBean(LoginManager.class);
>>
>> with my EJB defined as:
>>
>> @Stateless(name="LoginManager")
>> @Local(LoginManager.class)
>> @LocalBinding(jndiBinding="LoginManager")
>> public class LoginManagerBean implements LoginManager {
>> ...
>> ...
>> ...
>> }
>>
>> I don't understand it. I'm expecting the bean being retrieved from the
>> context to be a proxy. Shouldn't it be castable to my interface? Otherwise,
>> how am I supposed to retrieve it?
>>
>> More interestingly, this does not seem to be a consistent error; sometimes
>> the code works fine. Sometimes it fails. I haven't been able to determine
>> what makes it work or throw an exception.
>>
>> I found a related issue here, but not sure if this is the same problem
>> and/or which version of Weld is used in JB7EAP. I'm including the following
>> dependency in my application:
>>
>>     <dependency>
>>         <groupId>org.wildfly</groupId>
>>         <artifactId>wildfly-ejb-client-bom</artifactId>
>>         <version>10.1.0.Final</version>
>>         <type>pom</type>
>>     </dependency>
>>
>> Am I doing something completely wrong? If this is a Weld bug, can I use a
>> different proxy system than Weld?  Is this even configurable in undertow?
>>
>>
>> Thanks,
>>
>>
>> Eric
>>
>>
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic

From gpietrusza at gmail.com  Tue Apr 18 10:36:48 2017
From: gpietrusza at gmail.com (Grzegorz Pietrusza)
Date: Tue, 18 Apr 2017 16:36:48 +0200
Subject: [undertow-dev] downgrading permissions
Message-ID: <CABTHQYANAc=07G9NLUiqOs0uq+1DbpYHAEKfheXMhu3erUdbJA@mail.gmail.com>

Hi undertow-dev

Is it possible to run undertow on <1024 port as root and then downgrade
user to non-root one? Dropwizard (jetty in fact) framework has such feature
(see #1), it just needs libsetuid.so loaded. Any alternative mechanism?

#1
http://www.dropwizard.io/0.7.0/dropwizard-core/apidocs/io/dropwizard/server/AbstractServerFactory.html

Regards
Grzegorz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170418/dc19425f/attachment.html 

From kr at asseco.dk  Tue Apr 18 13:46:12 2017
From: kr at asseco.dk (Kim Rasmussen)
Date: Tue, 18 Apr 2017 19:46:12 +0200
Subject: [undertow-dev] downgrading permissions
In-Reply-To: <CABTHQYANAc=07G9NLUiqOs0uq+1DbpYHAEKfheXMhu3erUdbJA@mail.gmail.com>
References: <CABTHQYANAc=07G9NLUiqOs0uq+1DbpYHAEKfheXMhu3erUdbJA@mail.gmail.com>
Message-ID: <CAGX6Y=0o6s2mq0-JgUU-6A6iC5JJ+-9xXWx-yB1rVq7_uCJiBQ@mail.gmail.com>

Would using ipchains / iptables work for you instead as an alternative ?

See more info here:
http://www.eclipse.org/jetty/documentation/current/setting-port80-access.html

/Kim

2017-04-18 16:36 GMT+02:00 Grzegorz Pietrusza <gpietrusza at gmail.com>:

> Hi undertow-dev
>
> Is it possible to run undertow on <1024 port as root and then downgrade
> user to non-root one? Dropwizard (jetty in fact) framework has such feature
> (see #1), it just needs libsetuid.so loaded. Any alternative mechanism?
>
> #1 http://www.dropwizard.io/0.7.0/dropwizard-core/apidocs/io/
> dropwizard/server/AbstractServerFactory.html
>
> Regards
> Grzegorz
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>



-- 
Med venlig hilsen / Best regards

*Kim Rasmussen*
Partner, IT Architect

*Asseco Denmark A/S*
Kronprinsessegade 54
DK-1306 Copenhagen K
Mobile: +45 26 16 40 23
Ph.: +45 33 36 46 60
Fax: +45 33 36 46 61
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170418/45b92662/attachment.html 

From hothman at webalo.com  Thu Apr 20 09:58:20 2017
From: hothman at webalo.com (Hanan Othman)
Date: Thu, 20 Apr 2017 15:58:20 +0200
Subject: [undertow-dev] Cannot Add the alpn-boot jar to WildFly's Boot
	Classpath
Message-ID: <CAP4fEymC6nW_D3sKV=AtRCmt+COTs04n+8M3vCcQhr8WEGRrbg@mail.gmail.com>

Hello undertow-dev,

I'm trying to use WildFly to send a push notification to iOS devices, which
requires the use of HTTP/2. Using OkHttp (http://square.github.io/okhttp/),
I was able to send a request successfully in an external java project using
the JVM option: -Xbootclasspath/p:<path-to-alpn-boot-jar>.

After checking the documentation here: http://undertow.io/blog/
2015/03/26/HTTP2-In-Wildfly.html, I was unable to do the same in WildFly.
When I run the server I get:

okhttp3.OkHttpClient  -- ALPN callback dropped: SPDY and HTTP/2 are
disabled. Is alpn-boot on the boot class path?

which leads me to think that it is not actually on the classpath. I have
the same configuration as that in the blog post, except having Wildfly
10.0.1.Final instead of Wildfly 9.0.0.Beta1. I have the correct alpn-boot
jar version since it already works outside of WildFly, but I do not know
what else I could be missing. Thank you very much for your time.

Best,
Hanan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170420/8233288e/attachment.html 

From tomaz.cerar at gmail.com  Thu Apr 20 10:42:45 2017
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Thu, 20 Apr 2017 16:42:45 +0200
Subject: [undertow-dev] Cannot Add the alpn-boot jar to WildFly's Boot
	Classpath
In-Reply-To: <CAP4fEymC6nW_D3sKV=AtRCmt+COTs04n+8M3vCcQhr8WEGRrbg@mail.gmail.com>
References: <CAP4fEymC6nW_D3sKV=AtRCmt+COTs04n+8M3vCcQhr8WEGRrbg@mail.gmail.com>
Message-ID: <CAMquZP6r+WCOSbspaBZLPZopXoHxUtqq8YpmPkCGKwi3kvMM1Q@mail.gmail.com>

Hey,

are you using proper version of apln-boot jar that applies to your exact
version of jdk?

Since 10.1, WildFly itself doesn't use the apln-boot hack anymore since,
but uses different solution in undertow that doesn't require patching jdk
classes.

--
tomaz

On Thu, Apr 20, 2017 at 3:58 PM, Hanan Othman <hothman at webalo.com> wrote:

> Hello undertow-dev,
>
> I'm trying to use WildFly to send a push notification to iOS devices,
> which requires the use of HTTP/2. Using OkHttp (
> http://square.github.io/okhttp/), I was able to send a request
> successfully in an external java project using the JVM option:
> -Xbootclasspath/p:<path-to-alpn-boot-jar>.
>
> After checking the documentation here: http://undertow.io/blog/
> 2015/03/26/HTTP2-In-Wildfly.html, I was unable to do the same in WildFly.
> When I run the server I get:
>
> okhttp3.OkHttpClient  -- ALPN callback dropped: SPDY and HTTP/2 are
> disabled. Is alpn-boot on the boot class path?
>
> which leads me to think that it is not actually on the classpath. I have
> the same configuration as that in the blog post, except having Wildfly
> 10.0.1.Final instead of Wildfly 9.0.0.Beta1. I have the correct alpn-boot
> jar version since it already works outside of WildFly, but I do not know
> what else I could be missing. Thank you very much for your time.
>
> Best,
> Hanan
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170420/a235cacf/attachment-0001.html 

From hothman at webalo.com  Thu Apr 20 11:17:50 2017
From: hothman at webalo.com (Hanan Othman)
Date: Thu, 20 Apr 2017 17:17:50 +0200
Subject: [undertow-dev] Cannot Add the alpn-boot jar to WildFly's Boot
	Classpath
In-Reply-To: <CAMquZP6r+WCOSbspaBZLPZopXoHxUtqq8YpmPkCGKwi3kvMM1Q@mail.gmail.com>
References: <CAP4fEymC6nW_D3sKV=AtRCmt+COTs04n+8M3vCcQhr8WEGRrbg@mail.gmail.com>
	<CAMquZP6r+WCOSbspaBZLPZopXoHxUtqq8YpmPkCGKwi3kvMM1Q@mail.gmail.com>
Message-ID: <CAP4fEymcz6qd5oRUtHMYAiMqBdH0WhDocEy7eg700H52PoUuLw@mail.gmail.com>

Yes, I am. The same jar works outside of WildFly.

Can you tell me about the other solution that WildFly 10.1 uses?

On Thu, Apr 20, 2017 at 4:42 PM, Toma? Cerar <tomaz.cerar at gmail.com> wrote:

> Hey,
>
> are you using proper version of apln-boot jar that applies to your exact
> version of jdk?
>
> Since 10.1, WildFly itself doesn't use the apln-boot hack anymore since,
> but uses different solution in undertow that doesn't require patching jdk
> classes.
>
> --
> tomaz
>
> On Thu, Apr 20, 2017 at 3:58 PM, Hanan Othman <hothman at webalo.com> wrote:
>
>> Hello undertow-dev,
>>
>> I'm trying to use WildFly to send a push notification to iOS devices,
>> which requires the use of HTTP/2. Using OkHttp (
>> http://square.github.io/okhttp/), I was able to send a request
>> successfully in an external java project using the JVM option:
>> -Xbootclasspath/p:<path-to-alpn-boot-jar>.
>>
>> After checking the documentation here: http://undertow.io/blog/
>> 2015/03/26/HTTP2-In-Wildfly.html, I was unable to do the same in
>> WildFly. When I run the server I get:
>>
>> okhttp3.OkHttpClient  -- ALPN callback dropped: SPDY and HTTP/2 are
>> disabled. Is alpn-boot on the boot class path?
>>
>> which leads me to think that it is not actually on the classpath. I have
>> the same configuration as that in the blog post, except having Wildfly
>> 10.0.1.Final instead of Wildfly 9.0.0.Beta1. I have the correct alpn-boot
>> jar version since it already works outside of WildFly, but I do not know
>> what else I could be missing. Thank you very much for your time.
>>
>> Best,
>> Hanan
>>
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170420/cc4673a8/attachment.html 

From ebenzacar at gmail.com  Thu Apr 20 14:04:42 2017
From: ebenzacar at gmail.com (Eric B)
Date: Thu, 20 Apr 2017 14:04:42 -0400
Subject: [undertow-dev] ClassCastException when retrieving a beans from
 CDI with Weld Proxy beans
In-Reply-To: <CAD+L2cx3uPw5Jrd4TqhkUDRF8DZF9a0+r8eTUSMRK9TiNyZdOg@mail.gmail.com>
References: <CA+T+PjGa_Aho0iU-762igo4uWZkw1+U27vx39SCmPeyFUZU-kg@mail.gmail.com>
	<CAD+L2cx3uPw5Jrd4TqhkUDRF8DZF9a0+r8eTUSMRK9TiNyZdOg@mail.gmail.com>
Message-ID: <CA+T+PjFw3qiJqLur8YqSLb6vyfkVW_R6Kk_r99HYFgg3NoVRdA@mail.gmail.com>

Indeed, it was an issue with duplicate copies of the class.  But I'm still
not convinced I should be getting this error.  Is this a parent-first vs
parent-last class loading issue?

The LoginManager.class is part of my ejbs.jar archive.

In my EAR, I had the following
- ejbs.jar
- webapp.war
   \- WEB-INF/lib
      \- ejbs.jar


I am deploying the with default classloading mechanism (I believe it is
parent-first).  But based on the
https://docs.jboss.org/author/display/WFLY10/Class+Loading+in+WildFly, I
seem to understand that the Local Resources (ie: classes within my WAR)
would have a higher dependence than those from the EAR:

In order of highest priority to lowest priority
>
>    1. System Dependencies - These are dependencies that are added to the
>    module automatically by the container, including the Java EE api's.
>    2. User Dependencies - These are dependencies that are added through
>    jboss-deployment-structure.xml or through the Dependencies: manifest
>    entry.
>    3. Local Resource - Class files packaged up inside the deployment
>    itself, e.g. class files from WEB-INF/classes or WEB-INF/lib of a war.
>    4. Inter deployment dependencies - These are dependencies on other
>    deployments in an ear deployment. This can include classes in an ear's lib
>    directory, or classes defined in other ejb jars.
>
>
If that is the case, is my problem that I have the EJB implementation class
in my WAR as well?  Is my war only supposed to have a copy of the
LoginManager interface and not the actual impl code as well?  Wouldn't that
still cause an issue in that my EJB interface and implementation is in the
root/ejbs.jar and I have an additional copy of the interface in my war?

Thanks,

Eric


On Mon, Apr 17, 2017 at 6:01 PM, Stuart Douglas <sdouglas at redhat.com> wrote:

> It sounds like a class loading problem. You likely have two copies of
> ejbs.LoginManager, and somehow you are using the wrong one. If you
> look at the output of
> System.out.println(LoginManager.class.getClassLoader()) and
> System.out.println(CDI.current().select(clazz).get().
> getClass().getClassLoader())
> it should give you a clue.
>
> This is not an Undertow issue.
>
> Stuart
>
> On Fri, Apr 14, 2017 at 11:52 AM, Eric B <ebenzacar at gmail.com> wrote:
> > I posted this problem on StackOverflow, but after doing more research,
> I'm
> > not sure if this is a Weld, JBoss/WildFly or undertow issue.  Or whether
> its
> > a framework issue, or how the framework is being used.  If this is not
> the
> > correct list, can you please let me know which list/group I should be
> > directing the issue to?
> >
> > I'm running into a strange problem and error message that I do not
> > understand. I'm running my application on JBoss 7 EAP.
> >
> > Caused by: java.lang.ClassCastException: Cannot cast
> > ejbs.LoginManager$417755913$Proxy$_$$_Weld$EnterpriseProxy$ to
> > ejbs.LoginManager
> >
> > I'm trying to programatically retrieve an EJB from the CDI context by
> using
> > its interface and am getting this error message. I've created a sample
> > proof-of-concept that is trying to retrieve EJB beans from the CDI
> context
> >
> > public <T> T getSesionBean(Class<T> clazz, String name) {
> >     Properties properties = new Properties();
> >
> >     try {
> >         InitialContext initContext = new InitialContext();
> >
> >         return clazz.cast(CDI.current().select(clazz).get());
> >     } catch (Exception e) {
> >         // TODO Auto-generated catch block
> >         throw new RuntimeException(e);
> >     }
> > }
> >
> > It is being called as:
> >
> > LoginManager login = getSesionBean(LoginManager.class);
> >
> > with my EJB defined as:
> >
> > @Stateless(name="LoginManager")
> > @Local(LoginManager.class)
> > @LocalBinding(jndiBinding="LoginManager")
> > public class LoginManagerBean implements LoginManager {
> > ...
> > ...
> > ...
> > }
> >
> > I don't understand it. I'm expecting the bean being retrieved from the
> > context to be a proxy. Shouldn't it be castable to my interface?
> Otherwise,
> > how am I supposed to retrieve it?
> >
> > More interestingly, this does not seem to be a consistent error;
> sometimes
> > the code works fine. Sometimes it fails. I haven't been able to determine
> > what makes it work or throw an exception.
> >
> > I found a related issue here, but not sure if this is the same problem
> > and/or which version of Weld is used in JB7EAP. I'm including the
> following
> > dependency in my application:
> >
> >     <dependency>
> >         <groupId>org.wildfly</groupId>
> >         <artifactId>wildfly-ejb-client-bom</artifactId>
> >         <version>10.1.0.Final</version>
> >         <type>pom</type>
> >     </dependency>
> >
> > Am I doing something completely wrong? If this is a Weld bug, can I use a
> > different proxy system than Weld?  Is this even configurable in undertow?
> >
> >
> > Thanks,
> >
> >
> > Eric
> >
> >
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170420/3298e2dc/attachment.html 

From sdouglas at redhat.com  Thu Apr 20 18:01:33 2017
From: sdouglas at redhat.com (Stuart Douglas)
Date: Fri, 21 Apr 2017 08:01:33 +1000
Subject: [undertow-dev] Cannot Add the alpn-boot jar to WildFly's Boot
	Classpath
In-Reply-To: <CAP4fEymcz6qd5oRUtHMYAiMqBdH0WhDocEy7eg700H52PoUuLw@mail.gmail.com>
References: <CAP4fEymC6nW_D3sKV=AtRCmt+COTs04n+8M3vCcQhr8WEGRrbg@mail.gmail.com>
	<CAMquZP6r+WCOSbspaBZLPZopXoHxUtqq8YpmPkCGKwi3kvMM1Q@mail.gmail.com>
	<CAP4fEymcz6qd5oRUtHMYAiMqBdH0WhDocEy7eg700H52PoUuLw@mail.gmail.com>
Message-ID: <CAD+L2cxNRBffy--YCrV-mfeJ7f0yKM-nLjZpokX=qVVW4R3xAQ@mail.gmail.com>

On Fri, Apr 21, 2017 at 1:17 AM, Hanan Othman <hothman at webalo.com> wrote:
> Yes, I am. The same jar works outside of WildFly.
>
> Can you tell me about the other solution that WildFly 10.1 uses?

It uses a different approach that does not require replacing the boot
class path jars. It should just work out of the box on any Oracle or
OpenJDK JVM.

Stuart

>
> On Thu, Apr 20, 2017 at 4:42 PM, Toma? Cerar <tomaz.cerar at gmail.com> wrote:
>>
>> Hey,
>>
>> are you using proper version of apln-boot jar that applies to your exact
>> version of jdk?
>>
>> Since 10.1, WildFly itself doesn't use the apln-boot hack anymore since,
>> but uses different solution in undertow that doesn't require patching jdk
>> classes.
>>
>> --
>> tomaz
>>
>> On Thu, Apr 20, 2017 at 3:58 PM, Hanan Othman <hothman at webalo.com> wrote:
>>>
>>> Hello undertow-dev,
>>>
>>> I'm trying to use WildFly to send a push notification to iOS devices,
>>> which requires the use of HTTP/2. Using OkHttp
>>> (http://square.github.io/okhttp/), I was able to send a request successfully
>>> in an external java project using the JVM option:
>>> -Xbootclasspath/p:<path-to-alpn-boot-jar>.
>>>
>>> After checking the documentation here:
>>> http://undertow.io/blog/2015/03/26/HTTP2-In-Wildfly.html, I was unable to do
>>> the same in WildFly. When I run the server I get:
>>>
>>> okhttp3.OkHttpClient  -- ALPN callback dropped: SPDY and HTTP/2 are
>>> disabled. Is alpn-boot on the boot class path?
>>>
>>>
>>> which leads me to think that it is not actually on the classpath. I have
>>> the same configuration as that in the blog post, except having Wildfly
>>> 10.0.1.Final instead of Wildfly 9.0.0.Beta1. I have the correct alpn-boot
>>> jar version since it already works outside of WildFly, but I do not know
>>> what else I could be missing. Thank you very much for your time.
>>>
>>> Best,
>>> Hanan
>>>
>>> _______________________________________________
>>> undertow-dev mailing list
>>> undertow-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>
>>
>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev


From mkouba at redhat.com  Fri Apr 21 03:44:41 2017
From: mkouba at redhat.com (Martin Kouba)
Date: Fri, 21 Apr 2017 09:44:41 +0200
Subject: [undertow-dev] ClassCastException when retrieving a beans from
 CDI with Weld Proxy beans
In-Reply-To: <CA+T+PjFw3qiJqLur8YqSLb6vyfkVW_R6Kk_r99HYFgg3NoVRdA@mail.gmail.com>
References: <CA+T+PjGa_Aho0iU-762igo4uWZkw1+U27vx39SCmPeyFUZU-kg@mail.gmail.com>
	<CAD+L2cx3uPw5Jrd4TqhkUDRF8DZF9a0+r8eTUSMRK9TiNyZdOg@mail.gmail.com>
	<CA+T+PjFw3qiJqLur8YqSLb6vyfkVW_R6Kk_r99HYFgg3NoVRdA@mail.gmail.com>
Message-ID: <94362254-45ac-12a0-612b-860c97977dd8@redhat.com>

Hi Eric,

I wouldn't recommend to use CDI.current().select() to lookup session 
beans at all. From CDI POV, if you do a lookup from the ejbs.jar you 
should not see the bean from the webapp.war.

Also note that having a class deployed in two different bean archives is 
non-portable, see also 12.1. Bean archives:
"If a bean class is deployed in two different bean archives, 
non-portable behavior results...". [1] In real life having this causes 
similar CL/casting issues, esp. in EARs.

In any case, this is not an Undertow issue and we should move this 
discussion to Weld or WildFly channels.

Martin

[1]
http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bean_archive

Dne 20.4.2017 v 20:04 Eric B napsal(a):
> Indeed, it was an issue with duplicate copies of the class.  But I'm
> still not convinced I should be getting this error.  Is this aou
> parent-first vs parent-last class loading issue?
>
> The LoginManager.class is part of my ejbs.jar archive.
>
> In my EAR, I had the following
> - ejbs.jar
> - webapp.war
>    \- WEB-INF/lib
>       \- ejbs.jar
>
>
> I am deploying the with default classloading mechanism (I believe it is
> parent-first).  But based on the
> https://docs.jboss.org/author/display/WFLY10/Class+Loading+in+WildFly, I
> seem to understand that the Local Resources (ie: classes within my WAR)
> would have a higher dependence than those from the EAR:
>
>     In order of highest priority to lowest priority
>
>      1. System Dependencies - These are dependencies that are added to
>         the module automatically by the container, including the Java EE
>         api's.
>      2. User Dependencies - These are dependencies that are added
>         through jboss-deployment-structure.xml or through
>         the Dependencies: manifest entry.
>      3. Local Resource - Class files packaged up inside the deployment
>         itself, e.g. class files from WEB-INF/classes or WEB-INF/lib of
>         a war.
>      4. Inter deployment dependencies - These are dependencies on other
>         deployments in an ear deployment. This can include classes in an
>         ear's lib directory, or classes defined in other ejb jars.
>
>
> If that is the case, is my problem that I have the EJB implementation
> class in my WAR as well?  Is my war only supposed to have a copy of the
> LoginManager interface and not the actual impl code as well?  Wouldn't
> that still cause an issue in that my EJB interface and implementation is
> in the root/ejbs.jar and I have an additional copy of the interface in
> my war?
>
> Thanks,
>
> Eric
>
>
> On Mon, Apr 17, 2017 at 6:01 PM, Stuart Douglas <sdouglas at redhat.com
> <mailto:sdouglas at redhat.com>> wrote:
>
>     It sounds like a class loading problem. You likely have two copies of
>     ejbs.LoginManager, and somehow you are using the wrong one. If you
>     look at the output of
>     System.out.println(LoginManager.class.getClassLoader()) and
>     System.out.println(CDI.current().select(clazz).get().getClass().getClassLoader())
>     it should give you a clue.
>
>     This is not an Undertow issue.
>
>     Stuart
>
>     On Fri, Apr 14, 2017 at 11:52 AM, Eric B <ebenzacar at gmail.com
>     <mailto:ebenzacar at gmail.com>> wrote:
>     > I posted this problem on StackOverflow, but after doing more
>     research, I'm
>     > not sure if this is a Weld, JBoss/WildFly or undertow issue.  Or
>     whether its
>     > a framework issue, or how the framework is being used.  If this is
>     not the
>     > correct list, can you please let me know which list/group I should be
>     > directing the issue to?
>     >
>     > I'm running into a strange problem and error message that I do not
>     > understand. I'm running my application on JBoss 7 EAP.
>     >
>     > Caused by: java.lang.ClassCastException: Cannot cast
>     > ejbs.LoginManager$417755913$Proxy$_$$_Weld$EnterpriseProxy$ to
>     > ejbs.LoginManager
>     >
>     > I'm trying to programatically retrieve an EJB from the CDI context
>     by using
>     > its interface and am getting this error message. I've created a sample
>     > proof-of-concept that is trying to retrieve EJB beans from the CDI
>     context
>     >
>     > public <T> T getSesionBean(Class<T> clazz, String name) {
>     >     Properties properties = new Properties();
>     >
>     >     try {
>     >         InitialContext initContext = new InitialContext();
>     >
>     >         return clazz.cast(CDI.current().select(clazz).get());
>     >     } catch (Exception e) {
>     >         // TODO Auto-generated catch block
>     >         throw new RuntimeException(e);
>     >     }
>     > }
>     >
>     > It is being called as:
>     >
>     > LoginManager login = getSesionBean(LoginManager.class);
>     >
>     > with my EJB defined as:
>     >
>     > @Stateless(name="LoginManager")
>     > @Local(LoginManager.class)
>     > @LocalBinding(jndiBinding="LoginManager")
>     > public class LoginManagerBean implements LoginManager {
>     > ...
>     > ...
>     > ...
>     > }
>     >
>     > I don't understand it. I'm expecting the bean being retrieved from the
>     > context to be a proxy. Shouldn't it be castable to my interface?
>     Otherwise,
>     > how am I supposed to retrieve it?
>     >
>     > More interestingly, this does not seem to be a consistent error;
>     sometimes
>     > the code works fine. Sometimes it fails. I haven't been able to
>     determine
>     > what makes it work or throw an exception.
>     >
>     > I found a related issue here, but not sure if this is the same problem
>     > and/or which version of Weld is used in JB7EAP. I'm including the
>     following
>     > dependency in my application:
>     >
>     >     <dependency>
>     >         <groupId>org.wildfly</groupId>
>     >         <artifactId>wildfly-ejb-client-bom</artifactId>
>     >         <version>10.1.0.Final</version>
>     >         <type>pom</type>
>     >     </dependency>
>     >
>     > Am I doing something completely wrong? If this is a Weld bug, can
>     I use a
>     > different proxy system than Weld?  Is this even configurable in
>     undertow?
>     >
>     >
>     > Thanks,
>     >
>     >
>     > Eric
>     >
>     >
>     > _______________________________________________
>     > undertow-dev mailing list
>     > undertow-dev at lists.jboss.org <mailto:undertow-dev at lists.jboss.org>
>     > https://lists.jboss.org/mailman/listinfo/undertow-dev
>     <https://lists.jboss.org/mailman/listinfo/undertow-dev>
>
>
>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic

From hothman at webalo.com  Fri Apr 21 14:57:09 2017
From: hothman at webalo.com (Hanan Othman)
Date: Fri, 21 Apr 2017 20:57:09 +0200
Subject: [undertow-dev] Cannot Add the alpn-boot jar to WildFly's Boot
	Classpath
In-Reply-To: <CAD+L2cxNRBffy--YCrV-mfeJ7f0yKM-nLjZpokX=qVVW4R3xAQ@mail.gmail.com>
References: <CAP4fEymC6nW_D3sKV=AtRCmt+COTs04n+8M3vCcQhr8WEGRrbg@mail.gmail.com>
	<CAMquZP6r+WCOSbspaBZLPZopXoHxUtqq8YpmPkCGKwi3kvMM1Q@mail.gmail.com>
	<CAP4fEymcz6qd5oRUtHMYAiMqBdH0WhDocEy7eg700H52PoUuLw@mail.gmail.com>
	<CAD+L2cxNRBffy--YCrV-mfeJ7f0yKM-nLjZpokX=qVVW4R3xAQ@mail.gmail.com>
Message-ID: <CAP4fEy=1gcrxkSGh4OnF4VJBjqy4zACH_QMYnZokGO5u+8BRZA@mail.gmail.com>

So what you mean is that I should be able to use OkHttp inside WildFly
10.1 without having to do any additional setup? Might there be a reason
why this is not what I am seeing currently?

On Fri, Apr 21, 2017 at 12:01 AM, Stuart Douglas <sdouglas at redhat.com>
wrote:

> On Fri, Apr 21, 2017 at 1:17 AM, Hanan Othman <hothman at webalo.com> wrote:
> > Yes, I am. The same jar works outside of WildFly.
> >
> > Can you tell me about the other solution that WildFly 10.1 uses?
>
> It uses a different approach that does not require replacing the boot
> class path jars. It should just work out of the box on any Oracle or
> OpenJDK JVM.
>
> Stuart
>
> >
> > On Thu, Apr 20, 2017 at 4:42 PM, Toma? Cerar <tomaz.cerar at gmail.com>
> wrote:
> >>
> >> Hey,
> >>
> >> are you using proper version of apln-boot jar that applies to your exact
> >> version of jdk?
> >>
> >> Since 10.1, WildFly itself doesn't use the apln-boot hack anymore since,
> >> but uses different solution in undertow that doesn't require patching
> jdk
> >> classes.
> >>
> >> --
> >> tomaz
> >>
> >> On Thu, Apr 20, 2017 at 3:58 PM, Hanan Othman <hothman at webalo.com>
> wrote:
> >>>
> >>> Hello undertow-dev,
> >>>
> >>> I'm trying to use WildFly to send a push notification to iOS devices,
> >>> which requires the use of HTTP/2. Using OkHttp
> >>> (http://square.github.io/okhttp/), I was able to send a request
> successfully
> >>> in an external java project using the JVM option:
> >>> -Xbootclasspath/p:<path-to-alpn-boot-jar>.
> >>>
> >>> After checking the documentation here:
> >>> http://undertow.io/blog/2015/03/26/HTTP2-In-Wildfly.html, I was
> unable to do
> >>> the same in WildFly. When I run the server I get:
> >>>
> >>> okhttp3.OkHttpClient  -- ALPN callback dropped: SPDY and HTTP/2 are
> >>> disabled. Is alpn-boot on the boot class path?
> >>>
> >>>
> >>> which leads me to think that it is not actually on the classpath. I
> have
> >>> the same configuration as that in the blog post, except having Wildfly
> >>> 10.0.1.Final instead of Wildfly 9.0.0.Beta1. I have the correct
> alpn-boot
> >>> jar version since it already works outside of WildFly, but I do not
> know
> >>> what else I could be missing. Thank you very much for your time.
> >>>
> >>> Best,
> >>> Hanan
> >>>
> >>> _______________________________________________
> >>> undertow-dev mailing list
> >>> undertow-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/undertow-dev
> >>
> >>
> >
> >
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170421/95f51239/attachment.html 

From alon.zamir at hpe.com  Sun Apr 23 07:51:36 2017
From: alon.zamir at hpe.com (Zamir, Alon)
Date: Sun, 23 Apr 2017 11:51:36 +0000
Subject: [undertow-dev] Proxing with SSL Termination
Message-ID: <CS1PR84MB030948922CADB2596212F6CE871C0@CS1PR84MB0309.NAMPRD84.PROD.OUTLOOK.COM>

Is there an SSL Termination support to be used in conjunction with reverse proxy server ?
I'd like to implement an SSL server which terminates the SSL request and proxies plain HTTP to a remote server.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170423/4945ce4b/attachment.html 

From sdouglas at redhat.com  Sun Apr 23 19:27:39 2017
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 24 Apr 2017 09:27:39 +1000
Subject: [undertow-dev] Proxing with SSL Termination
In-Reply-To: <CS1PR84MB030948922CADB2596212F6CE871C0@CS1PR84MB0309.NAMPRD84.PROD.OUTLOOK.COM>
References: <CS1PR84MB030948922CADB2596212F6CE871C0@CS1PR84MB0309.NAMPRD84.PROD.OUTLOOK.COM>
Message-ID: <CAD+L2czgj5AfPbZWEdZFGrxcJ2z8CpHer_zONE1_jTkNpJb+Jw@mail.gmail.com>

Sure, you just add an SSL listener to the Undertow instance.

If you want to forward SSL information as a header you can do
something like this:


proxyHandler.addRequestHeader(Headers.SSL_CLIENT_CERT,
"%{SSL_CLIENT_CERT}", DefaultServer.class.getClassLoader());
proxyHandler.addRequestHeader(Headers.SSL_CIPHER, "%{SSL_CIPHER}",
DefaultServer.class.getClassLoader());
proxyHandler.addRequestHeader(Headers.SSL_SESSION_ID,
"%{SSL_SESSION_ID}", DefaultServer.class.getClassLoader());

Which will make the SSL information available on the backend as a header.

Stuart

On Sun, Apr 23, 2017 at 9:51 PM, Zamir, Alon <alon.zamir at hpe.com> wrote:
> Is there an SSL Termination support to be used in conjunction with reverse
> proxy server ?
>
> I?d like to implement an SSL server which terminates the SSL request and
> proxies plain HTTP to a remote server.
>
>
>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev


From sdouglas at redhat.com  Mon Apr 24 00:24:44 2017
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 24 Apr 2017 14:24:44 +1000
Subject: [undertow-dev] Cannot Add the alpn-boot jar to WildFly's Boot
	Classpath
In-Reply-To: <CAP4fEy=1gcrxkSGh4OnF4VJBjqy4zACH_QMYnZokGO5u+8BRZA@mail.gmail.com>
References: <CAP4fEymC6nW_D3sKV=AtRCmt+COTs04n+8M3vCcQhr8WEGRrbg@mail.gmail.com>
	<CAMquZP6r+WCOSbspaBZLPZopXoHxUtqq8YpmPkCGKwi3kvMM1Q@mail.gmail.com>
	<CAP4fEymcz6qd5oRUtHMYAiMqBdH0WhDocEy7eg700H52PoUuLw@mail.gmail.com>
	<CAD+L2cxNRBffy--YCrV-mfeJ7f0yKM-nLjZpokX=qVVW4R3xAQ@mail.gmail.com>
	<CAP4fEy=1gcrxkSGh4OnF4VJBjqy4zACH_QMYnZokGO5u+8BRZA@mail.gmail.com>
Message-ID: <CAD+L2cxXUwoBS-LALAc39jZy-QW2TR59t1DHUaU_hv2Z839aKg@mail.gmail.com>

Ah, I just skim read your first email and did not realize you were
talking about the OkHttp client, and not the native Undertow
client/server. Even though Undertow has support for ALPN natively
using other clients will require the jar.

How have you attempted to add the jar to the boot class path? You
probably want to add it to JAVA_OPTS in standalone.conf.

Stuart

On Sat, Apr 22, 2017 at 4:57 AM, Hanan Othman <hothman at webalo.com> wrote:
> So what you mean is that I should be able to use OkHttp inside WildFly
> 10.1 without having to do any additional setup? Might there be a reason
> why this is not what I am seeing currently?
>
> On Fri, Apr 21, 2017 at 12:01 AM, Stuart Douglas <sdouglas at redhat.com>
> wrote:
>>
>> On Fri, Apr 21, 2017 at 1:17 AM, Hanan Othman <hothman at webalo.com> wrote:
>> > Yes, I am. The same jar works outside of WildFly.
>> >
>> > Can you tell me about the other solution that WildFly 10.1 uses?
>>
>> It uses a different approach that does not require replacing the boot
>> class path jars. It should just work out of the box on any Oracle or
>> OpenJDK JVM.
>>
>> Stuart
>>
>> >
>> > On Thu, Apr 20, 2017 at 4:42 PM, Toma? Cerar <tomaz.cerar at gmail.com>
>> > wrote:
>> >>
>> >> Hey,
>> >>
>> >> are you using proper version of apln-boot jar that applies to your
>> >> exact
>> >> version of jdk?
>> >>
>> >> Since 10.1, WildFly itself doesn't use the apln-boot hack anymore
>> >> since,
>> >> but uses different solution in undertow that doesn't require patching
>> >> jdk
>> >> classes.
>> >>
>> >> --
>> >> tomaz
>> >>
>> >> On Thu, Apr 20, 2017 at 3:58 PM, Hanan Othman <hothman at webalo.com>
>> >> wrote:
>> >>>
>> >>> Hello undertow-dev,
>> >>>
>> >>> I'm trying to use WildFly to send a push notification to iOS devices,
>> >>> which requires the use of HTTP/2. Using OkHttp
>> >>> (http://square.github.io/okhttp/), I was able to send a request
>> >>> successfully
>> >>> in an external java project using the JVM option:
>> >>> -Xbootclasspath/p:<path-to-alpn-boot-jar>.
>> >>>
>> >>> After checking the documentation here:
>> >>> http://undertow.io/blog/2015/03/26/HTTP2-In-Wildfly.html, I was unable
>> >>> to do
>> >>> the same in WildFly. When I run the server I get:
>> >>>
>> >>> okhttp3.OkHttpClient  -- ALPN callback dropped: SPDY and HTTP/2 are
>> >>> disabled. Is alpn-boot on the boot class path?
>> >>>
>> >>>
>> >>> which leads me to think that it is not actually on the classpath. I
>> >>> have
>> >>> the same configuration as that in the blog post, except having Wildfly
>> >>> 10.0.1.Final instead of Wildfly 9.0.0.Beta1. I have the correct
>> >>> alpn-boot
>> >>> jar version since it already works outside of WildFly, but I do not
>> >>> know
>> >>> what else I could be missing. Thank you very much for your time.
>> >>>
>> >>> Best,
>> >>> Hanan
>> >>>
>> >>> _______________________________________________
>> >>> undertow-dev mailing list
>> >>> undertow-dev at lists.jboss.org
>> >>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>> >>
>> >>
>> >
>> >
>> > _______________________________________________
>> > undertow-dev mailing list
>> > undertow-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>
>


From hothman at webalo.com  Mon Apr 24 00:45:44 2017
From: hothman at webalo.com (Hanan Othman)
Date: Mon, 24 Apr 2017 04:45:44 +0000
Subject: [undertow-dev] Cannot Add the alpn-boot jar to WildFly's Boot
	Classpath
In-Reply-To: <CAD+L2cxXUwoBS-LALAc39jZy-QW2TR59t1DHUaU_hv2Z839aKg@mail.gmail.com>
References: <CAP4fEymC6nW_D3sKV=AtRCmt+COTs04n+8M3vCcQhr8WEGRrbg@mail.gmail.com>
	<CAMquZP6r+WCOSbspaBZLPZopXoHxUtqq8YpmPkCGKwi3kvMM1Q@mail.gmail.com>
	<CAP4fEymcz6qd5oRUtHMYAiMqBdH0WhDocEy7eg700H52PoUuLw@mail.gmail.com>
	<CAD+L2cxNRBffy--YCrV-mfeJ7f0yKM-nLjZpokX=qVVW4R3xAQ@mail.gmail.com>
	<CAP4fEy=1gcrxkSGh4OnF4VJBjqy4zACH_QMYnZokGO5u+8BRZA@mail.gmail.com>
	<CAD+L2cxXUwoBS-LALAc39jZy-QW2TR59t1DHUaU_hv2Z839aKg@mail.gmail.com>
Message-ID: <CAP4fEy=c6GRfZy0s94UTQLfWLzqMB_ZATSt5LgG6m=CtNvz6Uw@mail.gmail.com>

Yes I have done that as described in the blog post:
http://undertow.io/blog/2015/03/26/HTTP2-In-Wildfly.html.

The script shown in the post fails with output:

{

    "outcome" => "failed",

    "failure-description" => {

        "WFLYCTL0080: Failed services" => {"jboss.undertow.listener.https"
=> "org.jboss.msc.service.StartException in service
jboss.undertow.listener.https: Failed to start service

    Caused by: java.lang.IllegalStateException: WFLYUT0079: No SSL Context
available from security realm. Either the realm is not configured for SSL,
or the server has not been reloaded since the SSL config was added."},

        "WFLYCTL0412: Required services that are not installed:" =>
["jboss.undertow.listener.https"],

        "WFLYCTL0180: Services with missing/unavailable dependencies" =>
undefined

    },

    "rolled-back" => true,

    "response-headers" => {"process-state" => "reload-required"}

}


On Mon, Apr 24, 2017 at 6:24 AM Stuart Douglas <sdouglas at redhat.com> wrote:

> Ah, I just skim read your first email and did not realize you were
> talking about the OkHttp client, and not the native Undertow
> client/server. Even though Undertow has support for ALPN natively
> using other clients will require the jar.
>
> How have you attempted to add the jar to the boot class path? You
> probably want to add it to JAVA_OPTS in standalone.conf.
>
> Stuart
>
> On Sat, Apr 22, 2017 at 4:57 AM, Hanan Othman <hothman at webalo.com> wrote:
> > So what you mean is that I should be able to use OkHttp inside WildFly
> > 10.1 without having to do any additional setup? Might there be a reason
> > why this is not what I am seeing currently?
> >
> > On Fri, Apr 21, 2017 at 12:01 AM, Stuart Douglas <sdouglas at redhat.com>
> > wrote:
> >>
> >> On Fri, Apr 21, 2017 at 1:17 AM, Hanan Othman <hothman at webalo.com>
> wrote:
> >> > Yes, I am. The same jar works outside of WildFly.
> >> >
> >> > Can you tell me about the other solution that WildFly 10.1 uses?
> >>
> >> It uses a different approach that does not require replacing the boot
> >> class path jars. It should just work out of the box on any Oracle or
> >> OpenJDK JVM.
> >>
> >> Stuart
> >>
> >> >
> >> > On Thu, Apr 20, 2017 at 4:42 PM, Toma? Cerar <tomaz.cerar at gmail.com>
> >> > wrote:
> >> >>
> >> >> Hey,
> >> >>
> >> >> are you using proper version of apln-boot jar that applies to your
> >> >> exact
> >> >> version of jdk?
> >> >>
> >> >> Since 10.1, WildFly itself doesn't use the apln-boot hack anymore
> >> >> since,
> >> >> but uses different solution in undertow that doesn't require patching
> >> >> jdk
> >> >> classes.
> >> >>
> >> >> --
> >> >> tomaz
> >> >>
> >> >> On Thu, Apr 20, 2017 at 3:58 PM, Hanan Othman <hothman at webalo.com>
> >> >> wrote:
> >> >>>
> >> >>> Hello undertow-dev,
> >> >>>
> >> >>> I'm trying to use WildFly to send a push notification to iOS
> devices,
> >> >>> which requires the use of HTTP/2. Using OkHttp
> >> >>> (http://square.github.io/okhttp/), I was able to send a request
> >> >>> successfully
> >> >>> in an external java project using the JVM option:
> >> >>> -Xbootclasspath/p:<path-to-alpn-boot-jar>.
> >> >>>
> >> >>> After checking the documentation here:
> >> >>> http://undertow.io/blog/2015/03/26/HTTP2-In-Wildfly.html, I was
> unable
> >> >>> to do
> >> >>> the same in WildFly. When I run the server I get:
> >> >>>
> >> >>> okhttp3.OkHttpClient  -- ALPN callback dropped: SPDY and HTTP/2 are
> >> >>> disabled. Is alpn-boot on the boot class path?
> >> >>>
> >> >>>
> >> >>> which leads me to think that it is not actually on the classpath. I
> >> >>> have
> >> >>> the same configuration as that in the blog post, except having
> Wildfly
> >> >>> 10.0.1.Final instead of Wildfly 9.0.0.Beta1. I have the correct
> >> >>> alpn-boot
> >> >>> jar version since it already works outside of WildFly, but I do not
> >> >>> know
> >> >>> what else I could be missing. Thank you very much for your time.
> >> >>>
> >> >>> Best,
> >> >>> Hanan
> >> >>>
> >> >>> _______________________________________________
> >> >>> undertow-dev mailing list
> >> >>> undertow-dev at lists.jboss.org
> >> >>> https://lists.jboss.org/mailman/listinfo/undertow-dev
> >> >>
> >> >>
> >> >
> >> >
> >> > _______________________________________________
> >> > undertow-dev mailing list
> >> > undertow-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/undertow-dev
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170424/ce07d762/attachment-0001.html 

From rhatlapa at redhat.com  Mon Apr 24 04:57:00 2017
From: rhatlapa at redhat.com (Radim Hatlapatka)
Date: Mon, 24 Apr 2017 10:57:00 +0200
Subject: [undertow-dev] Cannot Add the alpn-boot jar to WildFly's Boot
 Classpath
In-Reply-To: <CAP4fEy=c6GRfZy0s94UTQLfWLzqMB_ZATSt5LgG6m=CtNvz6Uw@mail.gmail.com>
References: <CAP4fEymC6nW_D3sKV=AtRCmt+COTs04n+8M3vCcQhr8WEGRrbg@mail.gmail.com>
	<CAMquZP6r+WCOSbspaBZLPZopXoHxUtqq8YpmPkCGKwi3kvMM1Q@mail.gmail.com>
	<CAP4fEymcz6qd5oRUtHMYAiMqBdH0WhDocEy7eg700H52PoUuLw@mail.gmail.com>
	<CAD+L2cxNRBffy--YCrV-mfeJ7f0yKM-nLjZpokX=qVVW4R3xAQ@mail.gmail.com>
	<CAP4fEy=1gcrxkSGh4OnF4VJBjqy4zACH_QMYnZokGO5u+8BRZA@mail.gmail.com>
	<CAD+L2cxXUwoBS-LALAc39jZy-QW2TR59t1DHUaU_hv2Z839aKg@mail.gmail.com>
	<CAP4fEy=c6GRfZy0s94UTQLfWLzqMB_ZATSt5LgG6m=CtNvz6Uw@mail.gmail.com>
Message-ID: <16bc471a-76c3-9ee3-1ec8-b7e7466eddbf@redhat.com>

Hi Hanan,

there is issue in the script. After you create the security-realm 
(before creating the https listener) you need to reload the server. 
Reloading the server should fix the issue you are describing bellow.

Cheers.

Radim


On 04/24/2017 06:45 AM, Hanan Othman wrote:
> Yes I have done that as described in the blog post: 
> http://undertow.io/blog/2015/03/26/HTTP2-In-Wildfly.html.
>
> The script shown in the post fails with output:
>
> {
>
> "outcome" => "failed",
>
> "failure-description" => {
>
> "WFLYCTL0080: Failed services" => {"jboss.undertow.listener.https" => 
> "org.jboss.msc.service.StartException in service 
> jboss.undertow.listener.https: Failed to start service
>
> Caused by: java.lang.IllegalStateException: WFLYUT0079: No SSL Context 
> available from security realm. Either the realm is not configured for 
> SSL, or the server has not been reloaded since the SSL config was 
> added."},
>
> "WFLYCTL0412: Required services that are not installed:" => 
> ["jboss.undertow.listener.https"],
>
> "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
>
>     },
>
> "rolled-back" => true,
>
> "response-headers" => {"process-state" => "reload-required"}
>
> }
>
>
> On Mon, Apr 24, 2017 at 6:24 AM Stuart Douglas <sdouglas at redhat.com 
> <mailto:sdouglas at redhat.com>> wrote:
>
>     Ah, I just skim read your first email and did not realize you were
>     talking about the OkHttp client, and not the native Undertow
>     client/server. Even though Undertow has support for ALPN natively
>     using other clients will require the jar.
>
>     How have you attempted to add the jar to the boot class path? You
>     probably want to add it to JAVA_OPTS in standalone.conf.
>
>     Stuart
>
>     On Sat, Apr 22, 2017 at 4:57 AM, Hanan Othman <hothman at webalo.com
>     <mailto:hothman at webalo.com>> wrote:
>     > So what you mean is that I should be able to use OkHttp inside
>     WildFly
>     > 10.1 without having to do any additional setup? Might there be a
>     reason
>     > why this is not what I am seeing currently?
>     >
>     > On Fri, Apr 21, 2017 at 12:01 AM, Stuart Douglas
>     <sdouglas at redhat.com <mailto:sdouglas at redhat.com>>
>     > wrote:
>     >>
>     >> On Fri, Apr 21, 2017 at 1:17 AM, Hanan Othman
>     <hothman at webalo.com <mailto:hothman at webalo.com>> wrote:
>     >> > Yes, I am. The same jar works outside of WildFly.
>     >> >
>     >> > Can you tell me about the other solution that WildFly 10.1 uses?
>     >>
>     >> It uses a different approach that does not require replacing
>     the boot
>     >> class path jars. It should just work out of the box on any
>     Oracle or
>     >> OpenJDK JVM.
>     >>
>     >> Stuart
>     >>
>     >> >
>     >> > On Thu, Apr 20, 2017 at 4:42 PM, Toma? Cerar
>     <tomaz.cerar at gmail.com <mailto:tomaz.cerar at gmail.com>>
>     >> > wrote:
>     >> >>
>     >> >> Hey,
>     >> >>
>     >> >> are you using proper version of apln-boot jar that applies
>     to your
>     >> >> exact
>     >> >> version of jdk?
>     >> >>
>     >> >> Since 10.1, WildFly itself doesn't use the apln-boot hack
>     anymore
>     >> >> since,
>     >> >> but uses different solution in undertow that doesn't require
>     patching
>     >> >> jdk
>     >> >> classes.
>     >> >>
>     >> >> --
>     >> >> tomaz
>     >> >>
>     >> >> On Thu, Apr 20, 2017 at 3:58 PM, Hanan Othman
>     <hothman at webalo.com <mailto:hothman at webalo.com>>
>     >> >> wrote:
>     >> >>>
>     >> >>> Hello undertow-dev,
>     >> >>>
>     >> >>> I'm trying to use WildFly to send a push notification to
>     iOS devices,
>     >> >>> which requires the use of HTTP/2. Using OkHttp
>     >> >>> (http://square.github.io/okhttp/), I was able to send a request
>     >> >>> successfully
>     >> >>> in an external java project using the JVM option:
>     >> >>> -Xbootclasspath/p:<path-to-alpn-boot-jar>.
>     >> >>>
>     >> >>> After checking the documentation here:
>     >> >>> http://undertow.io/blog/2015/03/26/HTTP2-In-Wildfly.html, I
>     was unable
>     >> >>> to do
>     >> >>> the same in WildFly. When I run the server I get:
>     >> >>>
>     >> >>> okhttp3.OkHttpClient  -- ALPN callback dropped: SPDY and
>     HTTP/2 are
>     >> >>> disabled. Is alpn-boot on the boot class path?
>     >> >>>
>     >> >>>
>     >> >>> which leads me to think that it is not actually on the
>     classpath. I
>     >> >>> have
>     >> >>> the same configuration as that in the blog post, except
>     having Wildfly
>     >> >>> 10.0.1.Final instead of Wildfly 9.0.0.Beta1. I have the correct
>     >> >>> alpn-boot
>     >> >>> jar version since it already works outside of WildFly, but
>     I do not
>     >> >>> know
>     >> >>> what else I could be missing. Thank you very much for your
>     time.
>     >> >>>
>     >> >>> Best,
>     >> >>> Hanan
>     >> >>>
>     >> >>> _______________________________________________
>     >> >>> undertow-dev mailing list
>     >> >>> undertow-dev at lists.jboss.org
>     <mailto:undertow-dev at lists.jboss.org>
>     >> >>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>     >> >>
>     >> >>
>     >> >
>     >> >
>     >> > _______________________________________________
>     >> > undertow-dev mailing list
>     >> > undertow-dev at lists.jboss.org
>     <mailto:undertow-dev at lists.jboss.org>
>     >> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>     >
>     >
>
>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170424/944ba3f9/attachment.html 

From paroczizs at gmail.com  Wed Apr 26 16:36:35 2017
From: paroczizs at gmail.com (paroczizs .)
Date: Wed, 26 Apr 2017 22:36:35 +0200
Subject: [undertow-dev] Reverse proxy blocked connection after 503
Message-ID: <CACb-xVWOO_9DteO+vsZ8h8yvTkTeiAmdQows7reCTiGbONjO5g@mail.gmail.com>

Hi Undertow-dev,

we are using the Wildfly(10.1)/Undertow as reverse proxy and facing the
following issue:

The back end hots behind the reverse proxy are load balanced and ssl
terminated by HaProxy. When the real back ends are shutdown the Undertow
responds the request immediately with 503 error that sends by the HaProxy.
This behavior happens as many times as many connections are set to the
reverse proxy. After the max connections/thread are exceeded the responses
are stucked and wit for the connection timeout. It seems to me that after
the 503 may the HaProxy wants to close the socket but the Undertow keeps it
alive but not allow to be accessed by new request. It is released after a
while my the operating system free the socket or there are default idle
timeout and the undertow renew the stucked connections.

Are there any configuration that solves the above issue?

Thank you forward, Zsolt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170426/098d92dd/attachment.html 

From sdouglas at redhat.com  Wed Apr 26 18:22:05 2017
From: sdouglas at redhat.com (Stuart Douglas)
Date: Thu, 27 Apr 2017 08:22:05 +1000
Subject: [undertow-dev] Reverse proxy blocked connection after 503
In-Reply-To: <CACb-xVWOO_9DteO+vsZ8h8yvTkTeiAmdQows7reCTiGbONjO5g@mail.gmail.com>
References: <CACb-xVWOO_9DteO+vsZ8h8yvTkTeiAmdQows7reCTiGbONjO5g@mail.gmail.com>
Message-ID: <CAD+L2cw449=a0Fs+f77GPLEqC7rfrnQe1fXiPKOGtTgBxPEizw@mail.gmail.com>

What state are the sockets on the balancer left in while this is going on?

Also can you try upgrading the version of Undertow in Wildfly to
1.4.13.Final? Its possible this issue is already fixed.

Stuart

On Thu, Apr 27, 2017 at 6:36 AM, paroczizs . <paroczizs at gmail.com> wrote:
> Hi Undertow-dev,
>
> we are using the Wildfly(10.1)/Undertow as reverse proxy and facing the
> following issue:
>
> The back end hots behind the reverse proxy are load balanced and ssl
> terminated by HaProxy. When the real back ends are shutdown the Undertow
> responds the request immediately with 503 error that sends by the HaProxy.
> This behavior happens as many times as many connections are set to the
> reverse proxy. After the max connections/thread are exceeded the responses
> are stucked and wit for the connection timeout. It seems to me that after
> the 503 may the HaProxy wants to close the socket but the Undertow keeps it
> alive but not allow to be accessed by new request. It is released after a
> while my the operating system free the socket or there are default idle
> timeout and the undertow renew the stucked connections.
>
> Are there any configuration that solves the above issue?
>
> Thank you forward, Zsolt
>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev