From pbielicki at gmail.com  Wed Apr  2 04:19:46 2014
From: pbielicki at gmail.com (Przemyslaw Bielicki)
Date: Wed, 2 Apr 2014 10:19:46 +0200
Subject: [wildfly-dev] WF 8.0 HTTP Upgrade help needed
In-Reply-To: <CALbcAPV4k5CAZeshaqyH298KpVXJWz+JNnF9NwE9_cGousPYOA@mail.gmail.com>
References: <CAMvdueASMd1kUBSOC7J_dMoiAtC0ovTdQGywATpC3kNoheDDJA@mail.gmail.com>
	<9890BDFE-346B-4BE9-9ABF-50D4AF9535AF@redhat.com>
	<CAMvdueBqtHrAZp7E3at25pM5v48NydBZWg7rDEEnZAUf7CX_ZQ@mail.gmail.com>
	<CALbcAPV4k5CAZeshaqyH298KpVXJWz+JNnF9NwE9_cGousPYOA@mail.gmail.com>
Message-ID: <CAMvdueDwa=hU8uKkdxVWc2AHq290FDELbDuB4zadqceNKubHfg@mail.gmail.com>

Thanks for tips but actually it does not change anything :)

Still there is only the reader that is non-blocking. If you check my
updated example you will see that in the EchoHandler class I added a writer
task which is the only way I found at the moment to have an asynchronous
(yet BLOCKING) way of sending responses to the (telnet) client.

What I noticed is that Read and Write listeners are kind of mutually
exclusive i.e. when I set a WriteListener and ReadListener, the read part
will be NEVER called. When I set only ReadListener it's OK but then I'm not
able to write ServletOutputStream in a non-blocking way. I checked the
Servlet 3.1 specification, which documents Upgrade part very poorly and
they do not say anything about such limitations. I could try to set the
WriterListener from within ReadListener but subsequent calls to
setWriteListener throw IllegalStateException, which does not follow
strictly the specification:

Section 3.7:
"A subsequent call to setReadListener in the scope of the current request
is illegal and an IllegalStateException MUST be thrown."

Section 5.3 (symmetrical to 3.7 but regarding the write):
says nothing about IllegalStateExceptionin in case of subsequent calls to
setWriteListener

There was a presentation during JavaOne 2013 showing the upgrade mechanism,
but of course Oracle guys did not show the good pieces:
https://www.youtube.com/watch?v=LX8tchFSpnA

In conclusion, I am able to read in a non-blocking manner and write in a
blocking way. Anyone has an example how to use non-blocking read and write
streams?

Cheers,
Przemyslaw




On Fri, Mar 28, 2014 at 9:31 PM, Jim McGuinness <dador92 at gmail.com> wrote:

> So here's what I'm getting (my source code is attached) ...
>
>
> __Telnet__
>
> dador-iMac:~ dador$ telnet 10.0.1.14 8080
>
> Trying 10.0.1.14...
>
> Connected to 10.0.1.14.
>
> Escape character is '^]'.
>
> GET /wildfly-debug/upgrade HTTP/1.1
>
> Connection: upgrade
>
>
> HTTP/1.1 101 Switching Protocols
>
> Connection: Upgrade
>
> X-Powered-By: Undertow 1
>
> Server: Wildfly 8
>
> Content-Length: 0
>
> Date: Fri, 28 Mar 2014 20:22:36 GMT
>
>
> the quick brown fox blah, blah, blah
>
> ^]
>
> telnet> quit
>
> Connection closed.
>
> dador-iMac:~ dador$
>
>
> __console___
>
> 15:22:36,825 INFO  [stdout] (default task-15) servlet doGet() received
> 'upgrade'
>
> 15:22:46,488 INFO  [stdout] (default I/O-3) listener onDataAvailable()
> called
>
> 15:22:46,488 INFO  [stdout] (default I/O-3) listener read 'the quick brown
> fox blah, blah, blah'; successfully offered to queue
>
> 15:22:46,489 INFO  [stdout] (default I/O-3) listener read ''; successfully
> offered to queue
>
> 15:22:56,824 INFO  [stdout] (default I/O-3) listener onDataAvailable()
> called
>
> 15:22:56,824 INFO  [stdout] (default I/O-3) listener onAllDataRead() called
>
> 15:22:56,824 INFO  [stdout] (default I/O-3) here is data queued ...
>
> 15:22:56,825 INFO  [stdout] (default I/O-3) the quick brown fox blah,
> blah, blah
>
> 15:22:56,825 INFO  [stdout] (default I/O-3)
>
> 15:22:56,825 INFO  [stdout] (default I/O-3)
>
> 15:22:56,825 INFO  [stdout] (default I/O-3) now do something
>
>
> So the queue is getting the data as it's being piped in (the blanks in the
> queued data are telnet line feeds). But I have to send a signal to the
> servlet that all of the data has been sent (I simply close the telnet
> connection). Then the listener's onAllDataRead() method gets called.
>
> So maybe this is a configuration issue. By the way, it made a difference
> for me in the telnet session when I specified the Connection as "upgrade"
> versus "Upgrade".
>
> Just a suggestion, but you may also want to take a look at the
> non-blocking I/O if you input stream is a long one.
>
> Good luck,
>
> --Jim.
>
>
> On Fri, Mar 28, 2014 at 3:05 PM, PB <pbielicki at gmail.com> wrote:
>
>> Hi,
>>
>> I dare to say that my code is correct ;) The problem is that it is NEVER
>> called - this condition (even if it's wrong, however it's not) is never
>> checked. When I remove this line:
>>
>> out.setWriteListener(new EchoWriteListener(queue, out));
>>
>> it seems to work. However, I have no writer, so it should be rather
>> called SwallowListener... It's not my goal.
>>
>> Maybe I should initialize WriteListener from the ReadListener after the
>> first read? Or maybe, when I want to send back the response I should do
>> this directly from the read listener? e.g.
>> https://java.net/projects/tyrus/sources/source-code-repository/content/trunk/containers/servlet/src/main/java/org/glassfish/tyrus/servlet/TyrusHttpUpgradeHandler.java
>>
>> Thanks,
>> Przemyslaw
>>
>>
>> On Fri, Mar 28, 2014 at 5:14 PM, Heiko Braun <hbraun at redhat.com> wrote:
>>
>>> At a first glance, I'd say your while{} block never returns. Is
>>> ServletInputStream.isFinished() what you've been looking for, instead of
>>> isReady()
>>>
>>> On 28 Mar 2014, at 16:26, PB <pbielicki at gmail.com> wrote:
>>>
>>> while (in.isReady()) {
>>>
>>>
>>>   --
>>>
>>> http://about.me/hbraun
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140402/917a0543/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: EchoHandler.java
Type: application/octet-stream
Size: 1477 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140402/917a0543/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: EchoReadListener.java
Type: application/octet-stream
Size: 1050 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140402/917a0543/attachment-0001.obj 

From stuart.w.douglas at gmail.com  Thu Apr  3 00:18:17 2014
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Thu, 03 Apr 2014 15:18:17 +1100
Subject: [wildfly-dev] WF 8.0 HTTP Upgrade help needed
In-Reply-To: <CAMvdueASMd1kUBSOC7J_dMoiAtC0ovTdQGywATpC3kNoheDDJA@mail.gmail.com>
References: <CAMvdueASMd1kUBSOC7J_dMoiAtC0ovTdQGywATpC3kNoheDDJA@mail.gmail.com>
Message-ID: <533CE109.1030602@gmail.com>

Can you try with the latest development build of Wildfly (from 
https://ci.jboss.org/hudson/job/WildFly-latest-master/).

There have been some fixes in this area, so your problem may have 
already been fixed.

Stuart


PB wrote:
> Hi,
>
> I'm testing the HTTP Upgrade feature of WF 8.0 and I'm facing some banal
> problem. Basically my ReadListener is NEVER called.
> Here's the code:
>
> @WebServlet(urlPatterns = "/upgrade")
> public class UpgradeServlet extends HttpServlet {
>    @Override
>    protected void doGet(HttpServletRequest req, HttpServletResponse
> resp) throws ServletException, IOException {
>      if ("upgrade".equalsIgnoreCase(req.getHeader("Connection"))) {
>        req.upgrade(EchoHandler.class);
>      }
>    }
> }
>
> public class EchoHandler implements HttpUpgradeHandler {
>    @Override
>    public void init(WebConnection wc) {
>      try {
>        ServletInputStream in = wc.getInputStream();
>        ServletOutputStream out = wc.getOutputStream();
>
>        BlockingQueue<String> queue = new LinkedBlockingQueue<String>();
>        in.setReadListener(new EchoReadListener(queue, in));
>        out.setWriteListener(new EchoWriteListener(queue, out));
>      } catch (IOException e) {
>        throw new IllegalStateException(e);
>      }
>    }
>
> public class EchoReadListener implements ReadListener {
>    @Override
>    public void onDataAvailable() throws IOException {
>      while (in.isReady()) {
>        int length = in.read(buffer);
>        String input = new String(buffer, 0, length);
>        if (false == queue.offer(input)) {
>          System.err.println("'" + input + "' input was ignored");
>        }
>      }
>    }
>
> I'm connecting to WF using telnet and sending the upgrade request:
> GET /example-webapp/upgrade HTTP/1.1
> Host: localhost
> Connection: upgrade
> Upgrade: echo
>
> and I'm getting correct response:
>
> HTTP/1.1 101 Switching Protocols
> Connection: Upgrade
> X-Powered-By: Undertow 1
> Server: Wildfly 8
> Content-Length: 0
>
> which means that from now on the protocol between my telnet client and
> WF is pure TCP.
> So, I start typing some text, hit Enter and.... nothing happens.
> onDataAvailable() is NEVER called. More so, this makes WF totally
> irresponsive - my whole webapp is dead.
>
> I believe, I'm doing something wrong - any ideas what exactly? There is
> also a slight chance that Upgrade feature in WF is f****d :)
> Anyway, WF should not block even in case my upgraded protocol is not
> working correctly?
>
> Many thanks,
> Przemyslaw
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

From pbielicki at gmail.com  Thu Apr  3 09:21:07 2014
From: pbielicki at gmail.com (Przemyslaw Bielicki)
Date: Thu, 3 Apr 2014 15:21:07 +0200
Subject: [wildfly-dev] WF 8.0 HTTP Upgrade help needed
In-Reply-To: <533CE109.1030602@gmail.com>
References: <CAMvdueASMd1kUBSOC7J_dMoiAtC0ovTdQGywATpC3kNoheDDJA@mail.gmail.com>
	<533CE109.1030602@gmail.com>
Message-ID: <CAMvdueDggP8i1b9=c42V+ChumA-KL_oSWUmhuR_-kv7xBjSOyg@mail.gmail.com>

I tried - exactly the same results.

Another weird observation is that ServletOutputStream.isReady() is
returning true even after the connection is closed
(ServletInputStream.isFinished() is correctly returning true).

Here's the scenario that works but I can write back the data only once:
1. In HttpUpgradeHandler I set only  the ReadListener
2. I switch the protocol and send some data
3. ReadListener gets activated i.e. onDataAvailable() is called.
4. I process the input data, read as much as possible and put the input
into the queue
5. From within ReadListener I set the WriteListener
6. WriteListener.onWritePossible() gets called and I process the data - I
clean the queue
7. As long as I'm in WriteListener.onWritePossible() (while.out.isReady()
is constantly returning true, which is a correct bahavior) the ReadListener
is on-hold. I can send as much data as I like but onDataAvailable() is not
called
8. Only when I leave WriteListener.onWritePossible() method the
ReadListener.onDataAvailable() is called again and I can consume the input
data again.
9. I can process the input data again i.e. put it into the queue but
WriteListener.onWritePossible() is never called again. When I try to reset
it I get IllegalStateException

Either the specification or implementation seem not very mature.... Wildfly
behavior is consistent with the one of Tomcat.

At the moment I conclude that the non-blocking write is not possible in
Servlet 3.1.

I would appreciate if someone can provide an example that actually works or
explain why the weird behavior I observe is correct (is it?)

Cheers,
Przemyslaw




On Thu, Apr 3, 2014 at 6:18 AM, Stuart Douglas
<stuart.w.douglas at gmail.com>wrote:

> Can you try with the latest development build of Wildfly (from
> https://ci.jboss.org/hudson/job/WildFly-latest-master/).
>
> There have been some fixes in this area, so your problem may have already
> been fixed.
>
> Stuart
>
>
> PB wrote:
>
>> Hi,
>>
>> I'm testing the HTTP Upgrade feature of WF 8.0 and I'm facing some banal
>> problem. Basically my ReadListener is NEVER called.
>> Here's the code:
>>
>> @WebServlet(urlPatterns = "/upgrade")
>> public class UpgradeServlet extends HttpServlet {
>>    @Override
>>    protected void doGet(HttpServletRequest req, HttpServletResponse
>> resp) throws ServletException, IOException {
>>      if ("upgrade".equalsIgnoreCase(req.getHeader("Connection"))) {
>>        req.upgrade(EchoHandler.class);
>>      }
>>    }
>> }
>>
>> public class EchoHandler implements HttpUpgradeHandler {
>>    @Override
>>    public void init(WebConnection wc) {
>>      try {
>>        ServletInputStream in = wc.getInputStream();
>>        ServletOutputStream out = wc.getOutputStream();
>>
>>        BlockingQueue<String> queue = new LinkedBlockingQueue<String>();
>>        in.setReadListener(new EchoReadListener(queue, in));
>>        out.setWriteListener(new EchoWriteListener(queue, out));
>>      } catch (IOException e) {
>>        throw new IllegalStateException(e);
>>      }
>>    }
>>
>> public class EchoReadListener implements ReadListener {
>>    @Override
>>    public void onDataAvailable() throws IOException {
>>      while (in.isReady()) {
>>        int length = in.read(buffer);
>>        String input = new String(buffer, 0, length);
>>        if (false == queue.offer(input)) {
>>          System.err.println("'" + input + "' input was ignored");
>>        }
>>      }
>>    }
>>
>> I'm connecting to WF using telnet and sending the upgrade request:
>> GET /example-webapp/upgrade HTTP/1.1
>> Host: localhost
>> Connection: upgrade
>> Upgrade: echo
>>
>> and I'm getting correct response:
>>
>> HTTP/1.1 101 Switching Protocols
>> Connection: Upgrade
>> X-Powered-By: Undertow 1
>> Server: Wildfly 8
>> Content-Length: 0
>>
>> which means that from now on the protocol between my telnet client and
>> WF is pure TCP.
>> So, I start typing some text, hit Enter and.... nothing happens.
>> onDataAvailable() is NEVER called. More so, this makes WF totally
>> irresponsive - my whole webapp is dead.
>>
>> I believe, I'm doing something wrong - any ideas what exactly? There is
>> also a slight chance that Upgrade feature in WF is f****d :)
>> Anyway, WF should not block even in case my upgraded protocol is not
>> working correctly?
>>
>> Many thanks,
>> Przemyslaw
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140403/21e42b08/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: EchoHandler.java
Type: application/octet-stream
Size: 850 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140403/21e42b08/attachment-0003.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: EchoReadListener.java
Type: application/octet-stream
Size: 1298 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140403/21e42b08/attachment-0004.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: EchoWriteListener.java
Type: application/octet-stream
Size: 1031 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140403/21e42b08/attachment-0005.obj 

From rmaucher at redhat.com  Thu Apr  3 10:41:38 2014
From: rmaucher at redhat.com (=?ISO-8859-1?Q?R=E9my_Maucherat?=)
Date: Thu, 03 Apr 2014 16:41:38 +0200
Subject: [wildfly-dev] WF 8.0 HTTP Upgrade help needed
In-Reply-To: <CAMvdueDggP8i1b9=c42V+ChumA-KL_oSWUmhuR_-kv7xBjSOyg@mail.gmail.com>
References: <CAMvdueASMd1kUBSOC7J_dMoiAtC0ovTdQGywATpC3kNoheDDJA@mail.gmail.com>	<533CE109.1030602@gmail.com>
	<CAMvdueDggP8i1b9=c42V+ChumA-KL_oSWUmhuR_-kv7xBjSOyg@mail.gmail.com>
Message-ID: <533D7322.9050906@redhat.com>

On 03/04/2014 15:21, Przemyslaw Bielicki wrote:
> I tried - exactly the same results.
>
> Another weird observation is that ServletOutputStream.isReady() is 
> returning true even after the connection is closed 
> (ServletInputStream.isFinished() is correctly returning true).
>
> Here's the scenario that works but I can write back the data only once:
> 1. In HttpUpgradeHandler I set only  the ReadListener
> 2. I switch the protocol and send some data
> 3. ReadListener gets activated i.e. onDataAvailable() is called.
> 4. I process the input data, read as much as possible and put the 
> input into the queue
> 5. From within ReadListener I set the WriteListener
> 6. WriteListener.onWritePossible() gets called and I process the data 
> - I clean the queue
> 7. As long as I'm in WriteListener.onWritePossible() 
> (while.out.isReady() is constantly returning true, which is a correct 
> bahavior) the ReadListener is on-hold. I can send as much data as I 
> like but onDataAvailable() is not called
> 8. Only when I leave WriteListener.onWritePossible() method the 
> ReadListener.onDataAvailable() is called again and I can consume the 
> input data again.
> 9. I can process the input data again i.e. put it into the queue but 
> WriteListener.onWritePossible() is never called again. When I try to 
> reset it I get IllegalStateException
>
> Either the specification or implementation seem not very mature.... 
> Wildfly behavior is consistent with the one of Tomcat.
>
> At the moment I conclude that the non-blocking write is not possible 
> in Servlet 3.1.
>
> I would appreciate if someone can provide an example that actually 
> works or explain why the weird behavior I observe is correct (is it?)
This looks as expected (although Tomcat 8 should concurrently call 
read/write in upgraded mode, as a proprietary extension to be able to 
implement Websockets on top of Servlets 3.1, besides that Servlet 3.1 is 
still not concurrent, so at most one thread processing a request a given 
time).

Non blocking IO means it allows avoiding to block on IO, it doesn't 
imply anything else. Servlets 3.1 is actually async IO (similar to NIO2, 
rather than NIO1), since non blocking IO is unusable as is.

R?my


From pbielicki at gmail.com  Thu Apr  3 10:52:19 2014
From: pbielicki at gmail.com (Przemyslaw Bielicki)
Date: Thu, 3 Apr 2014 16:52:19 +0200
Subject: [wildfly-dev] WF 8.0 HTTP Upgrade help needed
In-Reply-To: <533D7322.9050906@redhat.com>
References: <CAMvdueASMd1kUBSOC7J_dMoiAtC0ovTdQGywATpC3kNoheDDJA@mail.gmail.com>
	<533CE109.1030602@gmail.com>
	<CAMvdueDggP8i1b9=c42V+ChumA-KL_oSWUmhuR_-kv7xBjSOyg@mail.gmail.com>
	<533D7322.9050906@redhat.com>
Message-ID: <CAMvdueAah7vg81NK_yfcmbhZmZ75hLmFxrzikE=YZj2Hv8Rp8w@mail.gmail.com>

As I showed  I'm not able to read and write at the same time using
non-blocking IO, as promised by Servlet 3.1. I'm able to read using
non-blocking IO but my writes are blocking and I'm looking for the solution.

Regarding concurrent access, HTTP Upgrade promises that the upgraded
protocol will be full-duplex, so I should be able to read and write
concurrently but I'm not.

Another comment is that Servlets 3.1 is actually async ONLY from the server
point of view - the client is still blocked because HTTP 1.1 is synchronous
(we have to wait for HTTP 2.0 to solve this). Here Upgrade should help as
it is a pure TCP, so I'm the master of my protocol and I'm no longer bound
to HTTP - I can be as asynchronous as I want. Unfortunately Servlet 3.1 API
does not respect this.

It looks like the specification is not meeting the promises given....


On Thu, Apr 3, 2014 at 4:41 PM, R?my Maucherat <rmaucher at redhat.com> wrote:

> On 03/04/2014 15:21, Przemyslaw Bielicki wrote:
> > I tried - exactly the same results.
> >
> > Another weird observation is that ServletOutputStream.isReady() is
> > returning true even after the connection is closed
> > (ServletInputStream.isFinished() is correctly returning true).
> >
> > Here's the scenario that works but I can write back the data only once:
> > 1. In HttpUpgradeHandler I set only  the ReadListener
> > 2. I switch the protocol and send some data
> > 3. ReadListener gets activated i.e. onDataAvailable() is called.
> > 4. I process the input data, read as much as possible and put the
> > input into the queue
> > 5. From within ReadListener I set the WriteListener
> > 6. WriteListener.onWritePossible() gets called and I process the data
> > - I clean the queue
> > 7. As long as I'm in WriteListener.onWritePossible()
> > (while.out.isReady() is constantly returning true, which is a correct
> > bahavior) the ReadListener is on-hold. I can send as much data as I
> > like but onDataAvailable() is not called
> > 8. Only when I leave WriteListener.onWritePossible() method the
> > ReadListener.onDataAvailable() is called again and I can consume the
> > input data again.
> > 9. I can process the input data again i.e. put it into the queue but
> > WriteListener.onWritePossible() is never called again. When I try to
> > reset it I get IllegalStateException
> >
> > Either the specification or implementation seem not very mature....
> > Wildfly behavior is consistent with the one of Tomcat.
> >
> > At the moment I conclude that the non-blocking write is not possible
> > in Servlet 3.1.
> >
> > I would appreciate if someone can provide an example that actually
> > works or explain why the weird behavior I observe is correct (is it?)
> This looks as expected (although Tomcat 8 should concurrently call
> read/write in upgraded mode, as a proprietary extension to be able to
> implement Websockets on top of Servlets 3.1, besides that Servlet 3.1 is
> still not concurrent, so at most one thread processing a request a given
> time).
>
> Non blocking IO means it allows avoiding to block on IO, it doesn't
> imply anything else. Servlets 3.1 is actually async IO (similar to NIO2,
> rather than NIO1), since non blocking IO is unusable as is.
>
> R?my
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140403/f9b5ed17/attachment.html 

From jgreene at redhat.com  Thu Apr  3 14:31:06 2014
From: jgreene at redhat.com (Jason T. Greene)
Date: Thu, 3 Apr 2014 14:31:06 -0400 (EDT)
Subject: [wildfly-dev] WF 8.0 HTTP Upgrade help needed
In-Reply-To: <CAMvdueAah7vg81NK_yfcmbhZmZ75hLmFxrzikE=YZj2Hv8Rp8w@mail.gmail.com>
References: <CAMvdueASMd1kUBSOC7J_dMoiAtC0ovTdQGywATpC3kNoheDDJA@mail.gmail.com>
	<533CE109.1030602@gmail.com>
	<CAMvdueDggP8i1b9=c42V+ChumA-KL_oSWUmhuR_-kv7xBjSOyg@mail.gmail.com>
	<533D7322.9050906@redhat.com>
	<CAMvdueAah7vg81NK_yfcmbhZmZ75hLmFxrzikE=YZj2Hv8Rp8w@mail.gmail.com>
Message-ID: <65DE649E-56BC-4B1B-8C07-BCA2ED9B1F5A@redhat.com>

Let me play with your use case, although it will be a few hours before I can get to it.

There are some limitations to the spec, but they are manageable. As an example the write is actually written for you in a non blocking fashion. It's basically an async deferred write. 

The undertow http handler API is, in my opinion a much better fit for pure non-blocking / reactive applications. 

> On Apr 3, 2014, at 9:52 AM, Przemyslaw Bielicki <pbielicki at gmail.com> wrote:
> 
> As I showed  I'm not able to read and write at the same time using non-blocking IO, as promised by Servlet 3.1. I'm able to read using non-blocking IO but my writes are blocking and I'm looking for the solution.
> 
> Regarding concurrent access, HTTP Upgrade promises that the upgraded protocol will be full-duplex, so I should be able to read and write concurrently but I'm not.
> 
> Another comment is that Servlets 3.1 is actually async ONLY from the server point of view - the client is still blocked because HTTP 1.1 is synchronous (we have to wait for HTTP 2.0 to solve this). Here Upgrade should help as it is a pure TCP, so I'm the master of my protocol and I'm no longer bound to HTTP - I can be as asynchronous as I want. Unfortunately Servlet 3.1 API does not respect this.
> 
> It looks like the specification is not meeting the promises given....
> 
> 
>> On Thu, Apr 3, 2014 at 4:41 PM, R?my Maucherat <rmaucher at redhat.com> wrote:
>> On 03/04/2014 15:21, Przemyslaw Bielicki wrote:
>> > I tried - exactly the same results.
>> >
>> > Another weird observation is that ServletOutputStream.isReady() is
>> > returning true even after the connection is closed
>> > (ServletInputStream.isFinished() is correctly returning true).
>> >
>> > Here's the scenario that works but I can write back the data only once:
>> > 1. In HttpUpgradeHandler I set only  the ReadListener
>> > 2. I switch the protocol and send some data
>> > 3. ReadListener gets activated i.e. onDataAvailable() is called.
>> > 4. I process the input data, read as much as possible and put the
>> > input into the queue
>> > 5. From within ReadListener I set the WriteListener
>> > 6. WriteListener.onWritePossible() gets called and I process the data
>> > - I clean the queue
>> > 7. As long as I'm in WriteListener.onWritePossible()
>> > (while.out.isReady() is constantly returning true, which is a correct
>> > bahavior) the ReadListener is on-hold. I can send as much data as I
>> > like but onDataAvailable() is not called
>> > 8. Only when I leave WriteListener.onWritePossible() method the
>> > ReadListener.onDataAvailable() is called again and I can consume the
>> > input data again.
>> > 9. I can process the input data again i.e. put it into the queue but
>> > WriteListener.onWritePossible() is never called again. When I try to
>> > reset it I get IllegalStateException
>> >
>> > Either the specification or implementation seem not very mature....
>> > Wildfly behavior is consistent with the one of Tomcat.
>> >
>> > At the moment I conclude that the non-blocking write is not possible
>> > in Servlet 3.1.
>> >
>> > I would appreciate if someone can provide an example that actually
>> > works or explain why the weird behavior I observe is correct (is it?)
>> This looks as expected (although Tomcat 8 should concurrently call
>> read/write in upgraded mode, as a proprietary extension to be able to
>> implement Websockets on top of Servlets 3.1, besides that Servlet 3.1 is
>> still not concurrent, so at most one thread processing a request a given
>> time).
>> 
>> Non blocking IO means it allows avoiding to block on IO, it doesn't
>> imply anything else. Servlets 3.1 is actually async IO (similar to NIO2,
>> rather than NIO1), since non blocking IO is unusable as is.
>> 
>> R?my
>> 
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140403/b6412816/attachment.html 

From pbielicki at gmail.com  Thu Apr  3 14:42:38 2014
From: pbielicki at gmail.com (Przemyslaw Bielicki)
Date: Thu, 3 Apr 2014 20:42:38 +0200
Subject: [wildfly-dev] WF 8.0 HTTP Upgrade help needed
In-Reply-To: <65DE649E-56BC-4B1B-8C07-BCA2ED9B1F5A@redhat.com>
References: <CAMvdueASMd1kUBSOC7J_dMoiAtC0ovTdQGywATpC3kNoheDDJA@mail.gmail.com>
	<533CE109.1030602@gmail.com>
	<CAMvdueDggP8i1b9=c42V+ChumA-KL_oSWUmhuR_-kv7xBjSOyg@mail.gmail.com>
	<533D7322.9050906@redhat.com>
	<CAMvdueAah7vg81NK_yfcmbhZmZ75hLmFxrzikE=YZj2Hv8Rp8w@mail.gmail.com>
	<65DE649E-56BC-4B1B-8C07-BCA2ED9B1F5A@redhat.com>
Message-ID: <CAMvdueD4C1i2_6Mrw8CF1nM2_U8x9sqAnOXJ72NzHWfnYDRXsQ@mail.gmail.com>

Hi Jason,

that would be great. I appreciate.

Take your time, it's not super urgent but I would like to have a complete
example of the full-duplex upgrade mechanism using standard API. Then I
would be more than interested in seeing how I can employ undertow to do the
job :)

Cheers,
Przemyslaw
3 kwi 2014 20:31 "Jason T. Greene" <jgreene at redhat.com> napisa?(a):

> Let me play with your use case, although it will be a few hours before I
> can get to it.
>
> There are some limitations to the spec, but they are manageable. As an
> example the write is actually written for you in a non blocking fashion.
> It's basically an async deferred write.
>
> The undertow http handler API is, in my opinion a much better fit for pure
> non-blocking / reactive applications.
>
> On Apr 3, 2014, at 9:52 AM, Przemyslaw Bielicki <pbielicki at gmail.com>
> wrote:
>
> As I showed  I'm not able to read and write at the same time using
> non-blocking IO, as promised by Servlet 3.1. I'm able to read using
> non-blocking IO but my writes are blocking and I'm looking for the solution.
>
> Regarding concurrent access, HTTP Upgrade promises that the upgraded
> protocol will be full-duplex, so I should be able to read and write
> concurrently but I'm not.
>
> Another comment is that Servlets 3.1 is actually async ONLY from the
> server point of view - the client is still blocked because HTTP 1.1 is
> synchronous (we have to wait for HTTP 2.0 to solve this). Here Upgrade
> should help as it is a pure TCP, so I'm the master of my protocol and I'm
> no longer bound to HTTP - I can be as asynchronous as I want. Unfortunately
> Servlet 3.1 API does not respect this.
>
> It looks like the specification is not meeting the promises given....
>
>
> On Thu, Apr 3, 2014 at 4:41 PM, R?my Maucherat <rmaucher at redhat.com>wrote:
>
>> On 03/04/2014 15:21, Przemyslaw Bielicki wrote:
>> > I tried - exactly the same results.
>> >
>> > Another weird observation is that ServletOutputStream.isReady() is
>> > returning true even after the connection is closed
>> > (ServletInputStream.isFinished() is correctly returning true).
>> >
>> > Here's the scenario that works but I can write back the data only once:
>> > 1. In HttpUpgradeHandler I set only  the ReadListener
>> > 2. I switch the protocol and send some data
>> > 3. ReadListener gets activated i.e. onDataAvailable() is called.
>> > 4. I process the input data, read as much as possible and put the
>> > input into the queue
>> > 5. From within ReadListener I set the WriteListener
>> > 6. WriteListener.onWritePossible() gets called and I process the data
>> > - I clean the queue
>> > 7. As long as I'm in WriteListener.onWritePossible()
>> > (while.out.isReady() is constantly returning true, which is a correct
>> > bahavior) the ReadListener is on-hold. I can send as much data as I
>> > like but onDataAvailable() is not called
>> > 8. Only when I leave WriteListener.onWritePossible() method the
>> > ReadListener.onDataAvailable() is called again and I can consume the
>> > input data again.
>> > 9. I can process the input data again i.e. put it into the queue but
>> > WriteListener.onWritePossible() is never called again. When I try to
>> > reset it I get IllegalStateException
>> >
>> > Either the specification or implementation seem not very mature....
>> > Wildfly behavior is consistent with the one of Tomcat.
>> >
>> > At the moment I conclude that the non-blocking write is not possible
>> > in Servlet 3.1.
>> >
>> > I would appreciate if someone can provide an example that actually
>> > works or explain why the weird behavior I observe is correct (is it?)
>> This looks as expected (although Tomcat 8 should concurrently call
>> read/write in upgraded mode, as a proprietary extension to be able to
>> implement Websockets on top of Servlets 3.1, besides that Servlet 3.1 is
>> still not concurrent, so at most one thread processing a request a given
>> time).
>>
>> Non blocking IO means it allows avoiding to block on IO, it doesn't
>> imply anything else. Servlets 3.1 is actually async IO (similar to NIO2,
>> rather than NIO1), since non blocking IO is unusable as is.
>>
>> R?my
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140403/6cbcfaa4/attachment-0001.html 

From stuart.w.douglas at gmail.com  Thu Apr  3 18:33:15 2014
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Fri, 04 Apr 2014 09:33:15 +1100
Subject: [wildfly-dev] WF 8.0 HTTP Upgrade help needed
In-Reply-To: <CAMvdueDggP8i1b9=c42V+ChumA-KL_oSWUmhuR_-kv7xBjSOyg@mail.gmail.com>
References: <CAMvdueASMd1kUBSOC7J_dMoiAtC0ovTdQGywATpC3kNoheDDJA@mail.gmail.com>
	<533CE109.1030602@gmail.com>
	<CAMvdueDggP8i1b9=c42V+ChumA-KL_oSWUmhuR_-kv7xBjSOyg@mail.gmail.com>
Message-ID: <533DE1AB.1030503@gmail.com>



Przemyslaw Bielicki wrote:
> I tried - exactly the same results.
>
> Another weird observation is that ServletOutputStream.isReady() is
> returning true even after the connection is closed
> (ServletInputStream.isFinished() is correctly returning true).
>
> Here's the scenario that works but I can write back the data only once:
> 1. In HttpUpgradeHandler I set only  the ReadListener
> 2. I switch the protocol and send some data
> 3. ReadListener gets activated i.e. onDataAvailable() is called.
> 4. I process the input data, read as much as possible and put the input
> into the queue
> 5. From within ReadListener I set the WriteListener
> 6. WriteListener.onWritePossible() gets called and I process the data -
> I clean the queue
> 7. As long as I'm in WriteListener.onWritePossible()
> (while.out.isReady() is constantly returning true, which is a correct
> bahavior) the ReadListener is on-hold. I can send as much data as I like
> but onDataAvailable() is not called
> 8. Only when I leave WriteListener.onWritePossible() method the
> ReadListener.onDataAvailable() is called again and I can consume the
> input data again.
> 9. I can process the input data again i.e. put it into the queue but
> WriteListener.onWritePossible() is never called again. When I try to
> reset it I get IllegalStateException
>
> Either the specification or implementation seem not very mature....
> Wildfly behavior is consistent with the one of Tomcat.

As Remy said this is expected.
Basically there is only ever one IO thread per connection, so only one 
method will be active at a time.

The reason why your listener method is not being called again would 
become apparent if you look at the javadoc for the read/write listeners:

Subsequently the container will invoke this method if and only
if {@link javax.servlet.ServletOutputStream#isReady()} method
has been called and has returned <code>false</code>.

Basically what this means is that the listener is only invoked if 
isReady() returns false at some point. If you have read some data and 
then you want to echo it you should call the onWritePossible method 
yourself, after you have received the data.

Stuart



>
> At the moment I conclude that the non-blocking write is not possible in
> Servlet 3.1.
>
> I would appreciate if someone can provide an example that actually works
> or explain why the weird behavior I observe is correct (is it?)
>
> Cheers,
> Przemyslaw
>
>
>
>
> On Thu, Apr 3, 2014 at 6:18 AM, Stuart Douglas
> <stuart.w.douglas at gmail.com <mailto:stuart.w.douglas at gmail.com>> wrote:
>
>     Can you try with the latest development build of Wildfly (from
>     https://ci.jboss.org/hudson/__job/WildFly-latest-master/
>     <https://ci.jboss.org/hudson/job/WildFly-latest-master/>).
>
>     There have been some fixes in this area, so your problem may have
>     already been fixed.
>
>     Stuart
>
>
>     PB wrote:
>
>         Hi,
>
>         I'm testing the HTTP Upgrade feature of WF 8.0 and I'm facing
>         some banal
>         problem. Basically my ReadListener is NEVER called.
>         Here's the code:
>
>         @WebServlet(urlPatterns = "/upgrade")
>         public class UpgradeServlet extends HttpServlet {
>             @Override
>             protected void doGet(HttpServletRequest req, HttpServletResponse
>         resp) throws ServletException, IOException {
>               if
>         ("upgrade".equalsIgnoreCase(__req.getHeader("Connection"))) {
>                 req.upgrade(EchoHandler.class)__;
>               }
>             }
>         }
>
>         public class EchoHandler implements HttpUpgradeHandler {
>             @Override
>             public void init(WebConnection wc) {
>               try {
>                 ServletInputStream in = wc.getInputStream();
>                 ServletOutputStream out = wc.getOutputStream();
>
>                 BlockingQueue<String> queue = new
>         LinkedBlockingQueue<String>();
>                 in.setReadListener(new EchoReadListener(queue, in));
>                 out.setWriteListener(new EchoWriteListener(queue, out));
>               } catch (IOException e) {
>                 throw new IllegalStateException(e);
>               }
>             }
>
>         public class EchoReadListener implements ReadListener {
>             @Override
>             public void onDataAvailable() throws IOException {
>               while (in.isReady()) {
>                 int length = in.read(buffer);
>                 String input = new String(buffer, 0, length);
>                 if (false == queue.offer(input)) {
>                   System.err.println("'" + input + "' input was ignored");
>                 }
>               }
>             }
>
>         I'm connecting to WF using telnet and sending the upgrade request:
>         GET /example-webapp/upgrade HTTP/1.1
>         Host: localhost
>         Connection: upgrade
>         Upgrade: echo
>
>         and I'm getting correct response:
>
>         HTTP/1.1 101 Switching Protocols
>         Connection: Upgrade
>         X-Powered-By: Undertow 1
>         Server: Wildfly 8
>         Content-Length: 0
>
>         which means that from now on the protocol between my telnet
>         client and
>         WF is pure TCP.
>         So, I start typing some text, hit Enter and.... nothing happens.
>         onDataAvailable() is NEVER called. More so, this makes WF totally
>         irresponsive - my whole webapp is dead.
>
>         I believe, I'm doing something wrong - any ideas what exactly?
>         There is
>         also a slight chance that Upgrade feature in WF is f****d :)
>         Anyway, WF should not block even in case my upgraded protocol is not
>         working correctly?
>
>         Many thanks,
>         Przemyslaw
>
>         _________________________________________________
>         wildfly-dev mailing list
>         wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>         https://lists.jboss.org/__mailman/listinfo/wildfly-dev
>         <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>
>

From pbielicki at gmail.com  Fri Apr  4 02:51:07 2014
From: pbielicki at gmail.com (Przemyslaw Bielicki)
Date: Fri, 4 Apr 2014 08:51:07 +0200
Subject: [wildfly-dev] WF 8.0 HTTP Upgrade help needed
In-Reply-To: <533DE1AB.1030503@gmail.com>
References: <CAMvdueASMd1kUBSOC7J_dMoiAtC0ovTdQGywATpC3kNoheDDJA@mail.gmail.com>
	<533CE109.1030602@gmail.com>
	<CAMvdueDggP8i1b9=c42V+ChumA-KL_oSWUmhuR_-kv7xBjSOyg@mail.gmail.com>
	<533DE1AB.1030503@gmail.com>
Message-ID: <CAMvdueDATZO1PQsbShMGjv3CRTGYk1jEfjffq=Lmw0C0rcPz7w@mail.gmail.com>

Hi Stuart,

thx for the explanations. There is a problem anyway - if you set both read
and write listeners from the handler it won't work at all as in the write
listener ServletOutputStream.isReady() will be returning true all the time
(why not? the output is ready to send some data at the same time in is
ready to read some data), and the read listener will be ignored (as the
tread is focused on the writer). The solution here is not to have while
(out.isReady()) loop in the writer but a simple check if (out.isReady()),
but then you have to call onWritePossible yourself. It means you need to
pass a write listener reference to the read listener - it's smells more
than a bit.

I think I have my conclusion, that is: it is impossible to achieve
full-duplex (thus multiplexing) in an upgraded protocol using Servlet 3.1
API as there is "only ever one IO thread per connection" (I didn't find
such limitation in the specification - can you point out the section in
which it is said there should be on thread per connection?). In order to
achieve multiplexing one have to explicitly create a separate thread
dealing with either reading or writing the data.
Also, using Servlet 3.1 it is impossible to achieve non-blocking read and
write and multiplexing on the same connection, even using a separate thread.

I will contact the specification owners to see their opinion.

Many thanks,
Przemyslaw


On Fri, Apr 4, 2014 at 12:33 AM, Stuart Douglas
<stuart.w.douglas at gmail.com>wrote:

>
>
> Przemyslaw Bielicki wrote:
>
>> I tried - exactly the same results.
>>
>> Another weird observation is that ServletOutputStream.isReady() is
>> returning true even after the connection is closed
>> (ServletInputStream.isFinished() is correctly returning true).
>>
>> Here's the scenario that works but I can write back the data only once:
>> 1. In HttpUpgradeHandler I set only  the ReadListener
>> 2. I switch the protocol and send some data
>> 3. ReadListener gets activated i.e. onDataAvailable() is called.
>> 4. I process the input data, read as much as possible and put the input
>> into the queue
>> 5. From within ReadListener I set the WriteListener
>> 6. WriteListener.onWritePossible() gets called and I process the data -
>> I clean the queue
>> 7. As long as I'm in WriteListener.onWritePossible()
>> (while.out.isReady() is constantly returning true, which is a correct
>> bahavior) the ReadListener is on-hold. I can send as much data as I like
>> but onDataAvailable() is not called
>> 8. Only when I leave WriteListener.onWritePossible() method the
>> ReadListener.onDataAvailable() is called again and I can consume the
>> input data again.
>> 9. I can process the input data again i.e. put it into the queue but
>> WriteListener.onWritePossible() is never called again. When I try to
>> reset it I get IllegalStateException
>>
>> Either the specification or implementation seem not very mature....
>> Wildfly behavior is consistent with the one of Tomcat.
>>
>
> As Remy said this is expected.
> Basically there is only ever one IO thread per connection, so only one
> method will be active at a time.
>
> The reason why your listener method is not being called again would become
> apparent if you look at the javadoc for the read/write listeners:
>
> Subsequently the container will invoke this method if and only
> if {@link javax.servlet.ServletOutputStream#isReady()} method
> has been called and has returned <code>false</code>.
>
> Basically what this means is that the listener is only invoked if
> isReady() returns false at some point. If you have read some data and then
> you want to echo it you should call the onWritePossible method yourself,
> after you have received the data.
>
> Stuart
>
>
>
>
>> At the moment I conclude that the non-blocking write is not possible in
>> Servlet 3.1.
>>
>> I would appreciate if someone can provide an example that actually works
>> or explain why the weird behavior I observe is correct (is it?)
>>
>> Cheers,
>> Przemyslaw
>>
>>
>>
>>
>> On Thu, Apr 3, 2014 at 6:18 AM, Stuart Douglas
>> <stuart.w.douglas at gmail.com <mailto:stuart.w.douglas at gmail.com>> wrote:
>>
>>     Can you try with the latest development build of Wildfly (from
>>     https://ci.jboss.org/hudson/__job/WildFly-latest-master/
>>     <https://ci.jboss.org/hudson/job/WildFly-latest-master/>).
>>
>>
>>     There have been some fixes in this area, so your problem may have
>>     already been fixed.
>>
>>     Stuart
>>
>>
>>     PB wrote:
>>
>>         Hi,
>>
>>         I'm testing the HTTP Upgrade feature of WF 8.0 and I'm facing
>>         some banal
>>         problem. Basically my ReadListener is NEVER called.
>>         Here's the code:
>>
>>         @WebServlet(urlPatterns = "/upgrade")
>>         public class UpgradeServlet extends HttpServlet {
>>             @Override
>>             protected void doGet(HttpServletRequest req,
>> HttpServletResponse
>>         resp) throws ServletException, IOException {
>>               if
>>         ("upgrade".equalsIgnoreCase(__req.getHeader("Connection"))) {
>>                 req.upgrade(EchoHandler.class)__;
>>
>>               }
>>             }
>>         }
>>
>>         public class EchoHandler implements HttpUpgradeHandler {
>>             @Override
>>             public void init(WebConnection wc) {
>>               try {
>>                 ServletInputStream in = wc.getInputStream();
>>                 ServletOutputStream out = wc.getOutputStream();
>>
>>                 BlockingQueue<String> queue = new
>>         LinkedBlockingQueue<String>();
>>                 in.setReadListener(new EchoReadListener(queue, in));
>>                 out.setWriteListener(new EchoWriteListener(queue, out));
>>               } catch (IOException e) {
>>                 throw new IllegalStateException(e);
>>               }
>>             }
>>
>>         public class EchoReadListener implements ReadListener {
>>             @Override
>>             public void onDataAvailable() throws IOException {
>>               while (in.isReady()) {
>>                 int length = in.read(buffer);
>>                 String input = new String(buffer, 0, length);
>>                 if (false == queue.offer(input)) {
>>                   System.err.println("'" + input + "' input was ignored");
>>                 }
>>               }
>>             }
>>
>>         I'm connecting to WF using telnet and sending the upgrade request:
>>         GET /example-webapp/upgrade HTTP/1.1
>>         Host: localhost
>>         Connection: upgrade
>>         Upgrade: echo
>>
>>         and I'm getting correct response:
>>
>>         HTTP/1.1 101 Switching Protocols
>>         Connection: Upgrade
>>         X-Powered-By: Undertow 1
>>         Server: Wildfly 8
>>         Content-Length: 0
>>
>>         which means that from now on the protocol between my telnet
>>         client and
>>         WF is pure TCP.
>>         So, I start typing some text, hit Enter and.... nothing happens.
>>         onDataAvailable() is NEVER called. More so, this makes WF totally
>>         irresponsive - my whole webapp is dead.
>>
>>         I believe, I'm doing something wrong - any ideas what exactly?
>>         There is
>>         also a slight chance that Upgrade feature in WF is f****d :)
>>         Anyway, WF should not block even in case my upgraded protocol is
>> not
>>         working correctly?
>>
>>         Many thanks,
>>         Przemyslaw
>>
>>         _________________________________________________
>>         wildfly-dev mailing list
>>         wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>         https://lists.jboss.org/__mailman/listinfo/wildfly-dev
>>         <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140404/1b620ab9/attachment.html 

From stuart.w.douglas at gmail.com  Fri Apr  4 03:02:49 2014
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Fri, 04 Apr 2014 18:02:49 +1100
Subject: [wildfly-dev] WF 8.0 HTTP Upgrade help needed
In-Reply-To: <CAMvdueDATZO1PQsbShMGjv3CRTGYk1jEfjffq=Lmw0C0rcPz7w@mail.gmail.com>
References: <CAMvdueASMd1kUBSOC7J_dMoiAtC0ovTdQGywATpC3kNoheDDJA@mail.gmail.com>
	<533CE109.1030602@gmail.com>
	<CAMvdueDggP8i1b9=c42V+ChumA-KL_oSWUmhuR_-kv7xBjSOyg@mail.gmail.com>
	<533DE1AB.1030503@gmail.com>
	<CAMvdueDATZO1PQsbShMGjv3CRTGYk1jEfjffq=Lmw0C0rcPz7w@mail.gmail.com>
Message-ID: <533E5919.3070902@gmail.com>

Try something like the code below:


public class AsyncEchoUpgradeServlet extends HttpServlet {

     @Override
     protected void doGet(final HttpServletRequest req, final 
HttpServletResponse resp) throws ServletException, IOException {
         req.upgrade(Handler.class);
     }

     public static class Handler implements HttpUpgradeHandler {

         @Override
         public void init(final WebConnection wc) {
             Listener listener = new Listener(wc);
             try {
                 //we have to set the write listener before the read 
listener
                 //otherwise the output stream could be written to 
before it is
                 //in async mode
                 wc.getOutputStream().setWriteListener(listener);
                 wc.getInputStream().setReadListener(listener);
             } catch (IOException e) {
                 UndertowLogger.REQUEST_IO_LOGGER.ioException(e);
             }
         }

         @Override
         public void destroy() {

         }
     }


     private static class Listener implements WriteListener, ReadListener {

         private final WebConnection connection;
         private final Queue<String> queue = new ArrayDeque<String>();

         private Listener(final WebConnection connection) {
             this.connection = connection;
         }

         @Override
         public synchronized void onDataAvailable() throws IOException {
             byte[] data = new byte[100];
             while (connection.getInputStream().isReady()) {
                 int read;
                 if ((read = connection.getInputStream().read(data)) != 
-1) {
                     queue.add(new String(data, 0, read));
                 }
                 onWritePossible();
             }
         }

         @Override
         public void onAllDataRead() throws IOException {

         }

         @Override
         public synchronized void onWritePossible() throws IOException {

             while (!queue.isEmpty() && 
connection.getOutputStream().isReady()) {
                 String data = queue.poll();
                 connection.getOutputStream().write(data.getBytes());
             }
         }

         @Override
         public void onError(final Throwable t) {

         }
     }
}



Przemyslaw Bielicki wrote:
> Hi Stuart,
>
> thx for the explanations. There is a problem anyway - if you set both
> read and write listeners from the handler it won't work at all as in the
> write listener ServletOutputStream.isReady() will be returning true all
> the time (why not? the output is ready to send some data at the same
> time in is ready to read some data), and the read listener will be
> ignored (as the tread is focused on the writer). The solution here is
> not to have while (out.isReady()) loop in the writer but a simple check
> if (out.isReady()), but then you have to call onWritePossible yourself.
> It means you need to pass a write listener reference to the read
> listener - it's smells more than a bit.
>
> I think I have my conclusion, that is: it is impossible to achieve
> full-duplex (thus multiplexing) in an upgraded protocol using Servlet
> 3.1 API as there is "only ever one IO thread per connection" (I didn't
> find such limitation in the specification - can you point out the
> section in which it is said there should be on thread per connection?).
> In order to achieve multiplexing one have to explicitly create a
> separate thread dealing with either reading or writing the data.
> Also, using Servlet 3.1 it is impossible to achieve non-blocking read
> and write and multiplexing on the same connection, even using a separate
> thread.
>
> I will contact the specification owners to see their opinion.
>
> Many thanks,
> Przemyslaw
>
>
> On Fri, Apr 4, 2014 at 12:33 AM, Stuart Douglas
> <stuart.w.douglas at gmail.com <mailto:stuart.w.douglas at gmail.com>> wrote:
>
>
>
>     Przemyslaw Bielicki wrote:
>
>         I tried - exactly the same results.
>
>         Another weird observation is that ServletOutputStream.isReady() is
>         returning true even after the connection is closed
>         (ServletInputStream.__isFinished() is correctly returning true).
>
>         Here's the scenario that works but I can write back the data
>         only once:
>         1. In HttpUpgradeHandler I set only  the ReadListener
>         2. I switch the protocol and send some data
>         3. ReadListener gets activated i.e. onDataAvailable() is called.
>         4. I process the input data, read as much as possible and put
>         the input
>         into the queue
>         5. From within ReadListener I set the WriteListener
>         6. WriteListener.onWritePossible(__) gets called and I process
>         the data -
>         I clean the queue
>         7. As long as I'm in WriteListener.onWritePossible(__)
>         (while.out.isReady() is constantly returning true, which is a
>         correct
>         bahavior) the ReadListener is on-hold. I can send as much data
>         as I like
>         but onDataAvailable() is not called
>         8. Only when I leave WriteListener.onWritePossible(__) method the
>         ReadListener.onDataAvailable() is called again and I can consume the
>         input data again.
>         9. I can process the input data again i.e. put it into the queue but
>         WriteListener.onWritePossible(__) is never called again. When I
>         try to
>         reset it I get IllegalStateException
>
>         Either the specification or implementation seem not very mature....
>         Wildfly behavior is consistent with the one of Tomcat.
>
>
>     As Remy said this is expected.
>     Basically there is only ever one IO thread per connection, so only
>     one method will be active at a time.
>
>     The reason why your listener method is not being called again would
>     become apparent if you look at the javadoc for the read/write listeners:
>
>     Subsequently the container will invoke this method if and only
>     if {@link javax.servlet.__ServletOutputStream#isReady()} method
>     has been called and has returned <code>false</code>.
>
>     Basically what this means is that the listener is only invoked if
>     isReady() returns false at some point. If you have read some data
>     and then you want to echo it you should call the onWritePossible
>     method yourself, after you have received the data.
>
>     Stuart
>
>
>
>
>         At the moment I conclude that the non-blocking write is not
>         possible in
>         Servlet 3.1.
>
>         I would appreciate if someone can provide an example that
>         actually works
>         or explain why the weird behavior I observe is correct (is it?)
>
>         Cheers,
>         Przemyslaw
>
>
>
>
>         On Thu, Apr 3, 2014 at 6:18 AM, Stuart Douglas
>         <stuart.w.douglas at gmail.com <mailto:stuart.w.douglas at gmail.com>
>         <mailto:stuart.w.douglas at __gmail.com
>         <mailto:stuart.w.douglas at gmail.com>>> wrote:
>
>              Can you try with the latest development build of Wildfly (from
>         https://ci.jboss.org/hudson/____job/WildFly-latest-master/
>         <https://ci.jboss.org/hudson/__job/WildFly-latest-master/>
>         <https://ci.jboss.org/hudson/__job/WildFly-latest-master/
>         <https://ci.jboss.org/hudson/job/WildFly-latest-master/>>).
>
>
>              There have been some fixes in this area, so your problem
>         may have
>              already been fixed.
>
>              Stuart
>
>
>              PB wrote:
>
>                  Hi,
>
>                  I'm testing the HTTP Upgrade feature of WF 8.0 and I'm
>         facing
>                  some banal
>                  problem. Basically my ReadListener is NEVER called.
>                  Here's the code:
>
>                  @WebServlet(urlPatterns = "/upgrade")
>                  public class UpgradeServlet extends HttpServlet {
>                      @Override
>                      protected void doGet(HttpServletRequest req,
>         HttpServletResponse
>                  resp) throws ServletException, IOException {
>                        if
>
>         ("upgrade".equalsIgnoreCase(____req.getHeader("Connection"))) {
>                          req.upgrade(EchoHandler.class)____;
>
>                        }
>                      }
>                  }
>
>                  public class EchoHandler implements HttpUpgradeHandler {
>                      @Override
>                      public void init(WebConnection wc) {
>                        try {
>                          ServletInputStream in = wc.getInputStream();
>                          ServletOutputStream out = wc.getOutputStream();
>
>                          BlockingQueue<String> queue = new
>                  LinkedBlockingQueue<String>();
>                          in.setReadListener(new EchoReadListener(queue,
>         in));
>                          out.setWriteListener(new
>         EchoWriteListener(queue, out));
>                        } catch (IOException e) {
>                          throw new IllegalStateException(e);
>                        }
>                      }
>
>                  public class EchoReadListener implements ReadListener {
>                      @Override
>                      public void onDataAvailable() throws IOException {
>                        while (in.isReady()) {
>                          int length = in.read(buffer);
>                          String input = new String(buffer, 0, length);
>                          if (false == queue.offer(input)) {
>                            System.err.println("'" + input + "' input was
>         ignored");
>                          }
>                        }
>                      }
>
>                  I'm connecting to WF using telnet and sending the
>         upgrade request:
>                  GET /example-webapp/upgrade HTTP/1.1
>                  Host: localhost
>                  Connection: upgrade
>                  Upgrade: echo
>
>                  and I'm getting correct response:
>
>                  HTTP/1.1 101 Switching Protocols
>                  Connection: Upgrade
>                  X-Powered-By: Undertow 1
>                  Server: Wildfly 8
>                  Content-Length: 0
>
>                  which means that from now on the protocol between my telnet
>                  client and
>                  WF is pure TCP.
>                  So, I start typing some text, hit Enter and.... nothing
>         happens.
>                  onDataAvailable() is NEVER called. More so, this makes
>         WF totally
>                  irresponsive - my whole webapp is dead.
>
>                  I believe, I'm doing something wrong - any ideas what
>         exactly?
>                  There is
>                  also a slight chance that Upgrade feature in WF is
>         f****d :)
>                  Anyway, WF should not block even in case my upgraded
>         protocol is not
>                  working correctly?
>
>                  Many thanks,
>                  Przemyslaw
>
>                  ___________________________________________________
>                  wildfly-dev mailing list
>         wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>         <mailto:wildfly-dev at lists.__jboss.org
>         <mailto:wildfly-dev at lists.jboss.org>>
>         https://lists.jboss.org/____mailman/listinfo/wildfly-dev
>         <https://lists.jboss.org/__mailman/listinfo/wildfly-dev>
>         <https://lists.jboss.org/__mailman/listinfo/wildfly-dev
>         <https://lists.jboss.org/mailman/listinfo/wildfly-dev>>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

From pbielicki at gmail.com  Fri Apr  4 03:19:37 2014
From: pbielicki at gmail.com (Przemyslaw Bielicki)
Date: Fri, 4 Apr 2014 09:19:37 +0200
Subject: [wildfly-dev] WF 8.0 HTTP Upgrade help needed
In-Reply-To: <533E5919.3070902@gmail.com>
References: <CAMvdueASMd1kUBSOC7J_dMoiAtC0ovTdQGywATpC3kNoheDDJA@mail.gmail.com>
	<533CE109.1030602@gmail.com>
	<CAMvdueDggP8i1b9=c42V+ChumA-KL_oSWUmhuR_-kv7xBjSOyg@mail.gmail.com>
	<533DE1AB.1030503@gmail.com>
	<CAMvdueDATZO1PQsbShMGjv3CRTGYk1jEfjffq=Lmw0C0rcPz7w@mail.gmail.com>
	<533E5919.3070902@gmail.com>
Message-ID: <CAMvdueBV0aLjMvgpqU2ZTigteZfrYTAx7Y2S=tt+sv+PTk37_Q@mail.gmail.com>

thanks a lot - it seems to work but:

1. Synchronized is bad :) anyway, you wrote that there is only one thread
so synchronization is not needed
2. Main issue: it's not bi-directional full-duplex (like WebSockets) i.e.
you are not able to receive and send data at the same time, it's still
synchronous

many thanks anyway - nice try :)


On Fri, Apr 4, 2014 at 9:02 AM, Stuart Douglas
<stuart.w.douglas at gmail.com>wrote:

> Try something like the code below:
>
>
> public class AsyncEchoUpgradeServlet extends HttpServlet {
>
>     @Override
>     protected void doGet(final HttpServletRequest req, final
> HttpServletResponse resp) throws ServletException, IOException {
>         req.upgrade(Handler.class);
>     }
>
>     public static class Handler implements HttpUpgradeHandler {
>
>         @Override
>         public void init(final WebConnection wc) {
>             Listener listener = new Listener(wc);
>             try {
>                 //we have to set the write listener before the read
> listener
>                 //otherwise the output stream could be written to before
> it is
>                 //in async mode
>                 wc.getOutputStream().setWriteListener(listener);
>                 wc.getInputStream().setReadListener(listener);
>             } catch (IOException e) {
>                 UndertowLogger.REQUEST_IO_LOGGER.ioException(e);
>             }
>         }
>
>         @Override
>         public void destroy() {
>
>         }
>     }
>
>
>     private static class Listener implements WriteListener, ReadListener {
>
>         private final WebConnection connection;
>         private final Queue<String> queue = new ArrayDeque<String>();
>
>         private Listener(final WebConnection connection) {
>             this.connection = connection;
>         }
>
>         @Override
>         public synchronized void onDataAvailable() throws IOException {
>             byte[] data = new byte[100];
>             while (connection.getInputStream().isReady()) {
>                 int read;
>                 if ((read = connection.getInputStream().read(data)) !=
> -1) {
>                     queue.add(new String(data, 0, read));
>                 }
>                 onWritePossible();
>             }
>         }
>
>         @Override
>         public void onAllDataRead() throws IOException {
>
>         }
>
>         @Override
>         public synchronized void onWritePossible() throws IOException {
>
>             while (!queue.isEmpty() && connection.getOutputStream().isReady())
> {
>                 String data = queue.poll();
>                 connection.getOutputStream().write(data.getBytes());
>             }
>         }
>
>         @Override
>         public void onError(final Throwable t) {
>
>         }
>     }
> }
>
>
>
> Przemyslaw Bielicki wrote:
>
>> Hi Stuart,
>>
>> thx for the explanations. There is a problem anyway - if you set both
>> read and write listeners from the handler it won't work at all as in the
>> write listener ServletOutputStream.isReady() will be returning true all
>> the time (why not? the output is ready to send some data at the same
>> time in is ready to read some data), and the read listener will be
>> ignored (as the tread is focused on the writer). The solution here is
>> not to have while (out.isReady()) loop in the writer but a simple check
>> if (out.isReady()), but then you have to call onWritePossible yourself.
>> It means you need to pass a write listener reference to the read
>> listener - it's smells more than a bit.
>>
>> I think I have my conclusion, that is: it is impossible to achieve
>> full-duplex (thus multiplexing) in an upgraded protocol using Servlet
>> 3.1 API as there is "only ever one IO thread per connection" (I didn't
>> find such limitation in the specification - can you point out the
>> section in which it is said there should be on thread per connection?).
>> In order to achieve multiplexing one have to explicitly create a
>> separate thread dealing with either reading or writing the data.
>> Also, using Servlet 3.1 it is impossible to achieve non-blocking read
>> and write and multiplexing on the same connection, even using a separate
>> thread.
>>
>> I will contact the specification owners to see their opinion.
>>
>> Many thanks,
>> Przemyslaw
>>
>>
>> On Fri, Apr 4, 2014 at 12:33 AM, Stuart Douglas
>> <stuart.w.douglas at gmail.com <mailto:stuart.w.douglas at gmail.com>> wrote:
>>
>>
>>
>>     Przemyslaw Bielicki wrote:
>>
>>         I tried - exactly the same results.
>>
>>         Another weird observation is that ServletOutputStream.isReady() is
>>         returning true even after the connection is closed
>>         (ServletInputStream.__isFinished() is correctly returning true).
>>
>>
>>         Here's the scenario that works but I can write back the data
>>         only once:
>>         1. In HttpUpgradeHandler I set only  the ReadListener
>>         2. I switch the protocol and send some data
>>         3. ReadListener gets activated i.e. onDataAvailable() is called.
>>         4. I process the input data, read as much as possible and put
>>         the input
>>         into the queue
>>         5. From within ReadListener I set the WriteListener
>>         6. WriteListener.onWritePossible(__) gets called and I process
>>
>>         the data -
>>         I clean the queue
>>         7. As long as I'm in WriteListener.onWritePossible(__)
>>
>>         (while.out.isReady() is constantly returning true, which is a
>>         correct
>>         bahavior) the ReadListener is on-hold. I can send as much data
>>         as I like
>>         but onDataAvailable() is not called
>>         8. Only when I leave WriteListener.onWritePossible(__) method the
>>
>>         ReadListener.onDataAvailable() is called again and I can consume
>> the
>>         input data again.
>>         9. I can process the input data again i.e. put it into the queue
>> but
>>         WriteListener.onWritePossible(__) is never called again. When I
>>
>>         try to
>>         reset it I get IllegalStateException
>>
>>         Either the specification or implementation seem not very
>> mature....
>>         Wildfly behavior is consistent with the one of Tomcat.
>>
>>
>>     As Remy said this is expected.
>>     Basically there is only ever one IO thread per connection, so only
>>     one method will be active at a time.
>>
>>     The reason why your listener method is not being called again would
>>     become apparent if you look at the javadoc for the read/write
>> listeners:
>>
>>     Subsequently the container will invoke this method if and only
>>     if {@link javax.servlet.__ServletOutputStream#isReady()} method
>>
>>     has been called and has returned <code>false</code>.
>>
>>     Basically what this means is that the listener is only invoked if
>>     isReady() returns false at some point. If you have read some data
>>     and then you want to echo it you should call the onWritePossible
>>     method yourself, after you have received the data.
>>
>>     Stuart
>>
>>
>>
>>
>>         At the moment I conclude that the non-blocking write is not
>>         possible in
>>         Servlet 3.1.
>>
>>         I would appreciate if someone can provide an example that
>>         actually works
>>         or explain why the weird behavior I observe is correct (is it?)
>>
>>         Cheers,
>>         Przemyslaw
>>
>>
>>
>>
>>         On Thu, Apr 3, 2014 at 6:18 AM, Stuart Douglas
>>         <stuart.w.douglas at gmail.com <mailto:stuart.w.douglas at gmail.com>
>>         <mailto:stuart.w.douglas at __gmail.com
>>
>>         <mailto:stuart.w.douglas at gmail.com>>> wrote:
>>
>>              Can you try with the latest development build of Wildfly
>> (from
>>         https://ci.jboss.org/hudson/____job/WildFly-latest-master/
>>         <https://ci.jboss.org/hudson/__job/WildFly-latest-master/>
>>
>>         <https://ci.jboss.org/hudson/__job/WildFly-latest-master/
>>         <https://ci.jboss.org/hudson/job/WildFly-latest-master/>>).
>>
>>
>>              There have been some fixes in this area, so your problem
>>         may have
>>              already been fixed.
>>
>>              Stuart
>>
>>
>>              PB wrote:
>>
>>                  Hi,
>>
>>                  I'm testing the HTTP Upgrade feature of WF 8.0 and I'm
>>         facing
>>                  some banal
>>                  problem. Basically my ReadListener is NEVER called.
>>                  Here's the code:
>>
>>                  @WebServlet(urlPatterns = "/upgrade")
>>                  public class UpgradeServlet extends HttpServlet {
>>                      @Override
>>                      protected void doGet(HttpServletRequest req,
>>         HttpServletResponse
>>                  resp) throws ServletException, IOException {
>>                        if
>>
>>         ("upgrade".equalsIgnoreCase(____req.getHeader("Connection"))) {
>>                          req.upgrade(EchoHandler.class)____;
>>
>>
>>                        }
>>                      }
>>                  }
>>
>>                  public class EchoHandler implements HttpUpgradeHandler {
>>                      @Override
>>                      public void init(WebConnection wc) {
>>                        try {
>>                          ServletInputStream in = wc.getInputStream();
>>                          ServletOutputStream out = wc.getOutputStream();
>>
>>                          BlockingQueue<String> queue = new
>>                  LinkedBlockingQueue<String>();
>>                          in.setReadListener(new EchoReadListener(queue,
>>         in));
>>                          out.setWriteListener(new
>>         EchoWriteListener(queue, out));
>>                        } catch (IOException e) {
>>                          throw new IllegalStateException(e);
>>                        }
>>                      }
>>
>>                  public class EchoReadListener implements ReadListener {
>>                      @Override
>>                      public void onDataAvailable() throws IOException {
>>                        while (in.isReady()) {
>>                          int length = in.read(buffer);
>>                          String input = new String(buffer, 0, length);
>>                          if (false == queue.offer(input)) {
>>                            System.err.println("'" + input + "' input was
>>         ignored");
>>                          }
>>                        }
>>                      }
>>
>>                  I'm connecting to WF using telnet and sending the
>>         upgrade request:
>>                  GET /example-webapp/upgrade HTTP/1.1
>>                  Host: localhost
>>                  Connection: upgrade
>>                  Upgrade: echo
>>
>>                  and I'm getting correct response:
>>
>>                  HTTP/1.1 101 Switching Protocols
>>                  Connection: Upgrade
>>                  X-Powered-By: Undertow 1
>>                  Server: Wildfly 8
>>                  Content-Length: 0
>>
>>                  which means that from now on the protocol between my
>> telnet
>>                  client and
>>                  WF is pure TCP.
>>                  So, I start typing some text, hit Enter and.... nothing
>>         happens.
>>                  onDataAvailable() is NEVER called. More so, this makes
>>         WF totally
>>                  irresponsive - my whole webapp is dead.
>>
>>                  I believe, I'm doing something wrong - any ideas what
>>         exactly?
>>                  There is
>>                  also a slight chance that Upgrade feature in WF is
>>         f****d :)
>>                  Anyway, WF should not block even in case my upgraded
>>         protocol is not
>>                  working correctly?
>>
>>                  Many thanks,
>>                  Przemyslaw
>>
>>                  ___________________________________________________
>>
>>                  wildfly-dev mailing list
>>         wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>         <mailto:wildfly-dev at lists.__jboss.org
>>         <mailto:wildfly-dev at lists.jboss.org>>
>>         https://lists.jboss.org/____mailman/listinfo/wildfly-dev
>>         <https://lists.jboss.org/__mailman/listinfo/wildfly-dev>
>>         <https://lists.jboss.org/__mailman/listinfo/wildfly-dev
>>         <https://lists.jboss.org/mailman/listinfo/wildfly-dev>>
>>
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140404/66a34c85/attachment-0001.html 

From stuart.w.douglas at gmail.com  Fri Apr  4 03:27:24 2014
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Fri, 4 Apr 2014 18:27:24 +1100
Subject: [wildfly-dev] WF 8.0 HTTP Upgrade help needed
In-Reply-To: <CAMvdueBV0aLjMvgpqU2ZTigteZfrYTAx7Y2S=tt+sv+PTk37_Q@mail.gmail.com>
References: <CAMvdueASMd1kUBSOC7J_dMoiAtC0ovTdQGywATpC3kNoheDDJA@mail.gmail.com>
	<533CE109.1030602@gmail.com>
	<CAMvdueDggP8i1b9=c42V+ChumA-KL_oSWUmhuR_-kv7xBjSOyg@mail.gmail.com>
	<533DE1AB.1030503@gmail.com>
	<CAMvdueDATZO1PQsbShMGjv3CRTGYk1jEfjffq=Lmw0C0rcPz7w@mail.gmail.com>
	<533E5919.3070902@gmail.com>
	<CAMvdueBV0aLjMvgpqU2ZTigteZfrYTAx7Y2S=tt+sv+PTk37_Q@mail.gmail.com>
Message-ID: <CAAoo=c5mDcxput6ZYoNnuUwdNmqVpWHUuveFY2wvZROazA+ukw@mail.gmail.com>

On Fri, Apr 4, 2014 at 6:19 PM, Przemyslaw Bielicki <pbielicki at gmail.com>wrote:

> thanks a lot - it seems to work but:
>
> 1. Synchronized is bad :) anyway, you wrote that there is only one thread
> so synchronization is not needed
>

oops, that was a copy paste error, it is not needed.


> 2. Main issue: it's not bi-directional full-duplex (like WebSockets) i.e.
> you are not able to receive and send data at the same time, it's still
> synchronous
>

Web sockets is exactly the same. There is generally only one thread, and it
handles both read and write notifications. If you are worried about the
read thread just reading constantly and the write thread never getting a go
then just put a limit on how much data can be queued before it is written
out.

At one point XNIO did have separate read and write threads, however it
ended up being much slower as you end up needing to synchronise. A single
IO thread is faster, you just have to be careful of how much you buffer on
the read side before writing.

Stuart


>
> many thanks anyway - nice try :)
>
>
> On Fri, Apr 4, 2014 at 9:02 AM, Stuart Douglas <stuart.w.douglas at gmail.com
> > wrote:
>
>> Try something like the code below:
>>
>>
>> public class AsyncEchoUpgradeServlet extends HttpServlet {
>>
>>     @Override
>>     protected void doGet(final HttpServletRequest req, final
>> HttpServletResponse resp) throws ServletException, IOException {
>>         req.upgrade(Handler.class);
>>     }
>>
>>     public static class Handler implements HttpUpgradeHandler {
>>
>>         @Override
>>         public void init(final WebConnection wc) {
>>             Listener listener = new Listener(wc);
>>             try {
>>                 //we have to set the write listener before the read
>> listener
>>                 //otherwise the output stream could be written to before
>> it is
>>                 //in async mode
>>                 wc.getOutputStream().setWriteListener(listener);
>>                 wc.getInputStream().setReadListener(listener);
>>             } catch (IOException e) {
>>                 UndertowLogger.REQUEST_IO_LOGGER.ioException(e);
>>             }
>>         }
>>
>>         @Override
>>         public void destroy() {
>>
>>         }
>>     }
>>
>>
>>     private static class Listener implements WriteListener, ReadListener {
>>
>>         private final WebConnection connection;
>>         private final Queue<String> queue = new ArrayDeque<String>();
>>
>>         private Listener(final WebConnection connection) {
>>             this.connection = connection;
>>         }
>>
>>         @Override
>>         public synchronized void onDataAvailable() throws IOException {
>>             byte[] data = new byte[100];
>>             while (connection.getInputStream().isReady()) {
>>                 int read;
>>                 if ((read = connection.getInputStream().read(data)) !=
>> -1) {
>>                     queue.add(new String(data, 0, read));
>>                 }
>>                 onWritePossible();
>>             }
>>         }
>>
>>         @Override
>>         public void onAllDataRead() throws IOException {
>>
>>         }
>>
>>         @Override
>>         public synchronized void onWritePossible() throws IOException {
>>
>>             while (!queue.isEmpty() && connection.getOutputStream().isReady())
>> {
>>                 String data = queue.poll();
>>                 connection.getOutputStream().write(data.getBytes());
>>             }
>>         }
>>
>>         @Override
>>         public void onError(final Throwable t) {
>>
>>         }
>>     }
>> }
>>
>>
>>
>> Przemyslaw Bielicki wrote:
>>
>>> Hi Stuart,
>>>
>>> thx for the explanations. There is a problem anyway - if you set both
>>> read and write listeners from the handler it won't work at all as in the
>>> write listener ServletOutputStream.isReady() will be returning true all
>>> the time (why not? the output is ready to send some data at the same
>>> time in is ready to read some data), and the read listener will be
>>> ignored (as the tread is focused on the writer). The solution here is
>>> not to have while (out.isReady()) loop in the writer but a simple check
>>> if (out.isReady()), but then you have to call onWritePossible yourself.
>>> It means you need to pass a write listener reference to the read
>>> listener - it's smells more than a bit.
>>>
>>> I think I have my conclusion, that is: it is impossible to achieve
>>> full-duplex (thus multiplexing) in an upgraded protocol using Servlet
>>> 3.1 API as there is "only ever one IO thread per connection" (I didn't
>>> find such limitation in the specification - can you point out the
>>> section in which it is said there should be on thread per connection?).
>>> In order to achieve multiplexing one have to explicitly create a
>>> separate thread dealing with either reading or writing the data.
>>> Also, using Servlet 3.1 it is impossible to achieve non-blocking read
>>> and write and multiplexing on the same connection, even using a separate
>>> thread.
>>>
>>> I will contact the specification owners to see their opinion.
>>>
>>> Many thanks,
>>> Przemyslaw
>>>
>>>
>>> On Fri, Apr 4, 2014 at 12:33 AM, Stuart Douglas
>>> <stuart.w.douglas at gmail.com <mailto:stuart.w.douglas at gmail.com>> wrote:
>>>
>>>
>>>
>>>     Przemyslaw Bielicki wrote:
>>>
>>>         I tried - exactly the same results.
>>>
>>>         Another weird observation is that ServletOutputStream.isReady()
>>> is
>>>         returning true even after the connection is closed
>>>         (ServletInputStream.__isFinished() is correctly returning true).
>>>
>>>
>>>         Here's the scenario that works but I can write back the data
>>>         only once:
>>>         1. In HttpUpgradeHandler I set only  the ReadListener
>>>         2. I switch the protocol and send some data
>>>         3. ReadListener gets activated i.e. onDataAvailable() is called.
>>>         4. I process the input data, read as much as possible and put
>>>         the input
>>>         into the queue
>>>         5. From within ReadListener I set the WriteListener
>>>         6. WriteListener.onWritePossible(__) gets called and I process
>>>
>>>         the data -
>>>         I clean the queue
>>>         7. As long as I'm in WriteListener.onWritePossible(__)
>>>
>>>         (while.out.isReady() is constantly returning true, which is a
>>>         correct
>>>         bahavior) the ReadListener is on-hold. I can send as much data
>>>         as I like
>>>         but onDataAvailable() is not called
>>>         8. Only when I leave WriteListener.onWritePossible(__) method
>>> the
>>>
>>>         ReadListener.onDataAvailable() is called again and I can consume
>>> the
>>>         input data again.
>>>         9. I can process the input data again i.e. put it into the queue
>>> but
>>>         WriteListener.onWritePossible(__) is never called again. When I
>>>
>>>         try to
>>>         reset it I get IllegalStateException
>>>
>>>         Either the specification or implementation seem not very
>>> mature....
>>>         Wildfly behavior is consistent with the one of Tomcat.
>>>
>>>
>>>     As Remy said this is expected.
>>>     Basically there is only ever one IO thread per connection, so only
>>>     one method will be active at a time.
>>>
>>>     The reason why your listener method is not being called again would
>>>     become apparent if you look at the javadoc for the read/write
>>> listeners:
>>>
>>>     Subsequently the container will invoke this method if and only
>>>     if {@link javax.servlet.__ServletOutputStream#isReady()} method
>>>
>>>     has been called and has returned <code>false</code>.
>>>
>>>     Basically what this means is that the listener is only invoked if
>>>     isReady() returns false at some point. If you have read some data
>>>     and then you want to echo it you should call the onWritePossible
>>>     method yourself, after you have received the data.
>>>
>>>     Stuart
>>>
>>>
>>>
>>>
>>>         At the moment I conclude that the non-blocking write is not
>>>         possible in
>>>         Servlet 3.1.
>>>
>>>         I would appreciate if someone can provide an example that
>>>         actually works
>>>         or explain why the weird behavior I observe is correct (is it?)
>>>
>>>         Cheers,
>>>         Przemyslaw
>>>
>>>
>>>
>>>
>>>         On Thu, Apr 3, 2014 at 6:18 AM, Stuart Douglas
>>>         <stuart.w.douglas at gmail.com <mailto:stuart.w.douglas at gmail.com>
>>>         <mailto:stuart.w.douglas at __gmail.com
>>>
>>>         <mailto:stuart.w.douglas at gmail.com>>> wrote:
>>>
>>>              Can you try with the latest development build of Wildfly
>>> (from
>>>         https://ci.jboss.org/hudson/____job/WildFly-latest-master/
>>>         <https://ci.jboss.org/hudson/__job/WildFly-latest-master/>
>>>
>>>         <https://ci.jboss.org/hudson/__job/WildFly-latest-master/
>>>         <https://ci.jboss.org/hudson/job/WildFly-latest-master/>>).
>>>
>>>
>>>              There have been some fixes in this area, so your problem
>>>         may have
>>>              already been fixed.
>>>
>>>              Stuart
>>>
>>>
>>>              PB wrote:
>>>
>>>                  Hi,
>>>
>>>                  I'm testing the HTTP Upgrade feature of WF 8.0 and I'm
>>>         facing
>>>                  some banal
>>>                  problem. Basically my ReadListener is NEVER called.
>>>                  Here's the code:
>>>
>>>                  @WebServlet(urlPatterns = "/upgrade")
>>>                  public class UpgradeServlet extends HttpServlet {
>>>                      @Override
>>>                      protected void doGet(HttpServletRequest req,
>>>         HttpServletResponse
>>>                  resp) throws ServletException, IOException {
>>>                        if
>>>
>>>         ("upgrade".equalsIgnoreCase(____req.getHeader("Connection"))) {
>>>                          req.upgrade(EchoHandler.class)____;
>>>
>>>
>>>                        }
>>>                      }
>>>                  }
>>>
>>>                  public class EchoHandler implements HttpUpgradeHandler {
>>>                      @Override
>>>                      public void init(WebConnection wc) {
>>>                        try {
>>>                          ServletInputStream in = wc.getInputStream();
>>>                          ServletOutputStream out = wc.getOutputStream();
>>>
>>>                          BlockingQueue<String> queue = new
>>>                  LinkedBlockingQueue<String>();
>>>                          in.setReadListener(new EchoReadListener(queue,
>>>         in));
>>>                          out.setWriteListener(new
>>>         EchoWriteListener(queue, out));
>>>                        } catch (IOException e) {
>>>                          throw new IllegalStateException(e);
>>>                        }
>>>                      }
>>>
>>>                  public class EchoReadListener implements ReadListener {
>>>                      @Override
>>>                      public void onDataAvailable() throws IOException {
>>>                        while (in.isReady()) {
>>>                          int length = in.read(buffer);
>>>                          String input = new String(buffer, 0, length);
>>>                          if (false == queue.offer(input)) {
>>>                            System.err.println("'" + input + "' input was
>>>         ignored");
>>>                          }
>>>                        }
>>>                      }
>>>
>>>                  I'm connecting to WF using telnet and sending the
>>>         upgrade request:
>>>                  GET /example-webapp/upgrade HTTP/1.1
>>>                  Host: localhost
>>>                  Connection: upgrade
>>>                  Upgrade: echo
>>>
>>>                  and I'm getting correct response:
>>>
>>>                  HTTP/1.1 101 Switching Protocols
>>>                  Connection: Upgrade
>>>                  X-Powered-By: Undertow 1
>>>                  Server: Wildfly 8
>>>                  Content-Length: 0
>>>
>>>                  which means that from now on the protocol between my
>>> telnet
>>>                  client and
>>>                  WF is pure TCP.
>>>                  So, I start typing some text, hit Enter and.... nothing
>>>         happens.
>>>                  onDataAvailable() is NEVER called. More so, this makes
>>>         WF totally
>>>                  irresponsive - my whole webapp is dead.
>>>
>>>                  I believe, I'm doing something wrong - any ideas what
>>>         exactly?
>>>                  There is
>>>                  also a slight chance that Upgrade feature in WF is
>>>         f****d :)
>>>                  Anyway, WF should not block even in case my upgraded
>>>         protocol is not
>>>                  working correctly?
>>>
>>>                  Many thanks,
>>>                  Przemyslaw
>>>
>>>                  ___________________________________________________
>>>
>>>                  wildfly-dev mailing list
>>>         wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>>         <mailto:wildfly-dev at lists.__jboss.org
>>>         <mailto:wildfly-dev at lists.jboss.org>>
>>>         https://lists.jboss.org/____mailman/listinfo/wildfly-dev
>>>         <https://lists.jboss.org/__mailman/listinfo/wildfly-dev>
>>>         <https://lists.jboss.org/__mailman/listinfo/wildfly-dev
>>>         <https://lists.jboss.org/mailman/listinfo/wildfly-dev>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140404/78f60d74/attachment-0001.html 

From pbielicki at gmail.com  Fri Apr  4 03:30:27 2014
From: pbielicki at gmail.com (Przemyslaw Bielicki)
Date: Fri, 4 Apr 2014 09:30:27 +0200
Subject: [wildfly-dev] WF 8.0 HTTP Upgrade help needed
In-Reply-To: <CAAoo=c5mDcxput6ZYoNnuUwdNmqVpWHUuveFY2wvZROazA+ukw@mail.gmail.com>
References: <CAMvdueASMd1kUBSOC7J_dMoiAtC0ovTdQGywATpC3kNoheDDJA@mail.gmail.com>
	<533CE109.1030602@gmail.com>
	<CAMvdueDggP8i1b9=c42V+ChumA-KL_oSWUmhuR_-kv7xBjSOyg@mail.gmail.com>
	<533DE1AB.1030503@gmail.com>
	<CAMvdueDATZO1PQsbShMGjv3CRTGYk1jEfjffq=Lmw0C0rcPz7w@mail.gmail.com>
	<533E5919.3070902@gmail.com>
	<CAMvdueBV0aLjMvgpqU2ZTigteZfrYTAx7Y2S=tt+sv+PTk37_Q@mail.gmail.com>
	<CAAoo=c5mDcxput6ZYoNnuUwdNmqVpWHUuveFY2wvZROazA+ukw@mail.gmail.com>
Message-ID: <CAMvdueAcNiyN0NL=G_EojQfhmi=af7bJvq=roCcUD8v8aDwZ6Q@mail.gmail.com>

cool, thx a lot - that should do the trick :)



On Fri, Apr 4, 2014 at 9:27 AM, Stuart Douglas
<stuart.w.douglas at gmail.com>wrote:

>
>
>
> On Fri, Apr 4, 2014 at 6:19 PM, Przemyslaw Bielicki <pbielicki at gmail.com>wrote:
>
>> thanks a lot - it seems to work but:
>>
>> 1. Synchronized is bad :) anyway, you wrote that there is only one thread
>> so synchronization is not needed
>>
>
> oops, that was a copy paste error, it is not needed.
>
>
>> 2. Main issue: it's not bi-directional full-duplex (like WebSockets) i.e.
>> you are not able to receive and send data at the same time, it's still
>> synchronous
>>
>
> Web sockets is exactly the same. There is generally only one thread, and
> it handles both read and write notifications. If you are worried about the
> read thread just reading constantly and the write thread never getting a go
> then just put a limit on how much data can be queued before it is written
> out.
>
> At one point XNIO did have separate read and write threads, however it
> ended up being much slower as you end up needing to synchronise. A single
> IO thread is faster, you just have to be careful of how much you buffer on
> the read side before writing.
>
> Stuart
>
>
>>
>> many thanks anyway - nice try :)
>>
>>
>> On Fri, Apr 4, 2014 at 9:02 AM, Stuart Douglas <
>> stuart.w.douglas at gmail.com> wrote:
>>
>>> Try something like the code below:
>>>
>>>
>>> public class AsyncEchoUpgradeServlet extends HttpServlet {
>>>
>>>     @Override
>>>     protected void doGet(final HttpServletRequest req, final
>>> HttpServletResponse resp) throws ServletException, IOException {
>>>         req.upgrade(Handler.class);
>>>     }
>>>
>>>     public static class Handler implements HttpUpgradeHandler {
>>>
>>>         @Override
>>>         public void init(final WebConnection wc) {
>>>             Listener listener = new Listener(wc);
>>>             try {
>>>                 //we have to set the write listener before the read
>>> listener
>>>                 //otherwise the output stream could be written to before
>>> it is
>>>                 //in async mode
>>>                 wc.getOutputStream().setWriteListener(listener);
>>>                 wc.getInputStream().setReadListener(listener);
>>>             } catch (IOException e) {
>>>                 UndertowLogger.REQUEST_IO_LOGGER.ioException(e);
>>>             }
>>>         }
>>>
>>>         @Override
>>>         public void destroy() {
>>>
>>>         }
>>>     }
>>>
>>>
>>>     private static class Listener implements WriteListener, ReadListener
>>> {
>>>
>>>         private final WebConnection connection;
>>>         private final Queue<String> queue = new ArrayDeque<String>();
>>>
>>>         private Listener(final WebConnection connection) {
>>>             this.connection = connection;
>>>         }
>>>
>>>         @Override
>>>         public synchronized void onDataAvailable() throws IOException {
>>>             byte[] data = new byte[100];
>>>             while (connection.getInputStream().isReady()) {
>>>                 int read;
>>>                 if ((read = connection.getInputStream().read(data)) !=
>>> -1) {
>>>                     queue.add(new String(data, 0, read));
>>>                 }
>>>                 onWritePossible();
>>>             }
>>>         }
>>>
>>>         @Override
>>>         public void onAllDataRead() throws IOException {
>>>
>>>         }
>>>
>>>         @Override
>>>         public synchronized void onWritePossible() throws IOException {
>>>
>>>             while (!queue.isEmpty() && connection.getOutputStream().isReady())
>>> {
>>>                 String data = queue.poll();
>>>                 connection.getOutputStream().write(data.getBytes());
>>>             }
>>>         }
>>>
>>>         @Override
>>>         public void onError(final Throwable t) {
>>>
>>>         }
>>>     }
>>> }
>>>
>>>
>>>
>>> Przemyslaw Bielicki wrote:
>>>
>>>> Hi Stuart,
>>>>
>>>> thx for the explanations. There is a problem anyway - if you set both
>>>> read and write listeners from the handler it won't work at all as in the
>>>> write listener ServletOutputStream.isReady() will be returning true all
>>>> the time (why not? the output is ready to send some data at the same
>>>> time in is ready to read some data), and the read listener will be
>>>> ignored (as the tread is focused on the writer). The solution here is
>>>> not to have while (out.isReady()) loop in the writer but a simple check
>>>> if (out.isReady()), but then you have to call onWritePossible yourself.
>>>> It means you need to pass a write listener reference to the read
>>>> listener - it's smells more than a bit.
>>>>
>>>> I think I have my conclusion, that is: it is impossible to achieve
>>>> full-duplex (thus multiplexing) in an upgraded protocol using Servlet
>>>> 3.1 API as there is "only ever one IO thread per connection" (I didn't
>>>> find such limitation in the specification - can you point out the
>>>> section in which it is said there should be on thread per connection?).
>>>> In order to achieve multiplexing one have to explicitly create a
>>>> separate thread dealing with either reading or writing the data.
>>>> Also, using Servlet 3.1 it is impossible to achieve non-blocking read
>>>> and write and multiplexing on the same connection, even using a separate
>>>> thread.
>>>>
>>>> I will contact the specification owners to see their opinion.
>>>>
>>>> Many thanks,
>>>> Przemyslaw
>>>>
>>>>
>>>> On Fri, Apr 4, 2014 at 12:33 AM, Stuart Douglas
>>>> <stuart.w.douglas at gmail.com <mailto:stuart.w.douglas at gmail.com>> wrote:
>>>>
>>>>
>>>>
>>>>     Przemyslaw Bielicki wrote:
>>>>
>>>>         I tried - exactly the same results.
>>>>
>>>>         Another weird observation is that ServletOutputStream.isReady()
>>>> is
>>>>         returning true even after the connection is closed
>>>>         (ServletInputStream.__isFinished() is correctly returning
>>>> true).
>>>>
>>>>
>>>>         Here's the scenario that works but I can write back the data
>>>>         only once:
>>>>         1. In HttpUpgradeHandler I set only  the ReadListener
>>>>         2. I switch the protocol and send some data
>>>>         3. ReadListener gets activated i.e. onDataAvailable() is called.
>>>>         4. I process the input data, read as much as possible and put
>>>>         the input
>>>>         into the queue
>>>>         5. From within ReadListener I set the WriteListener
>>>>         6. WriteListener.onWritePossible(__) gets called and I process
>>>>
>>>>         the data -
>>>>         I clean the queue
>>>>         7. As long as I'm in WriteListener.onWritePossible(__)
>>>>
>>>>         (while.out.isReady() is constantly returning true, which is a
>>>>         correct
>>>>         bahavior) the ReadListener is on-hold. I can send as much data
>>>>         as I like
>>>>         but onDataAvailable() is not called
>>>>         8. Only when I leave WriteListener.onWritePossible(__) method
>>>> the
>>>>
>>>>         ReadListener.onDataAvailable() is called again and I can
>>>> consume the
>>>>         input data again.
>>>>         9. I can process the input data again i.e. put it into the
>>>> queue but
>>>>         WriteListener.onWritePossible(__) is never called again. When I
>>>>
>>>>         try to
>>>>         reset it I get IllegalStateException
>>>>
>>>>         Either the specification or implementation seem not very
>>>> mature....
>>>>         Wildfly behavior is consistent with the one of Tomcat.
>>>>
>>>>
>>>>     As Remy said this is expected.
>>>>     Basically there is only ever one IO thread per connection, so only
>>>>     one method will be active at a time.
>>>>
>>>>     The reason why your listener method is not being called again would
>>>>     become apparent if you look at the javadoc for the read/write
>>>> listeners:
>>>>
>>>>     Subsequently the container will invoke this method if and only
>>>>     if {@link javax.servlet.__ServletOutputStream#isReady()} method
>>>>
>>>>     has been called and has returned <code>false</code>.
>>>>
>>>>     Basically what this means is that the listener is only invoked if
>>>>     isReady() returns false at some point. If you have read some data
>>>>     and then you want to echo it you should call the onWritePossible
>>>>     method yourself, after you have received the data.
>>>>
>>>>     Stuart
>>>>
>>>>
>>>>
>>>>
>>>>         At the moment I conclude that the non-blocking write is not
>>>>         possible in
>>>>         Servlet 3.1.
>>>>
>>>>         I would appreciate if someone can provide an example that
>>>>         actually works
>>>>         or explain why the weird behavior I observe is correct (is it?)
>>>>
>>>>         Cheers,
>>>>         Przemyslaw
>>>>
>>>>
>>>>
>>>>
>>>>         On Thu, Apr 3, 2014 at 6:18 AM, Stuart Douglas
>>>>         <stuart.w.douglas at gmail.com <mailto:stuart.w.douglas at gmail.com>
>>>>         <mailto:stuart.w.douglas at __gmail.com
>>>>
>>>>         <mailto:stuart.w.douglas at gmail.com>>> wrote:
>>>>
>>>>              Can you try with the latest development build of Wildfly
>>>> (from
>>>>         https://ci.jboss.org/hudson/____job/WildFly-latest-master/
>>>>         <https://ci.jboss.org/hudson/__job/WildFly-latest-master/>
>>>>
>>>>         <https://ci.jboss.org/hudson/__job/WildFly-latest-master/
>>>>         <https://ci.jboss.org/hudson/job/WildFly-latest-master/>>).
>>>>
>>>>
>>>>              There have been some fixes in this area, so your problem
>>>>         may have
>>>>              already been fixed.
>>>>
>>>>              Stuart
>>>>
>>>>
>>>>              PB wrote:
>>>>
>>>>                  Hi,
>>>>
>>>>                  I'm testing the HTTP Upgrade feature of WF 8.0 and I'm
>>>>         facing
>>>>                  some banal
>>>>                  problem. Basically my ReadListener is NEVER called.
>>>>                  Here's the code:
>>>>
>>>>                  @WebServlet(urlPatterns = "/upgrade")
>>>>                  public class UpgradeServlet extends HttpServlet {
>>>>                      @Override
>>>>                      protected void doGet(HttpServletRequest req,
>>>>         HttpServletResponse
>>>>                  resp) throws ServletException, IOException {
>>>>                        if
>>>>
>>>>         ("upgrade".equalsIgnoreCase(____req.getHeader("Connection"))) {
>>>>                          req.upgrade(EchoHandler.class)____;
>>>>
>>>>
>>>>                        }
>>>>                      }
>>>>                  }
>>>>
>>>>                  public class EchoHandler implements HttpUpgradeHandler
>>>> {
>>>>                      @Override
>>>>                      public void init(WebConnection wc) {
>>>>                        try {
>>>>                          ServletInputStream in = wc.getInputStream();
>>>>                          ServletOutputStream out = wc.getOutputStream();
>>>>
>>>>                          BlockingQueue<String> queue = new
>>>>                  LinkedBlockingQueue<String>();
>>>>                          in.setReadListener(new EchoReadListener(queue,
>>>>         in));
>>>>                          out.setWriteListener(new
>>>>         EchoWriteListener(queue, out));
>>>>                        } catch (IOException e) {
>>>>                          throw new IllegalStateException(e);
>>>>                        }
>>>>                      }
>>>>
>>>>                  public class EchoReadListener implements ReadListener {
>>>>                      @Override
>>>>                      public void onDataAvailable() throws IOException {
>>>>                        while (in.isReady()) {
>>>>                          int length = in.read(buffer);
>>>>                          String input = new String(buffer, 0, length);
>>>>                          if (false == queue.offer(input)) {
>>>>                            System.err.println("'" + input + "' input was
>>>>         ignored");
>>>>                          }
>>>>                        }
>>>>                      }
>>>>
>>>>                  I'm connecting to WF using telnet and sending the
>>>>         upgrade request:
>>>>                  GET /example-webapp/upgrade HTTP/1.1
>>>>                  Host: localhost
>>>>                  Connection: upgrade
>>>>                  Upgrade: echo
>>>>
>>>>                  and I'm getting correct response:
>>>>
>>>>                  HTTP/1.1 101 Switching Protocols
>>>>                  Connection: Upgrade
>>>>                  X-Powered-By: Undertow 1
>>>>                  Server: Wildfly 8
>>>>                  Content-Length: 0
>>>>
>>>>                  which means that from now on the protocol between my
>>>> telnet
>>>>                  client and
>>>>                  WF is pure TCP.
>>>>                  So, I start typing some text, hit Enter and.... nothing
>>>>         happens.
>>>>                  onDataAvailable() is NEVER called. More so, this makes
>>>>         WF totally
>>>>                  irresponsive - my whole webapp is dead.
>>>>
>>>>                  I believe, I'm doing something wrong - any ideas what
>>>>         exactly?
>>>>                  There is
>>>>                  also a slight chance that Upgrade feature in WF is
>>>>         f****d :)
>>>>                  Anyway, WF should not block even in case my upgraded
>>>>         protocol is not
>>>>                  working correctly?
>>>>
>>>>                  Many thanks,
>>>>                  Przemyslaw
>>>>
>>>>                  ___________________________________________________
>>>>
>>>>                  wildfly-dev mailing list
>>>>         wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org
>>>> >
>>>>         <mailto:wildfly-dev at lists.__jboss.org
>>>>         <mailto:wildfly-dev at lists.jboss.org>>
>>>>         https://lists.jboss.org/____mailman/listinfo/wildfly-dev
>>>>         <https://lists.jboss.org/__mailman/listinfo/wildfly-dev>
>>>>         <https://lists.jboss.org/__mailman/listinfo/wildfly-dev
>>>>         <https://lists.jboss.org/mailman/listinfo/wildfly-dev>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140404/b61cccbf/attachment-0001.html 

From rory.odonnell at oracle.com  Tue Apr  8 04:20:28 2014
From: rory.odonnell at oracle.com (Rory O'Donnell Oracle, Dublin Ireland)
Date: Tue, 08 Apr 2014 09:20:28 +0100
Subject: [wildfly-dev] JDK 9 build 06 is available on java.net
Message-ID: <5343B14C.1000109@oracle.com>

Hi Guys,

JDK 9 Build 06 Early Access Build is now available for download 
<https://jdk9.java.net/download> & test.

Rgds, Rory

-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140408/83455c3e/attachment.html 

From juanma.cabrera at gmail.com  Tue Apr  8 08:54:13 2014
From: juanma.cabrera at gmail.com (Juan Manuel CABRERA)
Date: Tue, 8 Apr 2014 14:54:13 +0200
Subject: [wildfly-dev] Exclusions in WildFly
Message-ID: <CANDP1e_QT9=V4aXFTTun39YdnijoUWigS1m9nywcR3xXc2vD_A@mail.gmail.com>

Hello devs,

I have a wildfly war application at hands, which depends on a jar which
starts its own JPA persistence container with Spring. This jar has its own
`persistence.xml`, with  only one persistence unit.
In the embedded jar, since there is only one persistence unit, it is
injected using a `@PersistenceContext` without a unit name. Furthermore,
the objects having such fields are not EJBs, they are simple Spring beans...

On the other hand, the application has also a `persistence.xml` with two
persistence units.
The code of the application has `@PersistenceContext` fields with a proper
`unitName`, which is mandatory since there are two of them.

Now, when I start my application, Wildfly (specifically the jpa module)
scans the code from the jar and chokes on the `@PersistenceContext` without
unitNames of my Spring beans:

    DEBUG [org.jboss.as.jpa.messages] (MSC service thread 1-1) persistence
unit search for unitName=null referenced from class=the.spring.Bean
(annotation=@javax.persistence.PersistenceContext() on void
the.spring.Bean.setEntityManager(javax.persistence.EntityManager))


To cope with this, I would like to exclude the jar: In TomEE there is a
mean to exclude a jar explicitly from being scanned, but I cannot find a
similar functionnality in WildFly.
I have tried the following configurations without success:

 - `jboss-deployment-structure.xml` which is read but without noticeable
effect:

        <jboss-deployment-structure
xmlns="urn:jboss:deployment-structure:1.2">
          <deployment>
            <exclusions>
              <module name="deployment.jee-app.war.spring-app.jar" />
              <!-- I have also tried the following -->
              <!-- <module name="jee-app.war.spring-app.jar" /> -->
              <!-- <module name="spring-app.jar" /> -->
            </exclusions>
          </deployment>
        </jboss-deployment-structure>

 - `jboss-scanning.xml` which seems to be ignored

        <scanning xmlns="urn:jboss:scanning:1.0">
          <path name="jee-app.war/WEB-INF/lib">
            <exclude name="spring-app.jar" />
          </path>
        </scanning>


Both of these files are in the WEB-INF folder of my war application.

Of course, I cannot modify the spring-app.jar (would be too easy...)

Needless to say, I have spend a considerable amount of time in the WildFly
doc and on Google without finding anything else than exluding subsystems,
or overriding locally modules of WildFly...

Thanks for your help!

Juan Manuel

PS: This question is also posted on StackOverflow:
http://stackoverflow.com/q/22932015/3509723
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140408/1a79f243/attachment.html 

From smarlow at redhat.com  Wed Apr  9 08:07:40 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 09 Apr 2014 08:07:40 -0400
Subject: [wildfly-dev] regression caused by "WFLY-3175 Create non-clustered
 implementations of org.wildfly.clustering.api services" change
Message-ID: <5345380C.1080305@redhat.com>

I'm running with an older WildFly configuration (EE TCK) that probably 
doesn't have the needed changes for the 
"jboss.clustering.registry.ejb.default" service.  Rather than just 
syncing up with the WFLY-3175 changes, I would like to know if the 
dependencies on "jboss.clustering.registry.ejb.default" should be 
optional so that people with older WildFly configurations do not get 
service dependency errors on "jboss.clustering.registry.ejb.default"?

Scott

From brian.stansberry at redhat.com  Wed Apr  9 09:14:54 2014
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 09 Apr 2014 08:14:54 -0500
Subject: [wildfly-dev] regression caused by "WFLY-3175 Create
 non-clustered implementations of org.wildfly.clustering.api services"
 change
In-Reply-To: <5345380C.1080305@redhat.com>
References: <5345380C.1080305@redhat.com>
Message-ID: <534547CE.30405@redhat.com>

If that change breaks existing configs, it's a major problem. For sure 
it has to be corrected for 8.0.1. We can't break existing configs in a 
bug fix release.

On 4/9/14, 7:07 AM, Scott Marlow wrote:
> I'm running with an older WildFly configuration (EE TCK) that probably
> doesn't have the needed changes for the
> "jboss.clustering.registry.ejb.default" service.  Rather than just
> syncing up with the WFLY-3175 changes, I would like to know if the
> dependencies on "jboss.clustering.registry.ejb.default" should be
> optional so that people with older WildFly configurations do not get
> service dependency errors on "jboss.clustering.registry.ejb.default"?
>
> Scott
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From smarlow at redhat.com  Wed Apr  9 10:05:28 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 09 Apr 2014 10:05:28 -0400
Subject: [wildfly-dev] regression caused by "WFLY-3175 Create
 non-clustered implementations of org.wildfly.clustering.api services"
 change
In-Reply-To: <534547CE.30405@redhat.com>
References: <5345380C.1080305@redhat.com> <534547CE.30405@redhat.com>
Message-ID: <534553A8.50502@redhat.com>

Test configuration file that I'm using is available at 
https://www.dropbox.com/s/3yedst8yuobhruu/standalone.xml if that helps.

On 04/09/2014 09:14 AM, Brian Stansberry wrote:
> If that change breaks existing configs, it's a major problem. For sure
> it has to be corrected for 8.0.1. We can't break existing configs in a
> bug fix release.
>
> On 4/9/14, 7:07 AM, Scott Marlow wrote:
>> I'm running with an older WildFly configuration (EE TCK) that probably
>> doesn't have the needed changes for the
>> "jboss.clustering.registry.ejb.default" service.  Rather than just
>> syncing up with the WFLY-3175 changes, I would like to know if the
>> dependencies on "jboss.clustering.registry.ejb.default" should be
>> optional so that people with older WildFly configurations do not get
>> service dependency errors on "jboss.clustering.registry.ejb.default"?
>>
>> Scott
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>


From paul.ferraro at redhat.com  Wed Apr  9 11:49:20 2014
From: paul.ferraro at redhat.com (Paul Ferraro)
Date: Wed, 09 Apr 2014 11:49:20 -0400
Subject: [wildfly-dev] regression caused by "WFLY-3175 Create
 non-clustered implementations of org.wildfly.clustering.api services"
 change
In-Reply-To: <534553A8.50502@redhat.com>
References: <5345380C.1080305@redhat.com> <534547CE.30405@redhat.com>
	<534553A8.50502@redhat.com>
Message-ID: <1397058560.2547.14.camel@T520>

Just to say, this config is different from the version shipped with
8.0.0.Final.  I should think we would run the TCK tests against the
config from that release.  If we did that, the failure below would not
have occurred.

On Wed, 2014-04-09 at 10:05 -0400, Scott Marlow wrote:
> Test configuration file that I'm using is available at 
> https://www.dropbox.com/s/3yedst8yuobhruu/standalone.xml if that helps.
> 
> On 04/09/2014 09:14 AM, Brian Stansberry wrote:
> > If that change breaks existing configs, it's a major problem. For sure
> > it has to be corrected for 8.0.1. We can't break existing configs in a
> > bug fix release.
> >
> > On 4/9/14, 7:07 AM, Scott Marlow wrote:
> >> I'm running with an older WildFly configuration (EE TCK) that probably
> >> doesn't have the needed changes for the
> >> "jboss.clustering.registry.ejb.default" service.  Rather than just
> >> syncing up with the WFLY-3175 changes, I would like to know if the
> >> dependencies on "jboss.clustering.registry.ejb.default" should be
> >> optional so that people with older WildFly configurations do not get
> >> service dependency errors on "jboss.clustering.registry.ejb.default"?
> >>
> >> Scott
> >> _______________________________________________
> >> wildfly-dev mailing list
> >> wildfly-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>
> >
> >
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



From marek.zupnik at gmail.com  Thu Apr 10 17:59:36 2014
From: marek.zupnik at gmail.com (=?ISO-8859-2?Q?Marek_=AFupnik?=)
Date: Thu, 10 Apr 2014 23:59:36 +0200
Subject: [wildfly-dev] Release date of 8.0.1 final
Message-ID: <CAGk6hhcsnKLKEYsi2+hFd3uxTQZ7hZP-nuUM++0v9dAoQL58Wg@mail.gmail.com>

Hi all,

I would like kindly ask if there is any estimation when 8.0.1.Final version
will be released?

Regards,
Marek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140410/b6af9c88/attachment.html 

From k.miksa at blogu.pl  Thu Apr 10 18:53:16 2014
From: k.miksa at blogu.pl (Krzysztof Miksa)
Date: Fri, 11 Apr 2014 00:53:16 +0200
Subject: [wildfly-dev] Release date of 8.0.1 final
In-Reply-To: <CAGk6hhcsnKLKEYsi2+hFd3uxTQZ7hZP-nuUM++0v9dAoQL58Wg@mail.gmail.com>
References: <CAGk6hhcsnKLKEYsi2+hFd3uxTQZ7hZP-nuUM++0v9dAoQL58Wg@mail.gmail.com>
Message-ID: <CANW4422_wZP1Z9=2bXmKyvOk0NpXcvE79C35VuqdLYsx6Je9nQ@mail.gmail.com>

When all blockers from:
https://issues.jboss.org/browse/WFLY-3178?jql=project%20%3D%20WFLY%20AND%20fixVersion%20%3D%20%228.0.1.Final%22%20AND%20resolution%20%3D%20Unresolved%20AND%20priority%20%3D%20Blocker%20ORDER%20BY%20key%20DESC
will be fixed.
Please vote for them :)



2014-04-10 23:59 GMT+02:00 Marek ?upnik <marek.zupnik at gmail.com>:

> Hi all,
>
> I would like kindly ask if there is any estimation when 8.0.1.Final
> version will be released?
>
> Regards,
> Marek
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140411/4de58702/attachment-0001.html 

From smarlow at redhat.com  Sat Apr 12 15:06:45 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Sat, 12 Apr 2014 15:06:45 -0400
Subject: [wildfly-dev] Failed to persist sessions:
 java.io.NotSerializableException at undeploy time
Message-ID: <53498EC5.2020104@redhat.com>

I'm running some tests with WildFly 8.0.1 master branch and seeing an 
intermittent failure.  Any ideas why http://pastie.org/9075646 might be 
occurring?  I see a number of these errors during an EJB test.  It is 
possible that this error is expected, I'm not sure.

Scott

From jason.greene at redhat.com  Sat Apr 12 15:11:21 2014
From: jason.greene at redhat.com (Jason Greene)
Date: Sat, 12 Apr 2014 14:11:21 -0500
Subject: [wildfly-dev] Failed to persist sessions:
	java.io.NotSerializableException at undeploy time
In-Reply-To: <53498EC5.2020104@redhat.com>
References: <53498EC5.2020104@redhat.com>
Message-ID: <4FF1FCFF-525D-43A6-9CF4-7C7D4D11C44A@redhat.com>

Does the TCK config have this in it, under the undertow servlet section?:

  <persistent-sessions/>


On Apr 12, 2014, at 2:06 PM, Scott Marlow <smarlow at redhat.com> wrote:

> I'm running some tests with WildFly 8.0.1 master branch and seeing an 
> intermittent failure.  Any ideas why http://pastie.org/9075646 might be 
> occurring?  I see a number of these errors during an EJB test.  It is 
> possible that this error is expected, I'm not sure.
> 
> Scott
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat


From jason.greene at redhat.com  Sat Apr 12 15:15:56 2014
From: jason.greene at redhat.com (Jason Greene)
Date: Sat, 12 Apr 2014 14:15:56 -0500
Subject: [wildfly-dev] Failed to persist sessions:
	java.io.NotSerializableException at undeploy time
In-Reply-To: <4FF1FCFF-525D-43A6-9CF4-7C7D4D11C44A@redhat.com>
References: <53498EC5.2020104@redhat.com>
	<4FF1FCFF-525D-43A6-9CF4-7C7D4D11C44A@redhat.com>
Message-ID: <CCBF11D0-BAAF-469E-AA23-DC616C012BA4@redhat.com>

It looks like it does:

                <persistent-sessions path="persistent-web-sessions" relative-to="jboss.server.data.dir"/>

We should pull that out. It?s a development feature, and it?s reliant on everything that is put in the session is serializable which is not strictly required. It?s odd though why it would intermittently fail. It should be deterministic.

On Apr 12, 2014, at 2:11 PM, Jason Greene <jason.greene at redhat.com> wrote:

> Does the TCK config have this in it, under the undertow servlet section?:
> 
>  <persistent-sessions/>
> 
> 
> On Apr 12, 2014, at 2:06 PM, Scott Marlow <smarlow at redhat.com> wrote:
> 
>> I'm running some tests with WildFly 8.0.1 master branch and seeing an 
>> intermittent failure.  Any ideas why http://pastie.org/9075646 might be 
>> occurring?  I see a number of these errors during an EJB test.  It is 
>> possible that this error is expected, I'm not sure.
>> 
>> Scott
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat



From smarlow at redhat.com  Sat Apr 12 15:17:34 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Sat, 12 Apr 2014 15:17:34 -0400
Subject: [wildfly-dev] Failed to persist sessions:
 java.io.NotSerializableException at undeploy time
In-Reply-To: <CCBF11D0-BAAF-469E-AA23-DC616C012BA4@redhat.com>
References: <53498EC5.2020104@redhat.com>
	<4FF1FCFF-525D-43A6-9CF4-7C7D4D11C44A@redhat.com>
	<CCBF11D0-BAAF-469E-AA23-DC616C012BA4@redhat.com>
Message-ID: <5349914E.1090303@redhat.com>

http://pastie.org/9075691 shows what we are using and that we do have 
"<persistent-sessions path="persistent-web-sessions" 
relative-to="jboss.server.data.dir"/>"

On 04/12/2014 03:15 PM, Jason Greene wrote:
> It looks like it does:
>
>                  <persistent-sessions path="persistent-web-sessions" relative-to="jboss.server.data.dir"/>
>
> We should pull that out. It?s a development feature, and it?s reliant on everything that is put in the session is serializable which is not strictly required. It?s odd though why it would intermittently fail. It should be deterministic.
>
> On Apr 12, 2014, at 2:11 PM, Jason Greene <jason.greene at redhat.com> wrote:
>
>> Does the TCK config have this in it, under the undertow servlet section?:
>>
>>   <persistent-sessions/>
>>
>>
>> On Apr 12, 2014, at 2:06 PM, Scott Marlow <smarlow at redhat.com> wrote:
>>
>>> I'm running some tests with WildFly 8.0.1 master branch and seeing an
>>> intermittent failure.  Any ideas why http://pastie.org/9075646 might be
>>> occurring?  I see a number of these errors during an EJB test.  It is
>>> possible that this error is expected, I'm not sure.
>>>
>>> Scott
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>> --
>> Jason T. Greene
>> WildFly Lead / JBoss EAP Platform Architect
>> JBoss, a division of Red Hat
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>


From smarlow at redhat.com  Sat Apr 12 15:29:29 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Sat, 12 Apr 2014 15:29:29 -0400
Subject: [wildfly-dev] Failed to persist sessions:
 java.io.NotSerializableException at undeploy time
In-Reply-To: <CCBF11D0-BAAF-469E-AA23-DC616C012BA4@redhat.com>
References: <53498EC5.2020104@redhat.com>
	<4FF1FCFF-525D-43A6-9CF4-7C7D4D11C44A@redhat.com>
	<CCBF11D0-BAAF-469E-AA23-DC616C012BA4@redhat.com>
Message-ID: <53499419.8000005@redhat.com>

On 04/12/2014 03:15 PM, Jason Greene wrote:
> It looks like it does:
>
>                  <persistent-sessions path="persistent-web-sessions" relative-to="jboss.server.data.dir"/>
>
> We should pull that out. It?s a development feature, and it?s reliant on everything that is put in the session is serializable which is not strictly required. It?s odd though why it would intermittently fail. It should be deterministic.

Hmm, it shouldn't impact our test results since its just a warning. 
False alarm on my part as the NotSerializableException has no impact...

>
> On Apr 12, 2014, at 2:11 PM, Jason Greene <jason.greene at redhat.com> wrote:
>
>> Does the TCK config have this in it, under the undertow servlet section?:
>>
>>   <persistent-sessions/>
>>
>>
>> On Apr 12, 2014, at 2:06 PM, Scott Marlow <smarlow at redhat.com> wrote:
>>
>>> I'm running some tests with WildFly 8.0.1 master branch and seeing an
>>> intermittent failure.  Any ideas why http://pastie.org/9075646 might be
>>> occurring?  I see a number of these errors during an EJB test.  It is
>>> possible that this error is expected, I'm not sure.
>>>
>>> Scott
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>> --
>> Jason T. Greene
>> WildFly Lead / JBoss EAP Platform Architect
>> JBoss, a division of Red Hat
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>


From tomaz.cerar at gmail.com  Sat Apr 12 15:42:33 2014
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Sat, 12 Apr 2014 12:42:33 -0700
Subject: [wildfly-dev] Failed to persist sessions:
 java.io.NotSerializableException at undeploy time
Message-ID: <-2419181728717715887@unknownmsgid>

That should not be there, it is not stable enough yet!
For same reason we removed it from default shipped configs before
8.0.0.Final.

In any case it is just warn and should not effect application deployed
beyond redundant logs.

--
Tomaz From: Scott Marlow
Sent: ?12.?4.?2014 21:17
To: Jason Greene
Cc: wildfly-dev at lists.jboss.org
Subject: Re: [wildfly-dev] Failed to persist sessions:
java.io.NotSerializableException at undeploy time
http://pastie.org/9075691 shows what we are using and that we do have
"<persistent-sessions path="persistent-web-sessions"
relative-to="jboss.server.data.dir"/>"

On 04/12/2014 03:15 PM, Jason Greene wrote:
> It looks like it does:
>
>                  <persistent-sessions path="persistent-web-sessions" relative-to="jboss.server.data.dir"/>
>
> We should pull that out. It?s a development feature, and it?s reliant on everything that is put in the session is serializable which is not strictly required. It?s odd though why it would intermittently fail. It should be deterministic.
>
> On Apr 12, 2014, at 2:11 PM, Jason Greene <jason.greene at redhat.com> wrote:
>
>> Does the TCK config have this in it, under the undertow servlet section?:
>>
>>   <persistent-sessions/>
>>
>>
>> On Apr 12, 2014, at 2:06 PM, Scott Marlow <smarlow at redhat.com> wrote:
>>
>>> I'm running some tests with WildFly 8.0.1 master branch and seeing an
>>> intermittent failure.  Any ideas why http://pastie.org/9075646 might be
>>> occurring?  I see a number of these errors during an EJB test.  It is
>>> possible that this error is expected, I'm not sure.
>>>
>>> Scott
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>> --
>> Jason T. Greene
>> WildFly Lead / JBoss EAP Platform Architect
>> JBoss, a division of Red Hat
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>

_______________________________________________
wildfly-dev mailing list
wildfly-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev


From smarlow at redhat.com  Sat Apr 12 15:56:59 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Sat, 12 Apr 2014 15:56:59 -0400
Subject: [wildfly-dev] Failed to persist sessions:
 java.io.NotSerializableException at undeploy time
In-Reply-To: <-2419181728717715887@unknownmsgid>
References: <-2419181728717715887@unknownmsgid>
Message-ID: <53499A8B.5010807@redhat.com>

I'll remove the persistent-sessions setting to reduce the noise.  Thanks 
for the feedback!

On 04/12/2014 03:42 PM, Toma? Cerar wrote:
> That should not be there, it is not stable enough yet!
> For same reason we removed it from default shipped configs before
> 8.0.0.Final.
>
> In any case it is just warn and should not effect application deployed
> beyond redundant logs.
>
> --
> Tomaz From: Scott Marlow
> Sent: ?12.?4.?2014 21:17
> To: Jason Greene
> Cc: wildfly-dev at lists.jboss.org
> Subject: Re: [wildfly-dev] Failed to persist sessions:
> java.io.NotSerializableException at undeploy time
> http://pastie.org/9075691 shows what we are using and that we do have
> "<persistent-sessions path="persistent-web-sessions"
> relative-to="jboss.server.data.dir"/>"
>
> On 04/12/2014 03:15 PM, Jason Greene wrote:
>> It looks like it does:
>>
>>                   <persistent-sessions path="persistent-web-sessions" relative-to="jboss.server.data.dir"/>
>>
>> We should pull that out. It?s a development feature, and it?s reliant on everything that is put in the session is serializable which is not strictly required. It?s odd though why it would intermittently fail. It should be deterministic.
>>
>> On Apr 12, 2014, at 2:11 PM, Jason Greene <jason.greene at redhat.com> wrote:
>>
>>> Does the TCK config have this in it, under the undertow servlet section?:
>>>
>>>    <persistent-sessions/>
>>>
>>>
>>> On Apr 12, 2014, at 2:06 PM, Scott Marlow <smarlow at redhat.com> wrote:
>>>
>>>> I'm running some tests with WildFly 8.0.1 master branch and seeing an
>>>> intermittent failure.  Any ideas why http://pastie.org/9075646 might be
>>>> occurring?  I see a number of these errors during an EJB test.  It is
>>>> possible that this error is expected, I'm not sure.
>>>>
>>>> Scott
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>> --
>>> Jason T. Greene
>>> WildFly Lead / JBoss EAP Platform Architect
>>> JBoss, a division of Red Hat
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>> --
>> Jason T. Greene
>> WildFly Lead / JBoss EAP Platform Architect
>> JBoss, a division of Red Hat
>>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


From jason.greene at redhat.com  Mon Apr 14 13:36:43 2014
From: jason.greene at redhat.com (Jason Greene)
Date: Mon, 14 Apr 2014 10:36:43 -0700
Subject: [wildfly-dev] 8.1.0.CR1 Released, Replaces 8.0.1
Message-ID: <D8FEAA72-2DAF-4FE2-8D32-7C73F06CEFB5@redhat.com>

Hello Everyone,

After an IRC discussion, we decided that since 8.0.1 had included some small features to address a few usability problems, that it was more appropriate to label it as a minor release. Our standard process for all feature releases is to release at least one CR to catch any unexpected problems. If you could please give it a try, and raise the flag if you notice a problem.

Provided no blockers are uncovered, we will promote the CR to Final status.

As always you can download the release here:
http://wildfly.org/downloads/

The release notes are available here:
https://community.jboss.org/wiki/WildFly810CR1ReleaseNotes

Thanks, and sorry for any confusion this may have caused.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat



From tomaz.cerar at gmail.com  Mon Apr 14 17:36:50 2014
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Mon, 14 Apr 2014 23:36:50 +0200
Subject: [wildfly-dev] 8.1.0.CR1 Released, Replaces 8.0.1
In-Reply-To: <D8FEAA72-2DAF-4FE2-8D32-7C73F06CEFB5@redhat.com>
References: <D8FEAA72-2DAF-4FE2-8D32-7C73F06CEFB5@redhat.com>
Message-ID: <CAMquZP4SgebOkGfcO-dcQJ-NCKyc3SEX+HrqQtRnoiyvMPmWpw@mail.gmail.com>

If anyone sees that we missed something in release notes,
please feel free to edit the document.

--
tomaz


On Mon, Apr 14, 2014 at 7:36 PM, Jason Greene <jason.greene at redhat.com>wrote:

> Hello Everyone,
>
> After an IRC discussion, we decided that since 8.0.1 had included some
> small features to address a few usability problems, that it was more
> appropriate to label it as a minor release. Our standard process for all
> feature releases is to release at least one CR to catch any unexpected
> problems. If you could please give it a try, and raise the flag if you
> notice a problem.
>
> Provided no blockers are uncovered, we will promote the CR to Final status.
>
> As always you can download the release here:
> http://wildfly.org/downloads/
>
> The release notes are available here:
> https://community.jboss.org/wiki/WildFly810CR1ReleaseNotes
>
> Thanks, and sorry for any confusion this may have caused.
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140414/37b38136/attachment-0001.html 

From arun.gupta at gmail.com  Tue Apr 15 10:02:19 2014
From: arun.gupta at gmail.com (Arun Gupta)
Date: Tue, 15 Apr 2014 07:02:19 -0700
Subject: [wildfly-dev] Hibernate 4.3.5 and JDK 8
Message-ID: <CAGBoHQUuMnSK6qP=1eu1Lnw+=5gs2s9z=QZ3Z2wG0z8ppJQ-6g@mail.gmail.com>

FYI http://www.reddit.com/r/java/comments/2327oi/heads_up_using_hibernate_with_java_8/

It'll be great if this can be fixed in WildFly 8.1.

Arun

-- 
http://blog.arungupta.me
http://twitter.com/arungupta

From david.lloyd at redhat.com  Tue Apr 15 10:08:40 2014
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Tue, 15 Apr 2014 09:08:40 -0500
Subject: [wildfly-dev] Hibernate 4.3.5 and JDK 8
In-Reply-To: <CAGBoHQUuMnSK6qP=1eu1Lnw+=5gs2s9z=QZ3Z2wG0z8ppJQ-6g@mail.gmail.com>
References: <CAGBoHQUuMnSK6qP=1eu1Lnw+=5gs2s9z=QZ3Z2wG0z8ppJQ-6g@mail.gmail.com>
Message-ID: <534D3D68.9030607@redhat.com>

On 04/15/2014 09:02 AM, Arun Gupta wrote:
> FYI http://www.reddit.com/r/java/comments/2327oi/heads_up_using_hibernate_with_java_8/
>
> It'll be great if this can be fixed in WildFly 8.1.

If you read the stack trace, it appears that the bug is in the JDK 
itself.  Furthermore, it is triggered by Hibernate, not WildFly.  Is 
there a Hibernate JIRA opened for this issue?  That is the right place 
to report it; if they agree it's a JDK issue then the JDK bug tracker is 
the next step, ideally followed by an OpenJDK patch.


-- 
- DML

From steve at hibernate.org  Tue Apr 15 10:17:52 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 15 Apr 2014 09:17:52 -0500
Subject: [wildfly-dev] Hibernate 4.3.5 and JDK 8
In-Reply-To: <534D3D68.9030607@redhat.com>
References: <CAGBoHQUuMnSK6qP=1eu1Lnw+=5gs2s9z=QZ3Z2wG0z8ppJQ-6g@mail.gmail.com>
	<534D3D68.9030607@redhat.com>
Message-ID: <CAFdSV9sRE5XAfb6gX6q+WsH6gk0=wZtm0KMGySvEp=H0CRg88Q@mail.gmail.com>

I'd have to look into the expectation of
java.lang.reflect.Method#getGenericReturnType in regards to a method like
the ones noted.  I agree that on the surface it seems strange that the JDK
would be throwing that exception here.





On Tue, Apr 15, 2014 at 9:08 AM, David M. Lloyd <david.lloyd at redhat.com>wrote:

> On 04/15/2014 09:02 AM, Arun Gupta wrote:
> > FYI
> http://www.reddit.com/r/java/comments/2327oi/heads_up_using_hibernate_with_java_8/
> >
> > It'll be great if this can be fixed in WildFly 8.1.
>
> If you read the stack trace, it appears that the bug is in the JDK
> itself.  Furthermore, it is triggered by Hibernate, not WildFly.  Is
> there a Hibernate JIRA opened for this issue?  That is the right place
> to report it; if they agree it's a JDK issue then the JDK bug tracker is
> the next step, ideally followed by an OpenJDK patch.
>
>
> --
> - DML
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140415/0373c0c3/attachment.html 

From arun.gupta at gmail.com  Tue Apr 15 12:04:11 2014
From: arun.gupta at gmail.com (Arun Gupta)
Date: Tue, 15 Apr 2014 09:04:11 -0700
Subject: [wildfly-dev] Hibernate 4.3.5 and JDK 8
In-Reply-To: <534D3D68.9030607@redhat.com>
References: <CAGBoHQUuMnSK6qP=1eu1Lnw+=5gs2s9z=QZ3Z2wG0z8ppJQ-6g@mail.gmail.com>
	<534D3D68.9030607@redhat.com>
Message-ID: <CAGBoHQV85MUVU3yFejhdQM5hwEZhiPnBX8KfFsFc7DXdJCRrDg@mail.gmail.com>

Somebody reported this error to me on twitter yesterday and I already
asked them to report the bug (with reproducible test case) on
Hibernate.

Arun

On Tue, Apr 15, 2014 at 7:08 AM, David M. Lloyd <david.lloyd at redhat.com> wrote:
> On 04/15/2014 09:02 AM, Arun Gupta wrote:
>> FYI http://www.reddit.com/r/java/comments/2327oi/heads_up_using_hibernate_with_java_8/
>>
>> It'll be great if this can be fixed in WildFly 8.1.
>
> If you read the stack trace, it appears that the bug is in the JDK
> itself.  Furthermore, it is triggered by Hibernate, not WildFly.  Is
> there a Hibernate JIRA opened for this issue?  That is the right place
> to report it; if they agree it's a JDK issue then the JDK bug tracker is
> the next step, ideally followed by an OpenJDK patch.
>
>
> --
> - DML
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



-- 
http://blog.arungupta.me
http://twitter.com/arungupta

From jperkins at redhat.com  Wed Apr 16 11:08:17 2014
From: jperkins at redhat.com (James R. Perkins)
Date: Wed, 16 Apr 2014 08:08:17 -0700
Subject: [wildfly-dev] Exclusions in WildFly
In-Reply-To: <CANDP1e_QT9=V4aXFTTun39YdnijoUWigS1m9nywcR3xXc2vD_A@mail.gmail.com>
References: <CANDP1e_QT9=V4aXFTTun39YdnijoUWigS1m9nywcR3xXc2vD_A@mail.gmail.com>
Message-ID: <534E9CE1.6000604@redhat.com>

Please direct questions like this to the forums 
https://community.jboss.org/en/wildfly. This list is used for 
collaboration of WildFly development.

On 04/08/2014 05:54 AM, Juan Manuel CABRERA wrote:
> Hello devs,
>
> I have a wildfly war application at hands, which depends on a jar 
> which starts its own JPA persistence container with Spring. This jar 
> has its own `persistence.xml`, with  only one persistence unit.
> In the embedded jar, since there is only one persistence unit, it is 
> injected using a `@PersistenceContext` without a unit name. 
> Furthermore, the objects having such fields are not EJBs, they are 
> simple Spring beans...
>
> On the other hand, the application has also a `persistence.xml` with 
> two persistence units.
> The code of the application has `@PersistenceContext` fields with a 
> proper `unitName`, which is mandatory since there are two of them.
>
> Now, when I start my application, Wildfly (specifically the jpa 
> module) scans the code from the jar and chokes on the 
> `@PersistenceContext` without unitNames of my Spring beans:
>
>     DEBUG [org.jboss.as.jpa.messages] (MSC service thread 1-1) 
> persistence unit search for unitName=null referenced from 
> class=the.spring.Bean 
> (annotation=@javax.persistence.PersistenceContext() on void 
> the.spring.Bean.setEntityManager(javax.persistence.EntityManager))
>
>
> To cope with this, I would like to exclude the jar: In TomEE there is 
> a mean to exclude a jar explicitly from being scanned, but I cannot 
> find a similar functionnality in WildFly.
> I have tried the following configurations without success:
>
>  - `jboss-deployment-structure.xml` which is read but without 
> noticeable effect:
>
>         <jboss-deployment-structure 
> xmlns="urn:jboss:deployment-structure:1.2">
>           <deployment>
>             <exclusions>
>               <module name="deployment.jee-app.war.spring-app.jar" />
>               <!-- I have also tried the following -->
>               <!-- <module name="jee-app.war.spring-app.jar" /> -->
>               <!-- <module name="spring-app.jar" /> -->
>             </exclusions>
>           </deployment>
>         </jboss-deployment-structure>
>
>  - `jboss-scanning.xml` which seems to be ignored
>
>         <scanning xmlns="urn:jboss:scanning:1.0">
>           <path name="jee-app.war/WEB-INF/lib">
>             <exclude name="spring-app.jar" />
>           </path>
>         </scanning>
>
>
> Both of these files are in the WEB-INF folder of my war application.
>
> Of course, I cannot modify the spring-app.jar (would be too easy...)
>
> Needless to say, I have spend a considerable amount of time in the 
> WildFly doc and on Google without finding anything else than exluding 
> subsystems, or overriding locally modules of WildFly...
>
> Thanks for your help!
>
> Juan Manuel
>
> PS: This question is also posted on StackOverflow: 
> http://stackoverflow.com/q/22932015/3509723
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-- 
James R. Perkins
JBoss by Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140416/d8ce3ef5/attachment.html 

From hanasaki at gmail.com  Fri Apr 18 14:35:57 2014
From: hanasaki at gmail.com (hanasaki at gmail.com)
Date: Fri, 18 Apr 2014 13:35:57 -0500
Subject: [wildfly-dev] issues with modules name differences in wildfly vs
 jboss eap (mvn scope and duplicate jar files)
Message-ID: <5351708D.5050707@gmail.com>

wildfly modules
	* include some open source non-JBoss modules
	* named the same as in Internet maven repositories
JBoss eap commercial product modules AND maven eap repo zip download
	* include the same modules as wildfly
	* named differently : suffixed with ex: "-redhat-3"
	* some might have been named ".redhat-3"

1. Should my projects use the internet version of the open source libs 
that are provided as JBoss modules or the JBoss modules by name?
2. If using the jboss modules by name (and jboss specific version 
number) they I assume the maven pom.xml would depend on them as
	<scope>provided</scope>
	instead of
	<scope>compile</scope>
	???
3. If using the modules from jboss/wildfly as "provided"
	- how to build one WAR/EAR that deploys on wildfly and eap?
4. if depending on a jboss "-redhat-3" version, this will depend on the 
other app server provided modules.  There is an issue if the project 
uses X and A below.
	X-1.2.3-redhat-_ depends on Y-..-redhat-_ from the repo zip
		which is OK
	A-5.6.7 depends on Y all not from the mvn repo zip
		which is OK
	project depends on X (in repo zip) and A (not in repo zip)
		NOT OK - project gets Y (internet) and Y (from repo zip)
	based on maven build


From bburke at redhat.com  Fri Apr 18 18:44:56 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 18 Apr 2014 18:44:56 -0400
Subject: [wildfly-dev] my 2 cents on Security Manager discussion
Message-ID: <5351AAE8.5010107@redhat.com>

Late to the discussion, but this came up in conversations at DevNation.

Are you sure you guys want to fully enable the Java security manager 
going forward?  Jboss has been around for, what 14 years now?  How many 
users/customers actually desire the Java Security Manager to be on by 
default?  Could it be a possibility that the majority of our 
customers/users might freak out if they found that all of a sudden the 
Java Security Manager is on when it has been off the last 14 years?

I don't know.  Just seems to me that there is a lot of other cool ideas 
that you guys have been discussing that might be more interesting to 
wildfly's user base.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stuart.w.douglas at gmail.com  Fri Apr 18 18:50:11 2014
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Sat, 19 Apr 2014 08:50:11 +1000
Subject: [wildfly-dev] my 2 cents on Security Manager discussion
In-Reply-To: <5351AAE8.5010107@redhat.com>
References: <5351AAE8.5010107@redhat.com>
Message-ID: <5351AC23.1090903@gmail.com>

Who is talking about enabling this by default?

What we have done is add a security manager subsystem that makes it very 
easy to enable, and also implement the Java EE 7 standard permission.xml 
descriptor to allow for a standard method of configuring permissions.

I have not heard anyone suggest this should be enabled by default, and I 
don't think it ever will be for two main reasons:

- Performance: Enabling the security manager has a very noticeable 
impact on performance. The checks are expensive and there are a lot of 
them.

- Compatibility: Unless you have actually written your application 
expecting it to be run under a security manager it almost certainly 
won't work out of the box.

Enabling the security manager by default is a terrible idea.

Stuart


Bill Burke wrote:
> Late to the discussion, but this came up in conversations at DevNation.
>
> Are you sure you guys want to fully enable the Java security manager
> going forward?  Jboss has been around for, what 14 years now?  How many
> users/customers actually desire the Java Security Manager to be on by
> default?  Could it be a possibility that the majority of our
> customers/users might freak out if they found that all of a sudden the
> Java Security Manager is on when it has been off the last 14 years?
>
> I don't know.  Just seems to me that there is a lot of other cool ideas
> that you guys have been discussing that might be more interesting to
> wildfly's user base.
>

From manderse at redhat.com  Fri Apr 18 19:14:32 2014
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Sat, 19 Apr 2014 01:14:32 +0200
Subject: [wildfly-dev] Hibernate 4.3.5 and JDK 8
In-Reply-To: <CAGBoHQV85MUVU3yFejhdQM5hwEZhiPnBX8KfFsFc7DXdJCRrDg@mail.gmail.com>
References: <CAGBoHQUuMnSK6qP=1eu1Lnw+=5gs2s9z=QZ3Z2wG0z8ppJQ-6g@mail.gmail.com>
	<534D3D68.9030607@redhat.com>
	<CAGBoHQV85MUVU3yFejhdQM5hwEZhiPnBX8KfFsFc7DXdJCRrDg@mail.gmail.com>
Message-ID: <A739CA35-3997-40FE-A5D0-30D674E17FF8@redhat.com>

On 15 Apr 2014, at 18:04, Arun Gupta wrote:

> Somebody reported this error to me on twitter yesterday and I already
> asked them to report the bug (with reproducible test case) on
> Hibernate.

They opened it at https://hibernate.atlassian.net/browse/HHH-9132
/max

> Arun
>
> On Tue, Apr 15, 2014 at 7:08 AM, David M. Lloyd 
> <david.lloyd at redhat.com> wrote:
>> On 04/15/2014 09:02 AM, Arun Gupta wrote:
>>> FYI 
>>> http://www.reddit.com/r/java/comments/2327oi/heads_up_using_hibernate_with_java_8/
>>>
>>> It'll be great if this can be fixed in WildFly 8.1.
>>
>> If you read the stack trace, it appears that the bug is in the JDK
>> itself.  Furthermore, it is triggered by Hibernate, not WildFly.  Is
>> there a Hibernate JIRA opened for this issue?  That is the right 
>> place
>> to report it; if they agree it's a JDK issue then the JDK bug tracker 
>> is
>> the next step, ideally followed by an OpenJDK patch.
>>
>>
>> --
>> - DML
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> -- 
> http://blog.arungupta.me
> http://twitter.com/arungupta
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


/max
http://about.me/maxandersen


From manderse at redhat.com  Fri Apr 18 19:25:16 2014
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Sat, 19 Apr 2014 01:25:16 +0200
Subject: [wildfly-dev] Hibernate 4.3.5 and JDK 8
In-Reply-To: <CAGBoHQV85MUVU3yFejhdQM5hwEZhiPnBX8KfFsFc7DXdJCRrDg@mail.gmail.com>
References: <CAGBoHQUuMnSK6qP=1eu1Lnw+=5gs2s9z=QZ3Z2wG0z8ppJQ-6g@mail.gmail.com>
	<534D3D68.9030607@redhat.com>
	<CAGBoHQV85MUVU3yFejhdQM5hwEZhiPnBX8KfFsFc7DXdJCRrDg@mail.gmail.com>
Message-ID: <9DB5D3AA-DADC-4ABE-B560-D66BF54D0589@redhat.com>

On 15 Apr 2014, at 18:04, Arun Gupta wrote:

> Somebody reported this error to me on twitter yesterday and I already
> asked them to report the bug (with reproducible test case) on
> Hibernate.

They opened it at https://hibernate.atlassian.net/browse/HHH-9132
/max

> Arun
>
> On Tue, Apr 15, 2014 at 7:08 AM, David M. Lloyd 
> <david.lloyd at redhat.com> wrote:
>> On 04/15/2014 09:02 AM, Arun Gupta wrote:
>>> FYI 
>>> http://www.reddit.com/r/java/comments/2327oi/heads_up_using_hibernate_with_java_8/
>>>
>>> It'll be great if this can be fixed in WildFly 8.1.
>>
>> If you read the stack trace, it appears that the bug is in the JDK
>> itself.  Furthermore, it is triggered by Hibernate, not WildFly.  Is
>> there a Hibernate JIRA opened for this issue?  That is the right 
>> place
>> to report it; if they agree it's a JDK issue then the JDK bug tracker 
>> is
>> the next step, ideally followed by an OpenJDK patch.
>>
>>
>> --
>> - DML
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> -- 
> http://blog.arungupta.me
> http://twitter.com/arungupta
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


/max
http://about.me/maxandersen


From jgreene at redhat.com  Fri Apr 18 19:53:31 2014
From: jgreene at redhat.com (Jason T. Greene)
Date: Fri, 18 Apr 2014 19:53:31 -0400 (EDT)
Subject: [wildfly-dev] my 2 cents on Security Manager discussion
In-Reply-To: <5351AC23.1090903@gmail.com>
References: <5351AAE8.5010107@redhat.com> <5351AC23.1090903@gmail.com>
Message-ID: <7EC05876-28DA-44EA-8CF0-CFD5D85A37E7@redhat.com>



Sent from my iPhone

> On Apr 18, 2014, at 5:50 PM, Stuart Douglas <stuart.w.douglas at gmail.com> wrote:
> 
> 
> Enabling the security manager by default is a terrible idea.

+1000

From david.lloyd at redhat.com  Sat Apr 19 09:34:39 2014
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Sat, 19 Apr 2014 08:34:39 -0500
Subject: [wildfly-dev] my 2 cents on Security Manager discussion
In-Reply-To: <5351AAE8.5010107@redhat.com>
References: <5351AAE8.5010107@redhat.com>
Message-ID: <53527B6F.5090803@redhat.com>

On 04/18/2014 05:44 PM, Bill Burke wrote:
> Late to the discussion, but this came up in conversations at DevNation.
>
> Are you sure you guys want to fully enable the Java security manager
> going forward?  Jboss has been around for, what 14 years now?  How many
> users/customers actually desire the Java Security Manager to be on by
> default?  Could it be a possibility that the majority of our
> customers/users might freak out if they found that all of a sudden the
> Java Security Manager is on when it has been off the last 14 years?
>
> I don't know.  Just seems to me that there is a lot of other cool ideas
> that you guys have been discussing that might be more interesting to
> wildfly's user base.

For the record I think Java's security model is pretty terrible.  Years 
of really, really bad CVEs are pretty much all the evidence you need. 
But security manager support is a part of Java EE now, as of 7 - and 
worse yet it is inexorably tied up with several JAAS concepts, making it 
a constant pain for us, as users want to be able to use JAAS even though 
it is terrible and it itself is not formally a part of Java EE (it is, 
after all, the only standard authentication client API).  Given our 
newer security initiatives, problems have arisen that we do have to 
solve, and that means we have to think about how it impacts this stuff too.

So, this is why we've spent time dealing with this.  There are tons of 
other things I for one would rather be doing, believe me. :-)
-- 
- DML

From dador92 at gmail.com  Sat Apr 19 13:20:31 2014
From: dador92 at gmail.com (Jim McGuinness)
Date: Sat, 19 Apr 2014 12:20:31 -0500
Subject: [wildfly-dev] my 2 cents on Security Manager discussion
In-Reply-To: <53527B6F.5090803@redhat.com>
References: <5351AAE8.5010107@redhat.com>
	<53527B6F.5090803@redhat.com>
Message-ID: <CALbcAPWZsiBWM1wei2yL7rgqNMAwA6UdSUMsGKGK5o7z5miOyQ@mail.gmail.com>

So from an external-to-Red-Hat perspective, leave the Java security manager
off as the wildfly default setting. While security continues to become more
important at the application level, I think you need to consider the
explicit/implicit objectives of wildfly: (a) provide an implementation of
the latest Java EE specs so developers/architects can work with it and
prepare for future work on projects and in production, and (b)
suggest/persuade non Red Hat customers to switch to JBoss. Turning on the
Java security manager in wildfly by default could really sour a lot of
developers/architects on Red Hat, not to mention wildfly. Consequently they
would most likely just switch to using glassfish.

But you want want to keep it easy and obvious to turn on the Java security
manager in wildfly.

Just my 2?.


On Sat, Apr 19, 2014 at 8:34 AM, David M. Lloyd <david.lloyd at redhat.com>wrote:

> On 04/18/2014 05:44 PM, Bill Burke wrote:
> > Late to the discussion, but this came up in conversations at DevNation.
> >
> > Are you sure you guys want to fully enable the Java security manager
> > going forward?  Jboss has been around for, what 14 years now?  How many
> > users/customers actually desire the Java Security Manager to be on by
> > default?  Could it be a possibility that the majority of our
> > customers/users might freak out if they found that all of a sudden the
> > Java Security Manager is on when it has been off the last 14 years?
> >
> > I don't know.  Just seems to me that there is a lot of other cool ideas
> > that you guys have been discussing that might be more interesting to
> > wildfly's user base.
>
> For the record I think Java's security model is pretty terrible.  Years
> of really, really bad CVEs are pretty much all the evidence you need.
> But security manager support is a part of Java EE now, as of 7 - and
> worse yet it is inexorably tied up with several JAAS concepts, making it
> a constant pain for us, as users want to be able to use JAAS even though
> it is terrible and it itself is not formally a part of Java EE (it is,
> after all, the only standard authentication client API).  Given our
> newer security initiatives, problems have arisen that we do have to
> solve, and that means we have to think about how it impacts this stuff too.
>
> So, this is why we've spent time dealing with this.  There are tons of
> other things I for one would rather be doing, believe me. :-)
> --
> - DML
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140419/951450ea/attachment.html 

From arjan.tijms at gmail.com  Sat Apr 19 13:43:24 2014
From: arjan.tijms at gmail.com (arjan tijms)
Date: Sat, 19 Apr 2014 19:43:24 +0200
Subject: [wildfly-dev] my 2 cents on Security Manager discussion
In-Reply-To: <7EC05876-28DA-44EA-8CF0-CFD5D85A37E7@redhat.com>
References: <5351AAE8.5010107@redhat.com> <5351AC23.1090903@gmail.com>
	<7EC05876-28DA-44EA-8CF0-CFD5D85A37E7@redhat.com>
Message-ID: <CAE=-AhDGUmJKJHuv0TnDEsnfGXXNy3aWvyARr1B=Kpx9ndZc8g@mail.gmail.com>

Hi,

Just wondering, but what is the primary use case for a security manager
server side?

While the model obviously makes sense for Applets and Webstart where
untrusted code is executed on the user's machine, I found it to be
extremely rare for a server to run untrusted code. In fact, I don't think
I've ever seen this situation.

There's maybe a case to prevent privilege escalation in case of a
legitimate app being hacked, but in practice it doesn't look like a
security manager is really being used a lot for that, is it? Instead the
default thing to do there seems to be to run the AS under a user with
limited rights on the host OS and/or use things like SELinix or Virtual
Servers (e.g. XEN) to isolate the complete AS.

Kind regards,
Arjan Tijms





On Sat, Apr 19, 2014 at 1:53 AM, Jason T. Greene <jgreene at redhat.com> wrote:

>
>
> Sent from my iPhone
>
> > On Apr 18, 2014, at 5:50 PM, Stuart Douglas <stuart.w.douglas at gmail.com>
> wrote:
> >
> >
> > Enabling the security manager by default is a terrible idea.
>
> +1000
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140419/e8a491c6/attachment.html 

From bburke at redhat.com  Sat Apr 19 16:46:03 2014
From: bburke at redhat.com (Bill Burke)
Date: Sat, 19 Apr 2014 16:46:03 -0400
Subject: [wildfly-dev] my 2 cents on Security Manager discussion
In-Reply-To: <5351AC23.1090903@gmail.com>
References: <5351AAE8.5010107@redhat.com> <5351AC23.1090903@gmail.com>
Message-ID: <5352E08B.1070403@redhat.com>

O, never mind then.  I thought that's what you were discussing a few 
weeks ago.  I think others thought the same which is why I brought it up.

On 4/18/2014 6:50 PM, Stuart Douglas wrote:
> Who is talking about enabling this by default?
>
> What we have done is add a security manager subsystem that makes it very
> easy to enable, and also implement the Java EE 7 standard permission.xml
> descriptor to allow for a standard method of configuring permissions.
>
> I have not heard anyone suggest this should be enabled by default, and I
> don't think it ever will be for two main reasons:
>
> - Performance: Enabling the security manager has a very noticeable
> impact on performance. The checks are expensive and there are a lot of
> them.
>
> - Compatibility: Unless you have actually written your application
> expecting it to be run under a security manager it almost certainly
> won't work out of the box.
>
> Enabling the security manager by default is a terrible idea.
>
> Stuart
>
>
> Bill Burke wrote:
>> Late to the discussion, but this came up in conversations at DevNation.
>>
>> Are you sure you guys want to fully enable the Java security manager
>> going forward?  Jboss has been around for, what 14 years now?  How many
>> users/customers actually desire the Java Security Manager to be on by
>> default?  Could it be a possibility that the majority of our
>> customers/users might freak out if they found that all of a sudden the
>> Java Security Manager is on when it has been off the last 14 years?
>>
>> I don't know.  Just seems to me that there is a lot of other cool ideas
>> that you guys have been discussing that might be more interesting to
>> wildfly's user base.
>>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From hanasaki at gmail.com  Sun Apr 20 17:56:51 2014
From: hanasaki at gmail.com (hanasaki at gmail.com)
Date: Sun, 20 Apr 2014 16:56:51 -0500
Subject: [wildfly-dev] Should deployed EAR WAR files include wildfly module
	provided JAR's?
Message-ID: <535442A3.4090106@gmail.com>

wildfly modules contain some open source jar files.

1. should WAR and EAR files include these or list them as maven scope 
provided and use the jboss deployment descriptor to have the app server 
include them in the classpath from the app server module?
2. Does the answer change for modules that are jboss.api=private vs 
those that are not private?

The below reference has some information however do not definitively 
state a best practice and why.

reference:
http://wildfly-development.1055759.n5.nabble.com/what-is-jboss-api-private-exactly-td5711072.html

From rstryker at redhat.com  Mon Apr 21 09:47:49 2014
From: rstryker at redhat.com (Rob Stryker)
Date: Mon, 21 Apr 2014 21:47:49 +0800
Subject: [wildfly-dev] Java-8 Support for various appserver versions
Message-ID: <53552185.60304@redhat.com>

Can anyone tell me the following:
    1) What server versions will work with Java 8
    2) What server versions will **require** Java 8 to work properly?

Feel free to answer with all varients of our products... so anything 
from AS 4 through wf8.x, eap*, soa*, etc etc.

Thanks in advance.

From brian.stansberry at redhat.com  Mon Apr 21 11:50:17 2014
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 21 Apr 2014 10:50:17 -0500
Subject: [wildfly-dev] Java-8 Support for various appserver versions
In-Reply-To: <53552185.60304@redhat.com>
References: <53552185.60304@redhat.com>
Message-ID: <53553E39.9050908@redhat.com>

Speaking for WildFly...

On 4/21/14, 8:47 AM, Rob Stryker wrote:
> Can anyone tell me the following:
>      1) What server versions will work with Java 8

8.0.0 and later.

It's possible something earlier might work in some scenarios (I really 
have no idea), but 8.0 is the first one where we tested it.

>      2) What server versions will **require** Java 8 to work properly?
>

There's no plan at this point to have a release require Java 8. I'm sure 
at some point we will, maybe WF 10. It's theoretically possible for WF 9 
but IMO very improbably and I'm sure there'd be some discussion on this 
list first.

> Feel free to answer with all varients of our products... so anything
> from AS 4 through wf8.x, eap*, soa*, etc etc.
>
> Thanks in advance.
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From brian.stansberry at redhat.com  Mon Apr 21 12:53:05 2014
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 21 Apr 2014 11:53:05 -0500
Subject: [wildfly-dev] Should deployed EAR WAR files include wildfly
 module provided JAR's?
In-Reply-To: <535442A3.4090106@gmail.com>
References: <535442A3.4090106@gmail.com>
Message-ID: <53554CF1.4000807@redhat.com>

On 4/20/14, 4:56 PM, hanasaki at gmail.com wrote:
> wildfly modules contain some open source jar files.
>
> 1. should WAR and EAR files include these or list them as maven scope
> provided and use the jboss deployment descriptor to have the app server
> include them in the classpath from the app server module?
> 2. Does the answer change for modules that are jboss.api=private vs
> those that are not private?
>

The answer definitely depends. If a module is marked as 
jboss.api=private that means if you depend on it you are on your own as 
far as checking for compatibility, etc if you upgrade your WildFly 
version. WF ships the module for its own internal use and we won't 
hesitate at all in a future release about making major upgrades in that 
module or removing it altogether if that best fits our needs.

> The below reference has some information however do not definitively
> state a best practice and why.
>
> reference:
> http://wildfly-development.1055759.n5.nabble.com/what-is-jboss-api-private-exactly-td5711072.html
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From tomaz.cerar at gmail.com  Mon Apr 21 13:58:23 2014
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Mon, 21 Apr 2014 19:58:23 +0200
Subject: [wildfly-dev] Java-8 Support for various appserver versions
In-Reply-To: <53553E39.9050908@redhat.com>
References: <53552185.60304@redhat.com>
	<53553E39.9050908@redhat.com>
Message-ID: <CAMquZP4c3RuM8JkejUQyHwZGPkX_0zg=g4YQVtoSy8YWS40diA@mail.gmail.com>

I think you could be somewhat fine also with WildFly 8 beta1 and up but
there are things that wont work properly, JSP compiling comes to mind.
Also EAP 6.2 somewhat works, also with limitations.
EAP 6.3 is/will be fine.

--
tomaz


On Mon, Apr 21, 2014 at 5:50 PM, Brian Stansberry <
brian.stansberry at redhat.com> wrote:

> Speaking for WildFly...
>
> On 4/21/14, 8:47 AM, Rob Stryker wrote:
> > Can anyone tell me the following:
> >      1) What server versions will work with Java 8
>
> 8.0.0 and later.
>
> It's possible something earlier might work in some scenarios (I really
> have no idea), but 8.0 is the first one where we tested it.
>
> >      2) What server versions will **require** Java 8 to work properly?
> >
>
> There's no plan at this point to have a release require Java 8. I'm sure
> at some point we will, maybe WF 10. It's theoretically possible for WF 9
> but IMO very improbably and I'm sure there'd be some discussion on this
> list first.
>
> > Feel free to answer with all varients of our products... so anything
> > from AS 4 through wf8.x, eap*, soa*, etc etc.
> >
> > Thanks in advance.
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
>
>
> --
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140421/6c8f5de3/attachment.html 

From Anil.Saldhana at redhat.com  Mon Apr 21 14:29:09 2014
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Mon, 21 Apr 2014 13:29:09 -0500
Subject: [wildfly-dev] my 2 cents on Security Manager discussion
In-Reply-To: <CAE=-AhDGUmJKJHuv0TnDEsnfGXXNy3aWvyARr1B=Kpx9ndZc8g@mail.gmail.com>
References: <5351AAE8.5010107@redhat.com>
	<5351AC23.1090903@gmail.com>	<7EC05876-28DA-44EA-8CF0-CFD5D85A37E7@redhat.com>
	<CAE=-AhDGUmJKJHuv0TnDEsnfGXXNy3aWvyARr1B=Kpx9ndZc8g@mail.gmail.com>
Message-ID: <53556375.3060808@redhat.com>

On 04/19/2014 12:43 PM, arjan tijms wrote:
> Hi,
>
> Just wondering, but what is the primary use case for a security 
> manager server side?
>
> While the model obviously makes sense for Applets and Webstart where 
> untrusted code is executed on the user's machine, I found it to be 
> extremely rare for a server to run untrusted code. In fact, I don't 
> think I've ever seen this situation.
I agree with what you are saying. Unfortunately there are a handful of 
users/developers/sys-admins who are required to run the JVM under the 
JSM. Might be corporate policy or compliance etc.
Luckily they are a minority. They always pinpoint if there are any 
particular permission failing under the JSM.

The JSM was really invented around the applet era and has really not 
seen any major adaptation/overhaul for the s/w industry growth.

>
> There's maybe a case to prevent privilege escalation in case of a 
> legitimate app being hacked, but in practice it doesn't look like a 
> security manager is really being used a lot for that, is it? Instead 
> the default thing to do there seems to be to run the AS under a user 
> with limited rights on the host OS and/or use things like SELinix or 
> Virtual Servers (e.g. XEN) to isolate the complete AS.
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
> On Sat, Apr 19, 2014 at 1:53 AM, Jason T. Greene <jgreene at redhat.com 
> <mailto:jgreene at redhat.com>> wrote:
>
>
>
>     Sent from my iPhone
>
>     > On Apr 18, 2014, at 5:50 PM, Stuart Douglas
>     <stuart.w.douglas at gmail.com <mailto:stuart.w.douglas at gmail.com>>
>     wrote:
>     >
>     >
>     > Enabling the security manager by default is a terrible idea.
>
>     +1000
>     ___________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140421/693bafc9/attachment.html 

From Anil.Saldhana at redhat.com  Mon Apr 21 14:35:48 2014
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Mon, 21 Apr 2014 13:35:48 -0500
Subject: [wildfly-dev] my 2 cents on Security Manager discussion
In-Reply-To: <5351AAE8.5010107@redhat.com>
References: <5351AAE8.5010107@redhat.com>
Message-ID: <53556504.1000409@redhat.com>

On 04/18/2014 05:44 PM, Bill Burke wrote:
> Late to the discussion, but this came up in conversations at DevNation.
>
> Are you sure you guys want to fully enable the Java security manager
> going forward?  Jboss has been around for, what 14 years now?  How many
> users/customers actually desire the Java Security Manager to be on by
> default?  Could it be a possibility that the majority of our
> customers/users might freak out if they found that all of a sudden the
> Java Security Manager is on when it has been off the last 14 years?
>
> I don't know.  Just seems to me that there is a lot of other cool ideas
> that you guys have been discussing that might be more interesting to
> wildfly's user base.
>
DML, Stefan Guilhen and I had a brainstorming session months ago before
the development of the security manager subsystem in WF8.

This session was mainly to address the permissions.xml requirement in EE7
https://blogs.oracle.com/SecuritEE/entry/java_ee_7_permission_declarations

During this session, we discussed the two options among many other 
discussion items:
a) Enable Java Security Manager as default in WF8.
b) Create a custom JSM Policy implementation to replace the one in the JVM.

Both these options were immediately dropped as neither useful nor 
necessary for
the WildFly community.

The Java Security Manager redesign happened around JDK 1.2 (applet era) 
and has had no
major overhaul in the implementation. One change that may be useful is 
the introduction of
a Policy SPI in JDK6:
http://docs.oracle.com/javase/6/docs/api/java/security/PolicySpi.html

JDK8 has limited doPrivileged: 
http://openjdk.java.net/projects/jdk8/features#140

I agree with Stuart and Jason that enabling JSM by default is a terrible 
idea.


From Robert.Panzer at wincor-nixdorf.com  Tue Apr 22 02:54:12 2014
From: Robert.Panzer at wincor-nixdorf.com (Panzer, Robert)
Date: Tue, 22 Apr 2014 08:54:12 +0200
Subject: [wildfly-dev] my 2 cents on Security Manager discussion
In-Reply-To: <53556375.3060808@redhat.com>
References: <5351AAE8.5010107@redhat.com>	<5351AC23.1090903@gmail.com> 
	<7EC05876-28DA-44EA-8CF0-CFD5D85A37E7@redhat.com> 
	<CAE=-AhDGUmJKJHuv0TnDEsnfGXXNy3aWvyARr1B=Kpx9ndZc8g@mail.gmail.com> 
	<53556375.3060808@redhat.com>
Message-ID: <907AE6DD25443A47982983074FC87C0FDD57B29659@DEEXVS21.wincor-nixdorf.com>

Hi,

Just want to throw in my other cent:

The Java Security Manager makes a lot of sense also on the server side when you are building component based software and want for instance to ensure that some components are eligible to access some data and others are not.

If you can ensure that most components are not able to access certain sensitive data then you can skip them in security audits and that's a great win!

Javas visibility is not capable of handling this.

Kind regards,
Robert

From: wildfly-dev-bounces at lists.jboss.org [mailto:wildfly-dev-bounces at lists.jboss.org] On Behalf Of Anil Saldhana
Sent: Monday, April 21, 2014 8:29 PM
To: wildfly-dev at lists.jboss.org
Subject: Re: [wildfly-dev] my 2 cents on Security Manager discussion

On 04/19/2014 12:43 PM, arjan tijms wrote:
Hi,

Just wondering, but what is the primary use case for a security manager server side?

While the model obviously makes sense for Applets and Webstart where untrusted code is executed on the user's machine, I found it to be extremely rare for a server to run untrusted code. In fact, I don't think I've ever seen this situation.
I agree with what you are saying. Unfortunately there are a handful of users/developers/sys-admins who are required to run the JVM under the JSM. Might be corporate policy or compliance etc.
Luckily they are a minority. They always pinpoint if there are any particular permission failing under the JSM.

The JSM was really invented around the applet era and has really not seen any major adaptation/overhaul for the s/w industry growth.



There's maybe a case to prevent privilege escalation in case of a legitimate app being hacked, but in practice it doesn't look like a security manager is really being used a lot for that, is it? Instead the default thing to do there seems to be to run the AS under a user with limited rights on the host OS and/or use things like SELinix or Virtual Servers (e.g. XEN) to isolate the complete AS.

Kind regards,
Arjan Tijms




On Sat, Apr 19, 2014 at 1:53 AM, Jason T. Greene <jgreene at redhat.com<mailto:jgreene at redhat.com>> wrote:


Sent from my iPhone

> On Apr 18, 2014, at 5:50 PM, Stuart Douglas <stuart.w.douglas at gmail.com<mailto:stuart.w.douglas at gmail.com>> wrote:
>
>
> Enabling the security manager by default is a terrible idea.
+1000
___________


WINCOR NIXDORF International GmbH
Sitz der Gesellschaft: Paderborn
Registergericht Paderborn HRB 3507
Gesch?ftsf?hrer: Eckard Heidloff (Vorsitzender), Dr. J?rgen Wunram (stellv. Vors.), Jens Bohlen, Olaf Heyden
Vorsitzender des Aufsichtsrats: Dr. Alexander Dibelius
Steuernummer: 339/5884/0020 - Ust-ID Nr.: DE812927716 - WEEE-Reg.-Nr. DE44477193

Diese E-Mail enth?lt vertrauliche Informationen.
Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrt?mlich erhalten haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet.

This e-mail may contain confidential information.
If you are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail.
Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140422/821d0caf/attachment-0001.html 

From arjan.tijms at gmail.com  Tue Apr 22 06:17:54 2014
From: arjan.tijms at gmail.com (arjan tijms)
Date: Tue, 22 Apr 2014 12:17:54 +0200
Subject: [wildfly-dev] my 2 cents on Security Manager discussion
In-Reply-To: <907AE6DD25443A47982983074FC87C0FDD57B29659@DEEXVS21.wincor-nixdorf.com>
References: <5351AAE8.5010107@redhat.com> <5351AC23.1090903@gmail.com>
	<7EC05876-28DA-44EA-8CF0-CFD5D85A37E7@redhat.com>
	<CAE=-AhDGUmJKJHuv0TnDEsnfGXXNy3aWvyARr1B=Kpx9ndZc8g@mail.gmail.com>
	<53556375.3060808@redhat.com>
	<907AE6DD25443A47982983074FC87C0FDD57B29659@DEEXVS21.wincor-nixdorf.com>
Message-ID: <CAE=-AhCCpyQFcXVm+nDwr8cueX4i+JV1Q9N7sp3dCmrCTch1DQ@mail.gmail.com>

Hi,


On Tue, Apr 22, 2014 at 8:54 AM, Panzer, Robert <
Robert.Panzer at wincor-nixdorf.com> wrote:

>
> The Java Security Manager makes a lot of sense also on the server side
> when you are building component based software and want for instance to
> ensure that some components are eligible to access some data and others are
> not.
>
>
>
> If you can ensure that most components are not able to access certain
> sensitive data then you can skip them in security audits and that?s a great
> win!
>

It does sound like a somewhat viable use case indeed, although in practice
it looks like few people walk that road (or maybe it are just my limited
amount of observations). What I did see (occasionally) happening in this
case is that people ran that single component that's capable of accessing
sensitive data in a separate JVM/virtual machine and then communicate with
it via a well-defined authenticated/secured interface.

That particular component is then protected by the OS' process model and
memory protection and the rest of the code doesn't suffer from the
performance degradation and coding complexities of the JSM.

If there's a LOT of communication with that particular component then I
guess running them both in the same JVM with the JSM enabled might
theoretically be better for performance, but I personally just haven't seen
this in practice.

Kind regards,
Arjan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140422/c26546f5/attachment.html 

From stuart.w.douglas at gmail.com  Tue Apr 22 07:09:02 2014
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Tue, 22 Apr 2014 21:09:02 +1000
Subject: [wildfly-dev] my 2 cents on Security Manager discussion
In-Reply-To: <907AE6DD25443A47982983074FC87C0FDD57B29659@DEEXVS21.wincor-nixdorf.com>
References: <5351AAE8.5010107@redhat.com> <5351AC23.1090903@gmail.com>
	<7EC05876-28DA-44EA-8CF0-CFD5D85A37E7@redhat.com>
	<CAE=-AhDGUmJKJHuv0TnDEsnfGXXNy3aWvyARr1B=Kpx9ndZc8g@mail.gmail.com>
	<53556375.3060808@redhat.com>
	<907AE6DD25443A47982983074FC87C0FDD57B29659@DEEXVS21.wincor-nixdorf.com>
Message-ID: <F2E9C244-93D5-406D-A124-62FC9A740867@gmail.com>



Sent from my iPhone

> On 22 Apr 2014, at 16:54, "Panzer, Robert" <Robert.Panzer at wincor-nixdorf.com> wrote:
> 
> Hi,
>  
> Just want to throw in my other cent:
>  
> The Java Security Manager makes a lot of sense also on the server side when you are building component based software and want for instance to ensure that some components are eligible to access some data and others are not.
>  
> If you can ensure that most components are not able to access certain sensitive data then you can skip them in security audits and that?s a great win!
>  
> Javas visibility is not capable of handling this.

We are trying to make running under a security manager as easy as possible, just not by default.

Stuart

>  
> Kind regards,
> Robert
>  
> From: wildfly-dev-bounces at lists.jboss.org [mailto:wildfly-dev-bounces at lists.jboss.org] On Behalf Of Anil Saldhana
> Sent: Monday, April 21, 2014 8:29 PM
> To: wildfly-dev at lists.jboss.org
> Subject: Re: [wildfly-dev] my 2 cents on Security Manager discussion
>  
> On 04/19/2014 12:43 PM, arjan tijms wrote:
> Hi,
>  
> Just wondering, but what is the primary use case for a security manager server side?
>  
> While the model obviously makes sense for Applets and Webstart where untrusted code is executed on the user's machine, I found it to be extremely rare for a server to run untrusted code. In fact, I don't think I've ever seen this situation.
> I agree with what you are saying. Unfortunately there are a handful of users/developers/sys-admins who are required to run the JVM under the JSM. Might be corporate policy or compliance etc.
> Luckily they are a minority. They always pinpoint if there are any particular permission failing under the JSM.
> 
> The JSM was really invented around the applet era and has really not seen any major adaptation/overhaul for the s/w industry growth.
> 
> 
>  
> There's maybe a case to prevent privilege escalation in case of a legitimate app being hacked, but in practice it doesn't look like a security manager is really being used a lot for that, is it? Instead the default thing to do there seems to be to run the AS under a user with limited rights on the host OS and/or use things like SELinix or Virtual Servers (e.g. XEN) to isolate the complete AS.
>  
> Kind regards,
> Arjan Tijms
>  
>  
>  
>  
> 
> On Sat, Apr 19, 2014 at 1:53 AM, Jason T. Greene <jgreene at redhat.com> wrote:
> 
> 
> Sent from my iPhone
> 
> > On Apr 18, 2014, at 5:50 PM, Stuart Douglas <stuart.w.douglas at gmail.com> wrote:
> >
> >
> > Enabling the security manager by default is a terrible idea.
> 
> +1000
> ___________
>  
> WINCOR NIXDORF International GmbH
> Sitz der Gesellschaft: Paderborn
> Registergericht Paderborn HRB 3507
> Gesch?ftsf?hrer: Eckard Heidloff (Vorsitzender), Dr. J?rgen Wunram (stellv. Vors.), Jens Bohlen, Olaf Heyden
> Vorsitzender des Aufsichtsrats: Dr. Alexander Dibelius
> Steuernummer: 339/5884/0020 - Ust-ID Nr.: DE812927716 - WEEE-Reg.-Nr. DE44477193
> 
> Diese E-Mail enth?lt vertrauliche Informationen.
> Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrt?mlich erhalten haben,
> informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail.
> Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet.
> 
> This e-mail may contain confidential information.
> If you are not the intended recipient (or have received this e-mail in error)
> please notify the sender immediately and destroy this e-mail.
> Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140422/d74464ef/attachment.html 

From fjuma at redhat.com  Tue Apr 22 15:17:02 2014
From: fjuma at redhat.com (Farah Juma)
Date: Tue, 22 Apr 2014 15:17:02 -0400 (EDT)
Subject: [wildfly-dev] WildFly 8.1.0.CR1 on OpenShift
In-Reply-To: <844163581.11186191.1397764995828.JavaMail.zimbra@redhat.com>
Message-ID: <1321791831.14575528.1398194222591.JavaMail.zimbra@redhat.com>

Since WildFly 8.1.0.CR1 was released last week, the OpenShift WildFly cartridge has been updated as well.

See https://community.jboss.org/people/fjuma/blog/2014/04/22/wildfly-810cr1-on-openshift for more details on how to get started. Please try it out and provide feedback.


From tomaz.cerar at gmail.com  Tue Apr 22 15:22:45 2014
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Tue, 22 Apr 2014 21:22:45 +0200
Subject: [wildfly-dev] WildFly 8.1.0.CR1 on OpenShift
In-Reply-To: <1321791831.14575528.1398194222591.JavaMail.zimbra@redhat.com>
References: <844163581.11186191.1397764995828.JavaMail.zimbra@redhat.com>
	<1321791831.14575528.1398194222591.JavaMail.zimbra@redhat.com>
Message-ID: <CAMquZP4pd_OFF96=F5bX8MefZHkEN4SRV7MSJpiA-LLWU26BgA@mail.gmail.com>

Great news!

Btw, did you manage to add support for JDK8 yet?
Not sure how far is openshift in this area but it would be great if we
would have JDK8 with WildFly on OpenShift.

--
tomaz


On Tue, Apr 22, 2014 at 9:17 PM, Farah Juma <fjuma at redhat.com> wrote:

> Since WildFly 8.1.0.CR1 was released last week, the OpenShift WildFly
> cartridge has been updated as well.
>
> See
> https://community.jboss.org/people/fjuma/blog/2014/04/22/wildfly-810cr1-on-openshiftfor more details on how to get started. Please try it out and provide
> feedback.
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140422/389cd8f0/attachment.html 

From fjuma at redhat.com  Tue Apr 22 15:35:40 2014
From: fjuma at redhat.com (Farah Juma)
Date: Tue, 22 Apr 2014 15:35:40 -0400 (EDT)
Subject: [wildfly-dev] WildFly 8.1.0.CR1 on OpenShift
In-Reply-To: <CAMquZP4pd_OFF96=F5bX8MefZHkEN4SRV7MSJpiA-LLWU26BgA@mail.gmail.com>
References: <844163581.11186191.1397764995828.JavaMail.zimbra@redhat.com>
	<1321791831.14575528.1398194222591.JavaMail.zimbra@redhat.com>
	<CAMquZP4pd_OFF96=F5bX8MefZHkEN4SRV7MSJpiA-LLWU26BgA@mail.gmail.com>
Message-ID: <1976792542.14584150.1398195340183.JavaMail.zimbra@redhat.com>

OpenShift hasn't added support for JDK8 yet but it should be possible for us to add it into the WildFly cartridge. I'll look into this.

Farah

----- Original Message -----
> From: "Toma? Cerar" <tomaz.cerar at gmail.com>
> To: "Farah Juma" <fjuma at redhat.com>
> Cc: "WildFly Dev" <wildfly-dev at lists.jboss.org>
> Sent: Tuesday, April 22, 2014 3:22:45 PM
> Subject: Re: [wildfly-dev] WildFly 8.1.0.CR1 on OpenShift
> 
> Great news!
> 
> Btw, did you manage to add support for JDK8 yet?
> Not sure how far is openshift in this area but it would be great if we
> would have JDK8 with WildFly on OpenShift.
> 
> --
> tomaz
> 
> 
> On Tue, Apr 22, 2014 at 9:17 PM, Farah Juma <fjuma at redhat.com> wrote:
> 
> > Since WildFly 8.1.0.CR1 was released last week, the OpenShift WildFly
> > cartridge has been updated as well.
> >
> > See
> > https://community.jboss.org/people/fjuma/blog/2014/04/22/wildfly-810cr1-on-openshiftfor
> > more details on how to get started. Please try it out and provide
> > feedback.
> >
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> 


From jcacek at redhat.com  Wed Apr 23 08:40:57 2014
From: jcacek at redhat.com (Josef Cacek)
Date: Wed, 23 Apr 2014 08:40:57 -0400 (EDT)
Subject: [wildfly-dev] my 2 cents on Security Manager discussion
In-Reply-To: <CAE=-AhDGUmJKJHuv0TnDEsnfGXXNy3aWvyARr1B=Kpx9ndZc8g@mail.gmail.com>
References: <5351AAE8.5010107@redhat.com> <5351AC23.1090903@gmail.com>
	<7EC05876-28DA-44EA-8CF0-CFD5D85A37E7@redhat.com>
	<CAE=-AhDGUmJKJHuv0TnDEsnfGXXNy3aWvyARr1B=Kpx9ndZc8g@mail.gmail.com>
Message-ID: <1966656146.15206399.1398256857398.JavaMail.zimbra@redhat.com>

Hi Arjan,

let me give you few examples. Do you really want to allow users/deployed-apps/3rd-party-libs

 * call System.exit()?
 * change behavior of the whole JVM by changing some system properties (keystores and truststores for instance)?
 * use reflection to read/change private data (caches, etc)?
 * access the filesystem (e.g. rewrite the WildFly configuration files)?
 * ...

If the answer is always yes, then you don't need the JSM I think.

But if you care what can do the parts of code which you don't have under full control, then you should really use the Java Security Manager.

Best regards,

-- Josef

----- Original Message -----
> From: "arjan tijms" <arjan.tijms at gmail.com>
> To: "Jason T. Greene" <jgreene at redhat.com>
> Cc: wildfly-dev at lists.jboss.org
> Sent: Saturday, April 19, 2014 7:43:24 PM
> Subject: Re: [wildfly-dev] my 2 cents on Security Manager discussion
> 
> Hi,
> 
> Just wondering, but what is the primary use case for a security manager
> server side?
> 
> While the model obviously makes sense for Applets and Webstart where
> untrusted code is executed on the user's machine, I found it to be extremely
> rare for a server to run untrusted code. In fact, I don't think I've ever
> seen this situation.
> 
> There's maybe a case to prevent privilege escalation in case of a legitimate
> app being hacked, but in practice it doesn't look like a security manager is
> really being used a lot for that, is it? Instead the default thing to do
> there seems to be to run the AS under a user with limited rights on the host
> OS and/or use things like SELinix or Virtual Servers (e.g. XEN) to isolate
> the complete AS.
> 
> Kind regards,
> Arjan Tijms

From david.lloyd at redhat.com  Wed Apr 23 08:57:29 2014
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Wed, 23 Apr 2014 07:57:29 -0500
Subject: [wildfly-dev] my 2 cents on Security Manager discussion
In-Reply-To: <1966656146.15206399.1398256857398.JavaMail.zimbra@redhat.com>
References: <5351AAE8.5010107@redhat.com>
	<5351AC23.1090903@gmail.com>	<7EC05876-28DA-44EA-8CF0-CFD5D85A37E7@redhat.com>	<CAE=-AhDGUmJKJHuv0TnDEsnfGXXNy3aWvyARr1B=Kpx9ndZc8g@mail.gmail.com>
	<1966656146.15206399.1398256857398.JavaMail.zimbra@redhat.com>
Message-ID: <5357B8B9.3000201@redhat.com>

At the same time, the sheer number of CVEs relating to sandbox 
vulnerabilities and privilege escalations should give anyone pause, who 
thinks to rely on an SM as a way to "safely" run untrusted code.

And an SM doesn't protect you from everything; untrusted code could, for 
example, still lock threads into infinite, uninterruptible loops.

Finally, as I've said numerous times before, adding a security manager 
has a performance cost - sometimes a *major* performance cost.  You have 
to balance all of these concerns against what your real requirements are 
before you take the plunge.

On 04/23/2014 07:40 AM, Josef Cacek wrote:
> Hi Arjan,
>
> let me give you few examples. Do you really want to allow users/deployed-apps/3rd-party-libs
>
>   * call System.exit()?
>   * change behavior of the whole JVM by changing some system properties (keystores and truststores for instance)?
>   * use reflection to read/change private data (caches, etc)?
>   * access the filesystem (e.g. rewrite the WildFly configuration files)?
>   * ...
>
> If the answer is always yes, then you don't need the JSM I think.
>
> But if you care what can do the parts of code which you don't have under full control, then you should really use the Java Security Manager.
>
> Best regards,
>
> -- Josef
>
> ----- Original Message -----
>> From: "arjan tijms" <arjan.tijms at gmail.com>
>> To: "Jason T. Greene" <jgreene at redhat.com>
>> Cc: wildfly-dev at lists.jboss.org
>> Sent: Saturday, April 19, 2014 7:43:24 PM
>> Subject: Re: [wildfly-dev] my 2 cents on Security Manager discussion
>>
>> Hi,
>>
>> Just wondering, but what is the primary use case for a security manager
>> server side?
>>
>> While the model obviously makes sense for Applets and Webstart where
>> untrusted code is executed on the user's machine, I found it to be extremely
>> rare for a server to run untrusted code. In fact, I don't think I've ever
>> seen this situation.
>>
>> There's maybe a case to prevent privilege escalation in case of a legitimate
>> app being hacked, but in practice it doesn't look like a security manager is
>> really being used a lot for that, is it? Instead the default thing to do
>> there seems to be to run the AS under a user with limited rights on the host
>> OS and/or use things like SELinix or Virtual Servers (e.g. XEN) to isolate
>> the complete AS.
>>
>> Kind regards,
>> Arjan Tijms
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
- DML

From dador92 at gmail.com  Wed Apr 23 09:10:02 2014
From: dador92 at gmail.com (Jim McGuinness)
Date: Wed, 23 Apr 2014 08:10:02 -0500
Subject: [wildfly-dev] WildFly 8.1.0.CR1 on OpenShift
In-Reply-To: <CALbcAPV-19V6MpgbTn6yxVSnrn=TrBWOKV8DAnTYA=+ZDMb2Qw@mail.gmail.com>
References: <844163581.11186191.1397764995828.JavaMail.zimbra@redhat.com>
	<1321791831.14575528.1398194222591.JavaMail.zimbra@redhat.com>
	<CAMquZP4pd_OFF96=F5bX8MefZHkEN4SRV7MSJpiA-LLWU26BgA@mail.gmail.com>
	<1976792542.14584150.1398195340183.JavaMail.zimbra@redhat.com>
	<CALbcAPW7ZJRsp3ovpZfenj_WUBfbSwmerSGo0qW3_p5TKCYNKQ@mail.gmail.com>
	<1165286158.14704733.1398207657860.JavaMail.zimbra@redhat.com>
	<CALbcAPV-19V6MpgbTn6yxVSnrn=TrBWOKV8DAnTYA=+ZDMb2Qw@mail.gmail.com>
Message-ID: <CALbcAPUwm5UfN1BP4uMoDsscithKpdhiD3_y3y8svY-h-2urPg@mail.gmail.com>

Farah,

I've been looking at this some more, and the marker for Java just toggles
back and forth between Java 6 and Java 7. If the Java 7 marker is not
present, then a cartridge just defaults back to Java 6.

But you still have to have the version of Java installed on the gear in
order to toggle back and forth.

Here are the contents of the /usr/lib/jvm directory on the gear where
OpenShift online installed my Wildfly 8.1
cartridge ...

lrwxrwxrwx.  1 root root   26 Apr 22 13:19 java ->
/etc/alternatives/java_sdk
drwxr-xr-x.  3 root root 4.0K Feb 18  2013 java-1.5.0-gcj-1.5.0.0
lrwxrwxrwx.  1 root root   32 Apr 22 13:19 java-1.6.0 ->
/etc/alternatives/java_sdk_1.6.0
lrwxrwxrwx.  1 root root   26 Apr 22 13:19 java-1.6.0-openjdk ->
java-1.6.0-openjdk-1.6.0.0
drwxr-xr-x.  7 root root 4.0K Apr 11 06:57 java-1.6.0-openjdk-1.6.0.0
lrwxrwxrwx.  1 root root   32 Apr 22 13:18 java-1.7.0 ->
/etc/alternatives/java_sdk_1.7.0
lrwxrwxrwx.  1 root root   27 Apr 22 13:18 java-1.7.0-openjdk ->
java-1.7.0-openjdk-1.7.0.55
drwxr-xr-x.  3 root root 4.0K Feb  3 17:06 java-1.7.0-openjdk-1.7.0.45
drwxr-xr-x.  3 root root 4.0K Apr 22 13:19 java-1.7.0-openjdk-1.7.0.51
drwxr-xr-x.  7 root root 4.0K Apr 22 13:18 java-1.7.0-openjdk-1.7.0.55
drwxr-xr-x.  3 root root 4.0K May  1  2013 java-1.7.0-openjdk-1.7.0.9
lrwxrwxrwx.  1 root root   34 Apr 22 13:19 java-openjdk ->
/etc/alternatives/java_sdk_openjdk
lrwxrwxrwx.  1 root root   21 Apr 22 13:19 jre -> /etc/alternatives/jre
lrwxrwxrwx.  1 root root   27 Feb 18  2013 jre-1.5.0 ->
/etc/alternatives/jre_1.5.0
lrwxrwxrwx.  1 root root   26 Feb 18  2013 jre-1.5.0-gcj ->
java-1.5.0-gcj-1.5.0.0/jre
lrwxrwxrwx.  1 root root   27 Apr 22 13:19 jre-1.6.0 ->
/etc/alternatives/jre_1.6.0
lrwxrwxrwx.  1 root root   30 Apr 22 13:19 jre-1.6.0-openjdk ->
java-1.6.0-openjdk-1.6.0.0/jre
lrwxrwxrwx.  1 root root   27 Apr 22 13:18 jre-1.7.0 ->
/etc/alternatives/jre_1.7.0
lrwxrwxrwx.  1 root root   31 Apr 22 13:18 jre-1.7.0-openjdk ->
java-1.7.0-openjdk-1.7.0.55/jre
lrwxrwxrwx.  1 root root   25 Feb 18  2013 jre-gcj ->
/etc/alternatives/jre_gcj
lrwxrwxrwx.  1 root root   29 Apr 22 13:19 jre-openjdk ->
/etc/alternatives/jre_openjdk

I truly think the answer is that the gear needs to add Java 8 SE in order
for the Wildfly cartridge to be able to use it. And the Wildfly cartridge
will then need to be updated to respond to a Java 8 marker..



On Tue, Apr 22, 2014 at 6:57 PM, Jim McGuinness <dador92 at gmail.com> wrote:

> Doesn't the marker just indicate the JDK version(s) used/usable by the app
> (in this case wildfly)? The gear still has to have a JDK 8 installed
> doesn't it?
>
>
> On Tue, Apr 22, 2014 at 6:00 PM, Farah Juma <fjuma at redhat.com> wrote:
>
>>
>> > From: "Jim McGuinness" <dador92 at gmail.com>
>> > To: "Farah Juma" <fjuma at redhat.com>
>> > Sent: Tuesday, April 22, 2014 5:57:07 PM
>> > Subject: Re: [wildfly-dev] WildFly 8.1.0.CR1 on OpenShift
>> >
>> > Would it be better to create a JDK 8 cartridge which could be deployed
>> in
>> > the same gear as the Wildfly 8.1 cartridge? Ideally you'll want to use
>> the
>> > JDK 8 for more than just Wildfly.
>>
>> Support for different JDK versions is added using marker files (e.g.,
>> this post describes how JDK7 support was added:
>> https://www.openshift.com/blogs/new-openshift-release-aug-8-2012-java-7-cakephp-origin-updates-and-more
>> ).
>>
>> > Is the gear's lack of a JDK 8 caused by the requirements of SELinux?
>>
>> It just hasn't been added by OpenShift yet.
>>
>> >
>> > On Tue, Apr 22, 2014 at 2:35 PM, Farah Juma <fjuma at redhat.com> wrote:
>> >
>> > > OpenShift hasn't added support for JDK8 yet but it should be possible
>> for
>> > > us to add it into the WildFly cartridge. I'll look into this.
>> > >
>> > > Farah
>> > >
>> > > ----- Original Message -----
>> > > > From: "Toma? Cerar" <tomaz.cerar at gmail.com>
>> > > > To: "Farah Juma" <fjuma at redhat.com>
>> > > > Cc: "WildFly Dev" <wildfly-dev at lists.jboss.org>
>> > > > Sent: Tuesday, April 22, 2014 3:22:45 PM
>> > > > Subject: Re: [wildfly-dev] WildFly 8.1.0.CR1 on OpenShift
>> > > >
>> > > > Great news!
>> > > >
>> > > > Btw, did you manage to add support for JDK8 yet?
>> > > > Not sure how far is openshift in this area but it would be great if
>> we
>> > > > would have JDK8 with WildFly on OpenShift.
>> > > >
>> > > > --
>> > > > tomaz
>> > > >
>> > > >
>> > > > On Tue, Apr 22, 2014 at 9:17 PM, Farah Juma <fjuma at redhat.com>
>> wrote:
>> > > >
>> > > > > Since WildFly 8.1.0.CR1 was released last week, the OpenShift
>> WildFly
>> > > > > cartridge has been updated as well.
>> > > > >
>> > > > > See
>> > > > >
>> > >
>> https://community.jboss.org/people/fjuma/blog/2014/04/22/wildfly-810cr1-on-openshiftfor
>> > > > > more details on how to get started. Please try it out and provide
>> > > > > feedback.
>> > > > >
>> > > > > _______________________________________________
>> > > > > wildfly-dev mailing list
>> > > > > wildfly-dev at lists.jboss.org
>> > > > > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> > > > >
>> > > >
>> > >
>> > > _______________________________________________
>> > > wildfly-dev mailing list
>> > > wildfly-dev at lists.jboss.org
>> > > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> > >
>> >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140423/b6cccefd/attachment.html 

From bburke at redhat.com  Wed Apr 23 09:38:40 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 23 Apr 2014 09:38:40 -0400
Subject: [wildfly-dev] my 2 cents on Security Manager discussion
In-Reply-To: <1966656146.15206399.1398256857398.JavaMail.zimbra@redhat.com>
References: <5351AAE8.5010107@redhat.com>
	<5351AC23.1090903@gmail.com>	<7EC05876-28DA-44EA-8CF0-CFD5D85A37E7@redhat.com>	<CAE=-AhDGUmJKJHuv0TnDEsnfGXXNy3aWvyARr1B=Kpx9ndZc8g@mail.gmail.com>
	<1966656146.15206399.1398256857398.JavaMail.zimbra@redhat.com>
Message-ID: <5357C260.9080005@redhat.com>

As much as we like to think the app server is an operating system, it 
isn't.  The app server isn't a place where untrusted apps run.

On 4/23/2014 8:40 AM, Josef Cacek wrote:
> Hi Arjan,
>
> let me give you few examples. Do you really want to allow users/deployed-apps/3rd-party-libs
>
>   * call System.exit()?
>   * change behavior of the whole JVM by changing some system properties (keystores and truststores for instance)?
>   * use reflection to read/change private data (caches, etc)?
>   * access the filesystem (e.g. rewrite the WildFly configuration files)?
>   * ...
>
> If the answer is always yes, then you don't need the JSM I think.
>
> But if you care what can do the parts of code which you don't have under full control, then you should really use the Java Security Manager.
>
> Best regards,
>
> -- Josef
>
> ----- Original Message -----
>> From: "arjan tijms" <arjan.tijms at gmail.com>
>> To: "Jason T. Greene" <jgreene at redhat.com>
>> Cc: wildfly-dev at lists.jboss.org
>> Sent: Saturday, April 19, 2014 7:43:24 PM
>> Subject: Re: [wildfly-dev] my 2 cents on Security Manager discussion
>>
>> Hi,
>>
>> Just wondering, but what is the primary use case for a security manager
>> server side?
>>
>> While the model obviously makes sense for Applets and Webstart where
>> untrusted code is executed on the user's machine, I found it to be extremely
>> rare for a server to run untrusted code. In fact, I don't think I've ever
>> seen this situation.
>>
>> There's maybe a case to prevent privilege escalation in case of a legitimate
>> app being hacked, but in practice it doesn't look like a security manager is
>> really being used a lot for that, is it? Instead the default thing to do
>> there seems to be to run the AS under a user with limited rights on the host
>> OS and/or use things like SELinix or Virtual Servers (e.g. XEN) to isolate
>> the complete AS.
>>
>> Kind regards,
>> Arjan Tijms
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From fjuma at redhat.com  Wed Apr 23 09:46:37 2014
From: fjuma at redhat.com (Farah Juma)
Date: Wed, 23 Apr 2014 09:46:37 -0400 (EDT)
Subject: [wildfly-dev] WildFly 8.1.0.CR1 on OpenShift
In-Reply-To: <CALbcAPUwm5UfN1BP4uMoDsscithKpdhiD3_y3y8svY-h-2urPg@mail.gmail.com>
References: <844163581.11186191.1397764995828.JavaMail.zimbra@redhat.com>
	<1321791831.14575528.1398194222591.JavaMail.zimbra@redhat.com>
	<CAMquZP4pd_OFF96=F5bX8MefZHkEN4SRV7MSJpiA-LLWU26BgA@mail.gmail.com>
	<1976792542.14584150.1398195340183.JavaMail.zimbra@redhat.com>
	<CALbcAPW7ZJRsp3ovpZfenj_WUBfbSwmerSGo0qW3_p5TKCYNKQ@mail.gmail.com>
	<1165286158.14704733.1398207657860.JavaMail.zimbra@redhat.com>
	<CALbcAPV-19V6MpgbTn6yxVSnrn=TrBWOKV8DAnTYA=+ZDMb2Qw@mail.gmail.com>
	<CALbcAPUwm5UfN1BP4uMoDsscithKpdhiD3_y3y8svY-h-2urPg@mail.gmail.com>
Message-ID: <1655439322.15273081.1398260797795.JavaMail.zimbra@redhat.com>


> From: "Jim McGuinness" <dador92 at gmail.com>
> To: "Farah Juma" <fjuma at redhat.com>, wildfly-dev at lists.jboss.org
> Sent: Wednesday, April 23, 2014 9:10:02 AM
> Subject: Re: [wildfly-dev] WildFly 8.1.0.CR1 on OpenShift
> 
> Farah,
> 
> I've been looking at this some more, and the marker for Java just toggles
> back and forth between Java 6 and Java 7. If the Java 7 marker is not
> present, then a cartridge just defaults back to Java 6.
> 
> But you still have to have the version of Java installed on the gear in
> order to toggle back and forth.
> 
> Here are the contents of the /usr/lib/jvm directory on the gear where
> OpenShift online installed my Wildfly 8.1
> cartridge ...
> 
> lrwxrwxrwx.  1 root root   26 Apr 22 13:19 java ->
> /etc/alternatives/java_sdk
> drwxr-xr-x.  3 root root 4.0K Feb 18  2013 java-1.5.0-gcj-1.5.0.0
> lrwxrwxrwx.  1 root root   32 Apr 22 13:19 java-1.6.0 ->
> /etc/alternatives/java_sdk_1.6.0
> lrwxrwxrwx.  1 root root   26 Apr 22 13:19 java-1.6.0-openjdk ->
> java-1.6.0-openjdk-1.6.0.0
> drwxr-xr-x.  7 root root 4.0K Apr 11 06:57 java-1.6.0-openjdk-1.6.0.0
> lrwxrwxrwx.  1 root root   32 Apr 22 13:18 java-1.7.0 ->
> /etc/alternatives/java_sdk_1.7.0
> lrwxrwxrwx.  1 root root   27 Apr 22 13:18 java-1.7.0-openjdk ->
> java-1.7.0-openjdk-1.7.0.55
> drwxr-xr-x.  3 root root 4.0K Feb  3 17:06 java-1.7.0-openjdk-1.7.0.45
> drwxr-xr-x.  3 root root 4.0K Apr 22 13:19 java-1.7.0-openjdk-1.7.0.51
> drwxr-xr-x.  7 root root 4.0K Apr 22 13:18 java-1.7.0-openjdk-1.7.0.55
> drwxr-xr-x.  3 root root 4.0K May  1  2013 java-1.7.0-openjdk-1.7.0.9
> lrwxrwxrwx.  1 root root   34 Apr 22 13:19 java-openjdk ->
> /etc/alternatives/java_sdk_openjdk
> lrwxrwxrwx.  1 root root   21 Apr 22 13:19 jre -> /etc/alternatives/jre
> lrwxrwxrwx.  1 root root   27 Feb 18  2013 jre-1.5.0 ->
> /etc/alternatives/jre_1.5.0
> lrwxrwxrwx.  1 root root   26 Feb 18  2013 jre-1.5.0-gcj ->
> java-1.5.0-gcj-1.5.0.0/jre
> lrwxrwxrwx.  1 root root   27 Apr 22 13:19 jre-1.6.0 ->
> /etc/alternatives/jre_1.6.0
> lrwxrwxrwx.  1 root root   30 Apr 22 13:19 jre-1.6.0-openjdk ->
> java-1.6.0-openjdk-1.6.0.0/jre
> lrwxrwxrwx.  1 root root   27 Apr 22 13:18 jre-1.7.0 ->
> /etc/alternatives/jre_1.7.0
> lrwxrwxrwx.  1 root root   31 Apr 22 13:18 jre-1.7.0-openjdk ->
> java-1.7.0-openjdk-1.7.0.55/jre
> lrwxrwxrwx.  1 root root   25 Feb 18  2013 jre-gcj ->
> /etc/alternatives/jre_gcj
> lrwxrwxrwx.  1 root root   29 Apr 22 13:19 jre-openjdk ->
> /etc/alternatives/jre_openjdk
> 
> I truly think the answer is that the gear needs to add Java 8 SE in order
> for the Wildfly cartridge to be able to use it. And the Wildfly cartridge
> will then need to be updated to respond to a Java 8 marker..

That's correct. Since OpenShift hasn't yet made JDK 8 available though, the idea is to update the WildFly cartridge so that it installs JDK 8 on the gear.

Farah

> 
> 
> On Tue, Apr 22, 2014 at 6:57 PM, Jim McGuinness <dador92 at gmail.com> wrote:
> 
> > Doesn't the marker just indicate the JDK version(s) used/usable by the app
> > (in this case wildfly)? The gear still has to have a JDK 8 installed
> > doesn't it?
> >
> >
> > On Tue, Apr 22, 2014 at 6:00 PM, Farah Juma <fjuma at redhat.com> wrote:
> >
> >>
> >> > From: "Jim McGuinness" <dador92 at gmail.com>
> >> > To: "Farah Juma" <fjuma at redhat.com>
> >> > Sent: Tuesday, April 22, 2014 5:57:07 PM
> >> > Subject: Re: [wildfly-dev] WildFly 8.1.0.CR1 on OpenShift
> >> >
> >> > Would it be better to create a JDK 8 cartridge which could be deployed
> >> in
> >> > the same gear as the Wildfly 8.1 cartridge? Ideally you'll want to use
> >> the
> >> > JDK 8 for more than just Wildfly.
> >>
> >> Support for different JDK versions is added using marker files (e.g.,
> >> this post describes how JDK7 support was added:
> >> https://www.openshift.com/blogs/new-openshift-release-aug-8-2012-java-7-cakephp-origin-updates-and-more
> >> ).
> >>
> >> > Is the gear's lack of a JDK 8 caused by the requirements of SELinux?
> >>
> >> It just hasn't been added by OpenShift yet.
> >>
> >> >
> >> > On Tue, Apr 22, 2014 at 2:35 PM, Farah Juma <fjuma at redhat.com> wrote:
> >> >
> >> > > OpenShift hasn't added support for JDK8 yet but it should be possible
> >> for
> >> > > us to add it into the WildFly cartridge. I'll look into this.
> >> > >
> >> > > Farah
> >> > >
> >> > > ----- Original Message -----
> >> > > > From: "Toma? Cerar" <tomaz.cerar at gmail.com>
> >> > > > To: "Farah Juma" <fjuma at redhat.com>
> >> > > > Cc: "WildFly Dev" <wildfly-dev at lists.jboss.org>
> >> > > > Sent: Tuesday, April 22, 2014 3:22:45 PM
> >> > > > Subject: Re: [wildfly-dev] WildFly 8.1.0.CR1 on OpenShift
> >> > > >
> >> > > > Great news!
> >> > > >
> >> > > > Btw, did you manage to add support for JDK8 yet?
> >> > > > Not sure how far is openshift in this area but it would be great if
> >> we
> >> > > > would have JDK8 with WildFly on OpenShift.
> >> > > >
> >> > > > --
> >> > > > tomaz
> >> > > >
> >> > > >
> >> > > > On Tue, Apr 22, 2014 at 9:17 PM, Farah Juma <fjuma at redhat.com>
> >> wrote:
> >> > > >
> >> > > > > Since WildFly 8.1.0.CR1 was released last week, the OpenShift
> >> WildFly
> >> > > > > cartridge has been updated as well.
> >> > > > >
> >> > > > > See
> >> > > > >
> >> > >
> >> https://community.jboss.org/people/fjuma/blog/2014/04/22/wildfly-810cr1-on-openshiftfor
> >> > > > > more details on how to get started. Please try it out and provide
> >> > > > > feedback.
> >> > > > >
> >> > > > > _______________________________________________
> >> > > > > wildfly-dev mailing list
> >> > > > > wildfly-dev at lists.jboss.org
> >> > > > > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >> > > > >
> >> > > >
> >> > >
> >> > > _______________________________________________
> >> > > wildfly-dev mailing list
> >> > > wildfly-dev at lists.jboss.org
> >> > > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >> > >
> >> >
> >>
> >
> >
> 


From dador92 at gmail.com  Wed Apr 23 09:50:01 2014
From: dador92 at gmail.com (Jim McGuinness)
Date: Wed, 23 Apr 2014 08:50:01 -0500
Subject: [wildfly-dev] WildFly 8.1.0.CR1 on OpenShift
In-Reply-To: <1655439322.15273081.1398260797795.JavaMail.zimbra@redhat.com>
References: <844163581.11186191.1397764995828.JavaMail.zimbra@redhat.com>
	<1321791831.14575528.1398194222591.JavaMail.zimbra@redhat.com>
	<CAMquZP4pd_OFF96=F5bX8MefZHkEN4SRV7MSJpiA-LLWU26BgA@mail.gmail.com>
	<1976792542.14584150.1398195340183.JavaMail.zimbra@redhat.com>
	<CALbcAPW7ZJRsp3ovpZfenj_WUBfbSwmerSGo0qW3_p5TKCYNKQ@mail.gmail.com>
	<1165286158.14704733.1398207657860.JavaMail.zimbra@redhat.com>
	<CALbcAPV-19V6MpgbTn6yxVSnrn=TrBWOKV8DAnTYA=+ZDMb2Qw@mail.gmail.com>
	<CALbcAPUwm5UfN1BP4uMoDsscithKpdhiD3_y3y8svY-h-2urPg@mail.gmail.com>
	<1655439322.15273081.1398260797795.JavaMail.zimbra@redhat.com>
Message-ID: <CALbcAPXX=QQV6beU65grxmx-fEduzrfh4RG0C7TqEkmbwkwnXA@mail.gmail.com>

Is this the sort of thing that geard will address going forward?


On Wed, Apr 23, 2014 at 8:46 AM, Farah Juma <fjuma at redhat.com> wrote:

>
> > From: "Jim McGuinness" <dador92 at gmail.com>
> > To: "Farah Juma" <fjuma at redhat.com>, wildfly-dev at lists.jboss.org
> > Sent: Wednesday, April 23, 2014 9:10:02 AM
> > Subject: Re: [wildfly-dev] WildFly 8.1.0.CR1 on OpenShift
> >
> > Farah,
> >
> > I've been looking at this some more, and the marker for Java just toggles
> > back and forth between Java 6 and Java 7. If the Java 7 marker is not
> > present, then a cartridge just defaults back to Java 6.
> >
> > But you still have to have the version of Java installed on the gear in
> > order to toggle back and forth.
> >
> > Here are the contents of the /usr/lib/jvm directory on the gear where
> > OpenShift online installed my Wildfly 8.1
> > cartridge ...
> >
> > lrwxrwxrwx.  1 root root   26 Apr 22 13:19 java ->
> > /etc/alternatives/java_sdk
> > drwxr-xr-x.  3 root root 4.0K Feb 18  2013 java-1.5.0-gcj-1.5.0.0
> > lrwxrwxrwx.  1 root root   32 Apr 22 13:19 java-1.6.0 ->
> > /etc/alternatives/java_sdk_1.6.0
> > lrwxrwxrwx.  1 root root   26 Apr 22 13:19 java-1.6.0-openjdk ->
> > java-1.6.0-openjdk-1.6.0.0
> > drwxr-xr-x.  7 root root 4.0K Apr 11 06:57 java-1.6.0-openjdk-1.6.0.0
> > lrwxrwxrwx.  1 root root   32 Apr 22 13:18 java-1.7.0 ->
> > /etc/alternatives/java_sdk_1.7.0
> > lrwxrwxrwx.  1 root root   27 Apr 22 13:18 java-1.7.0-openjdk ->
> > java-1.7.0-openjdk-1.7.0.55
> > drwxr-xr-x.  3 root root 4.0K Feb  3 17:06 java-1.7.0-openjdk-1.7.0.45
> > drwxr-xr-x.  3 root root 4.0K Apr 22 13:19 java-1.7.0-openjdk-1.7.0.51
> > drwxr-xr-x.  7 root root 4.0K Apr 22 13:18 java-1.7.0-openjdk-1.7.0.55
> > drwxr-xr-x.  3 root root 4.0K May  1  2013 java-1.7.0-openjdk-1.7.0.9
> > lrwxrwxrwx.  1 root root   34 Apr 22 13:19 java-openjdk ->
> > /etc/alternatives/java_sdk_openjdk
> > lrwxrwxrwx.  1 root root   21 Apr 22 13:19 jre -> /etc/alternatives/jre
> > lrwxrwxrwx.  1 root root   27 Feb 18  2013 jre-1.5.0 ->
> > /etc/alternatives/jre_1.5.0
> > lrwxrwxrwx.  1 root root   26 Feb 18  2013 jre-1.5.0-gcj ->
> > java-1.5.0-gcj-1.5.0.0/jre
> > lrwxrwxrwx.  1 root root   27 Apr 22 13:19 jre-1.6.0 ->
> > /etc/alternatives/jre_1.6.0
> > lrwxrwxrwx.  1 root root   30 Apr 22 13:19 jre-1.6.0-openjdk ->
> > java-1.6.0-openjdk-1.6.0.0/jre
> > lrwxrwxrwx.  1 root root   27 Apr 22 13:18 jre-1.7.0 ->
> > /etc/alternatives/jre_1.7.0
> > lrwxrwxrwx.  1 root root   31 Apr 22 13:18 jre-1.7.0-openjdk ->
> > java-1.7.0-openjdk-1.7.0.55/jre
> > lrwxrwxrwx.  1 root root   25 Feb 18  2013 jre-gcj ->
> > /etc/alternatives/jre_gcj
> > lrwxrwxrwx.  1 root root   29 Apr 22 13:19 jre-openjdk ->
> > /etc/alternatives/jre_openjdk
> >
> > I truly think the answer is that the gear needs to add Java 8 SE in order
> > for the Wildfly cartridge to be able to use it. And the Wildfly cartridge
> > will then need to be updated to respond to a Java 8 marker..
>
> That's correct. Since OpenShift hasn't yet made JDK 8 available though,
> the idea is to update the WildFly cartridge so that it installs JDK 8 on
> the gear.
>
> Farah
>
> >
> >
> > On Tue, Apr 22, 2014 at 6:57 PM, Jim McGuinness <dador92 at gmail.com>
> wrote:
> >
> > > Doesn't the marker just indicate the JDK version(s) used/usable by the
> app
> > > (in this case wildfly)? The gear still has to have a JDK 8 installed
> > > doesn't it?
> > >
> > >
> > > On Tue, Apr 22, 2014 at 6:00 PM, Farah Juma <fjuma at redhat.com> wrote:
> > >
> > >>
> > >> > From: "Jim McGuinness" <dador92 at gmail.com>
> > >> > To: "Farah Juma" <fjuma at redhat.com>
> > >> > Sent: Tuesday, April 22, 2014 5:57:07 PM
> > >> > Subject: Re: [wildfly-dev] WildFly 8.1.0.CR1 on OpenShift
> > >> >
> > >> > Would it be better to create a JDK 8 cartridge which could be
> deployed
> > >> in
> > >> > the same gear as the Wildfly 8.1 cartridge? Ideally you'll want to
> use
> > >> the
> > >> > JDK 8 for more than just Wildfly.
> > >>
> > >> Support for different JDK versions is added using marker files (e.g.,
> > >> this post describes how JDK7 support was added:
> > >>
> https://www.openshift.com/blogs/new-openshift-release-aug-8-2012-java-7-cakephp-origin-updates-and-more
> > >> ).
> > >>
> > >> > Is the gear's lack of a JDK 8 caused by the requirements of SELinux?
> > >>
> > >> It just hasn't been added by OpenShift yet.
> > >>
> > >> >
> > >> > On Tue, Apr 22, 2014 at 2:35 PM, Farah Juma <fjuma at redhat.com>
> wrote:
> > >> >
> > >> > > OpenShift hasn't added support for JDK8 yet but it should be
> possible
> > >> for
> > >> > > us to add it into the WildFly cartridge. I'll look into this.
> > >> > >
> > >> > > Farah
> > >> > >
> > >> > > ----- Original Message -----
> > >> > > > From: "Toma? Cerar" <tomaz.cerar at gmail.com>
> > >> > > > To: "Farah Juma" <fjuma at redhat.com>
> > >> > > > Cc: "WildFly Dev" <wildfly-dev at lists.jboss.org>
> > >> > > > Sent: Tuesday, April 22, 2014 3:22:45 PM
> > >> > > > Subject: Re: [wildfly-dev] WildFly 8.1.0.CR1 on OpenShift
> > >> > > >
> > >> > > > Great news!
> > >> > > >
> > >> > > > Btw, did you manage to add support for JDK8 yet?
> > >> > > > Not sure how far is openshift in this area but it would be
> great if
> > >> we
> > >> > > > would have JDK8 with WildFly on OpenShift.
> > >> > > >
> > >> > > > --
> > >> > > > tomaz
> > >> > > >
> > >> > > >
> > >> > > > On Tue, Apr 22, 2014 at 9:17 PM, Farah Juma <fjuma at redhat.com>
> > >> wrote:
> > >> > > >
> > >> > > > > Since WildFly 8.1.0.CR1 was released last week, the OpenShift
> > >> WildFly
> > >> > > > > cartridge has been updated as well.
> > >> > > > >
> > >> > > > > See
> > >> > > > >
> > >> > >
> > >>
> https://community.jboss.org/people/fjuma/blog/2014/04/22/wildfly-810cr1-on-openshiftfor
> > >> > > > > more details on how to get started. Please try it out and
> provide
> > >> > > > > feedback.
> > >> > > > >
> > >> > > > > _______________________________________________
> > >> > > > > wildfly-dev mailing list
> > >> > > > > wildfly-dev at lists.jboss.org
> > >> > > > > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> > >> > > > >
> > >> > > >
> > >> > >
> > >> > > _______________________________________________
> > >> > > wildfly-dev mailing list
> > >> > > wildfly-dev at lists.jboss.org
> > >> > > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140423/a9778c7a/attachment.html 

From arjan.tijms at gmail.com  Wed Apr 23 09:54:43 2014
From: arjan.tijms at gmail.com (arjan tijms)
Date: Wed, 23 Apr 2014 15:54:43 +0200
Subject: [wildfly-dev] my 2 cents on Security Manager discussion
In-Reply-To: <1966656146.15206399.1398256857398.JavaMail.zimbra@redhat.com>
References: <5351AAE8.5010107@redhat.com> <5351AC23.1090903@gmail.com>
	<7EC05876-28DA-44EA-8CF0-CFD5D85A37E7@redhat.com>
	<CAE=-AhDGUmJKJHuv0TnDEsnfGXXNy3aWvyARr1B=Kpx9ndZc8g@mail.gmail.com>
	<1966656146.15206399.1398256857398.JavaMail.zimbra@redhat.com>
Message-ID: <CAE=-AhDnqt5SN8QOJMvyqfNvcdKjdKh6a0fGgrfVKxWO884NrA@mail.gmail.com>

Hi,


On Wed, Apr 23, 2014 at 2:40 PM, Josef Cacek <jcacek at redhat.com> wrote:

> let me give you few examples. Do you really want to allow
> users/deployed-apps/3rd-party-libs
>
>  * call System.exit()?
>  * change behavior of the whole JVM by changing some system properties
> (keystores and truststores for instance)?
>  * use reflection to read/change private data (caches, etc)?
>  * access the filesystem (e.g. rewrite the WildFly configuration files)?
>  * ...
>

It's not about wanting that or not wanting it I think. It's about the
question if you run code that you trust or not on your server. If you don't
trust your code, then you may indeed be tempted to put up guards against
calling System.exit(), etc.

But...

In practice, in at least my experience, it just doesn't happen a lot if
ever that you run untrusted code on a server.

In the majority of the cases the code I and my team deploy is the code that
I and my team have written. We don't need to protect ourselves against
calling System.exit(). If we suspect that a library that we use would be
potentially malicious enough that it called System.exit() or did other
nasty things then we just don't use it.

Since in the overwhelming majority of cases you totally control the code
and all its dependencies on the server, there's no need to put guards in
place. Either you trust the code and use it, or you don't trust the code
and then don't use it. As soon as someone would feel a need to put a guard
in place, then it means the code isn't fully trusted and thus the decision
not to use that code has already been made IMHO.

And particularly about the "users" in "to allow
users/deployed-apps/3rd-party-libs": the permissions you mentioned are all
*code level* permissions. Users aren't code, but interact with your system
via its UI. So naturally you need a lot of user level permissions, but this
is something else than code level ones.

Kind regards,
Arjan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140423/86bfef9f/attachment.html 

From anmiller at redhat.com  Wed Apr 23 10:04:45 2014
From: anmiller at redhat.com (Andrig Miller)
Date: Wed, 23 Apr 2014 10:04:45 -0400 (EDT)
Subject: [wildfly-dev] my 2 cents on Security Manager discussion
In-Reply-To: <CAE=-AhDnqt5SN8QOJMvyqfNvcdKjdKh6a0fGgrfVKxWO884NrA@mail.gmail.com>
References: <5351AAE8.5010107@redhat.com> <5351AC23.1090903@gmail.com>
	<7EC05876-28DA-44EA-8CF0-CFD5D85A37E7@redhat.com>
	<CAE=-AhDGUmJKJHuv0TnDEsnfGXXNy3aWvyARr1B=Kpx9ndZc8g@mail.gmail.com>
	<1966656146.15206399.1398256857398.JavaMail.zimbra@redhat.com>
	<CAE=-AhDnqt5SN8QOJMvyqfNvcdKjdKh6a0fGgrfVKxWO884NrA@mail.gmail.com>
Message-ID: <9289521.255.1398261882468.JavaMail.andrig@worklaptop.miller.org>

----- Original Message -----

> From: "arjan tijms" <arjan.tijms at gmail.com>
> To: "Josef Cacek" <jcacek at redhat.com>
> Cc: "WildFly Dev" <wildfly-dev at lists.jboss.org>
> Sent: Wednesday, April 23, 2014 7:54:43 AM
> Subject: Re: [wildfly-dev] my 2 cents on Security Manager discussion

> Hi,

> On Wed, Apr 23, 2014 at 2:40 PM, Josef Cacek < jcacek at redhat.com >
> wrote:

> > let me give you few examples. Do you really want to allow
> > users/deployed-apps/3rd-party-libs
> 

> > * call System.exit()?
> 
> > * change behavior of the whole JVM by changing some system
> > properties
> > (keystores and truststores for instance)?
> 
> > * use reflection to read/change private data (caches, etc)?
> 
> > * access the filesystem (e.g. rewrite the WildFly configuration
> > files)?
> 
> > * ...
> 

> It's not about wanting that or not wanting it I think. It's about the
> question if you run code that you trust or not on your server. If
> you don't trust your code, then you may indeed be tempted to put up
> guards against calling System.exit(), etc.

> But...

> In practice, in at least my experience, it just doesn't happen a lot
> if ever that you run untrusted code on a server.

> In the majority of the cases the code I and my team deploy is the
> code that I and my team have written. We don't need to protect
> ourselves against calling System.exit(). If we suspect that a
> library that we use would be potentially malicious enough that it
> called System.exit() or did other nasty things then we just don't
> use it.

> Since in the overwhelming majority of cases you totally control the
> code and all its dependencies on the server, there's no need to put
> guards in place. Either you trust the code and use it, or you don't
> trust the code and then don't use it.
I would add here, that you may start off not trusting some code you want to use, but if that code is open source, then you can audit that code for any malicious behavior. Open source libraries, as third-party dependencies has become the norm too. 

Andy 

> As soon as someone would feel a need to put a guard in place, then it
> means the code isn't fully trusted and thus the decision not to use
> that code has already been made IMHO.

> And particularly about the "users" in "to allow
> users/deployed-apps/3rd-party-libs": the permissions you mentioned
> are all *code level* permissions. Users aren't code, but interact
> with your system via its UI. So naturally you need a lot of user
> level permissions, but this is something else than code level ones.

> Kind regards,
> Arjan

> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140423/c4ea9d88/attachment-0001.html 

From arjan.tijms at gmail.com  Wed Apr 23 10:08:28 2014
From: arjan.tijms at gmail.com (arjan tijms)
Date: Wed, 23 Apr 2014 16:08:28 +0200
Subject: [wildfly-dev] my 2 cents on Security Manager discussion
In-Reply-To: <5357C260.9080005@redhat.com>
References: <5351AAE8.5010107@redhat.com> <5351AC23.1090903@gmail.com>
	<7EC05876-28DA-44EA-8CF0-CFD5D85A37E7@redhat.com>
	<CAE=-AhDGUmJKJHuv0TnDEsnfGXXNy3aWvyARr1B=Kpx9ndZc8g@mail.gmail.com>
	<1966656146.15206399.1398256857398.JavaMail.zimbra@redhat.com>
	<5357C260.9080005@redhat.com>
Message-ID: <CAE=-AhCMfAuQPv0ddpd49GzbRX-dQ_6PZa7bVnqZAxshRKnRtw@mail.gmail.com>

Hi,

On Wed, Apr 23, 2014 at 3:38 PM, Bill Burke <bburke at redhat.com> wrote:

> As much as we like to think the app server is an operating system, it
> isn't.  The app server isn't a place where untrusted apps run.
>

I'm a big fan of this view. I know that originally the AS may have been
seen as a kind of OS for server apps, but in practice this just hasn't
worked out. The protection model of the OS with its isolating processes is
just much more powerful.

Running a single app per AS gives you better protection, even more if each
AS runs inside its own virtual server (which makes it even easier to limit
the CPU usage of individual apps). Additionally, a lot of problems
associated with updating either the JVM, the entire AS, or one or more
libraries of the AS just go away in the one-app-per-AS setup. Adam Bien
wrote a good article about this:
http://adam-bien.com/roller/abien/entry/why_not_one_application_per

I think Red Hat/JBoss shares the same belief. I mean, why else would
OpenShift use SELinux to isolate apps and not just run a bunch of them on a
single JBoss AS?

Kind regards,
Arjan Tijms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140423/18e2bfd3/attachment.html 

From jason.greene at redhat.com  Wed Apr 23 10:34:04 2014
From: jason.greene at redhat.com (Jason Greene)
Date: Wed, 23 Apr 2014 09:34:04 -0500
Subject: [wildfly-dev] my 2 cents on Security Manager discussion
In-Reply-To: <CAE=-AhCMfAuQPv0ddpd49GzbRX-dQ_6PZa7bVnqZAxshRKnRtw@mail.gmail.com>
References: <5351AAE8.5010107@redhat.com> <5351AC23.1090903@gmail.com>
	<7EC05876-28DA-44EA-8CF0-CFD5D85A37E7@redhat.com>
	<CAE=-AhDGUmJKJHuv0TnDEsnfGXXNy3aWvyARr1B=Kpx9ndZc8g@mail.gmail.com>
	<1966656146.15206399.1398256857398.JavaMail.zimbra@redhat.com>
	<5357C260.9080005@redhat.com>
	<CAE=-AhCMfAuQPv0ddpd49GzbRX-dQ_6PZa7bVnqZAxshRKnRtw@mail.gmail.com>
Message-ID: <A1FE1EF6-6E66-4CB4-BA4E-F0EB25046865@redhat.com>


On Apr 23, 2014, at 9:08 AM, arjan tijms <arjan.tijms at gmail.com> wrote:

> Hi,
> 
> On Wed, Apr 23, 2014 at 3:38 PM, Bill Burke <bburke at redhat.com> wrote:
> As much as we like to think the app server is an operating system, it
> isn't.  The app server isn't a place where untrusted apps run.
> 
> I'm a big fan of this view. I know that originally the AS may have been seen as a kind of OS for server apps, but in practice this just hasn't worked out. The protection model of the OS with its isolating processes is just much more powerful.
> 
> Running a single app per AS gives you better protection, even more if each AS runs inside its own virtual server (which makes it even easier to limit the CPU usage of individual apps). Additionally, a lot of problems associated with updating either the JVM, the entire AS, or one or more libraries of the AS just go away in the one-app-per-AS setup. Adam Bien wrote a good article about this: http://adam-bien.com/roller/abien/entry/why_not_one_application_per
> 
> I think Red Hat/JBoss shares the same belief. I mean, why else would OpenShift use SELinux to isolate apps and not just run a bunch of them on a single JBoss AS?

Yes that is our recommended security model, and yes thats precisely what we do on OpenShift because otherwise one customer could potentially access another?s data, which would be very very bad :)

We do hope that one day a multi-tenant JVM will come around, since it would reduce the memory cost of multiple JVMs (base JVM heap + class code memory which ideally you could share but can?t currently). Although this is only really a problem when you have thousands of instances on a box (you are running a PAAS).

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat



From bburke at redhat.com  Wed Apr 23 10:39:04 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 23 Apr 2014 10:39:04 -0400
Subject: [wildfly-dev] my 2 cents on Security Manager discussion
In-Reply-To: <A1FE1EF6-6E66-4CB4-BA4E-F0EB25046865@redhat.com>
References: <5351AAE8.5010107@redhat.com> <5351AC23.1090903@gmail.com>
	<7EC05876-28DA-44EA-8CF0-CFD5D85A37E7@redhat.com>
	<CAE=-AhDGUmJKJHuv0TnDEsnfGXXNy3aWvyARr1B=Kpx9ndZc8g@mail.gmail.com>
	<1966656146.15206399.1398256857398.JavaMail.zimbra@redhat.com>
	<5357C260.9080005@redhat.com>
	<CAE=-AhCMfAuQPv0ddpd49GzbRX-dQ_6PZa7bVnqZAxshRKnRtw@mail.gmail.com>
	<A1FE1EF6-6E66-4CB4-BA4E-F0EB25046865@redhat.com>
Message-ID: <5357D088.1000001@redhat.com>



On 4/23/2014 10:34 AM, Jason Greene wrote:
>
> On Apr 23, 2014, at 9:08 AM, arjan tijms <arjan.tijms at gmail.com> wrote:
>
>> Hi,
>>
>> On Wed, Apr 23, 2014 at 3:38 PM, Bill Burke <bburke at redhat.com> wrote:
>> As much as we like to think the app server is an operating system, it
>> isn't.  The app server isn't a place where untrusted apps run.
>>
>> I'm a big fan of this view. I know that originally the AS may have been seen as a kind of OS for server apps, but in practice this just hasn't worked out. The protection model of the OS with its isolating processes is just much more powerful.
>>
>> Running a single app per AS gives you better protection, even more if each AS runs inside its own virtual server (which makes it even easier to limit the CPU usage of individual apps). Additionally, a lot of problems associated with updating either the JVM, the entire AS, or one or more libraries of the AS just go away in the one-app-per-AS setup. Adam Bien wrote a good article about this: http://adam-bien.com/roller/abien/entry/why_not_one_application_per
>>
>> I think Red Hat/JBoss shares the same belief. I mean, why else would OpenShift use SELinux to isolate apps and not just run a bunch of them on a single JBoss AS?
>
> Yes that is our recommended security model, and yes thats precisely what we do on OpenShift because otherwise one customer could potentially access another?s data, which would be very very bad :)
>
> We do hope that one day a multi-tenant JVM will come around, since it would reduce the memory cost of multiple JVMs (base JVM heap + class code memory which ideally you could share but can?t currently). Although this is only really a problem when you have thousands of instances on a box (you are running a PAAS).
>

Just cross-process/cross-OS-VM shared jars would probably be really 
huge.  Not something we can really focus on in the middleware side of 
development though.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From jason.greene at redhat.com  Wed Apr 23 10:10:03 2014
From: jason.greene at redhat.com (Jason Greene)
Date: Wed, 23 Apr 2014 09:10:03 -0500
Subject: [wildfly-dev] my 2 cents on Security Manager discussion
In-Reply-To: <5357C260.9080005@redhat.com>
References: <5351AAE8.5010107@redhat.com>
	<5351AC23.1090903@gmail.com>	<7EC05876-28DA-44EA-8CF0-CFD5D85A37E7@redhat.com>	<CAE=-AhDGUmJKJHuv0TnDEsnfGXXNy3aWvyARr1B=Kpx9ndZc8g@mail.gmail.com>
	<1966656146.15206399.1398256857398.JavaMail.zimbra@redhat.com>
	<5357C260.9080005@redhat.com>
Message-ID: <C45EC292-C255-4676-9B58-D2B96755157B@redhat.com>

Right. An operating system is able to segment code by using page mapping and traps. Each process gets a dedicated memory area that another process can?t access at a very low level (without special permissions). The JVM + SM on the other hand relies on protection at a higher level. Fundamentally the entire JVM memory area is shared between all code. The only thing that prevents it is lots of security checks on every possible method that might leak a reference. So the fundamental flaw is that the SM requires a perfect policy, and is essentially trust-by-default. If a developer forgets to add a check, then a vulnerability is possible. This happens frequently, even in the JDK itself (hence the multiple CVEs)

The only way the JVM could fix this, is if it introduced real multi-tenancy at the lowest levels. You would have to operate similar to an OS and assign blocks of heap to a particular app, and allow sharing for certain ?safe? things like code pages tied to class implementations. 

On Apr 23, 2014, at 8:38 AM, Bill Burke <bburke at redhat.com> wrote:

> As much as we like to think the app server is an operating system, it 
> isn't.  The app server isn't a place where untrusted apps run.
> 
> On 4/23/2014 8:40 AM, Josef Cacek wrote:
>> Hi Arjan,
>> 
>> let me give you few examples. Do you really want to allow users/deployed-apps/3rd-party-libs
>> 
>>  * call System.exit()?
>>  * change behavior of the whole JVM by changing some system properties (keystores and truststores for instance)?
>>  * use reflection to read/change private data (caches, etc)?
>>  * access the filesystem (e.g. rewrite the WildFly configuration files)?
>>  * ...
>> 
>> If the answer is always yes, then you don't need the JSM I think.
>> 
>> But if you care what can do the parts of code which you don't have under full control, then you should really use the Java Security Manager.
>> 
>> Best regards,
>> 
>> -- Josef
>> 
>> ----- Original Message -----
>>> From: "arjan tijms" <arjan.tijms at gmail.com>
>>> To: "Jason T. Greene" <jgreene at redhat.com>
>>> Cc: wildfly-dev at lists.jboss.org
>>> Sent: Saturday, April 19, 2014 7:43:24 PM
>>> Subject: Re: [wildfly-dev] my 2 cents on Security Manager discussion
>>> 
>>> Hi,
>>> 
>>> Just wondering, but what is the primary use case for a security manager
>>> server side?
>>> 
>>> While the model obviously makes sense for Applets and Webstart where
>>> untrusted code is executed on the user's machine, I found it to be extremely
>>> rare for a server to run untrusted code. In fact, I don't think I've ever
>>> seen this situation.
>>> 
>>> There's maybe a case to prevent privilege escalation in case of a legitimate
>>> app being hacked, but in practice it doesn't look like a security manager is
>>> really being used a lot for that, is it? Instead the default thing to do
>>> there seems to be to run the AS under a user with limited rights on the host
>>> OS and/or use things like SELinix or Virtual Servers (e.g. XEN) to isolate
>>> the complete AS.
>>> 
>>> Kind regards,
>>> Arjan Tijms
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> 
> 
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat



From fjuma at redhat.com  Wed Apr 23 11:13:24 2014
From: fjuma at redhat.com (Farah Juma)
Date: Wed, 23 Apr 2014 11:13:24 -0400 (EDT)
Subject: [wildfly-dev] WildFly 8.1.0.CR1 on OpenShift
In-Reply-To: <CALbcAPXX=QQV6beU65grxmx-fEduzrfh4RG0C7TqEkmbwkwnXA@mail.gmail.com>
References: <844163581.11186191.1397764995828.JavaMail.zimbra@redhat.com>
	<1976792542.14584150.1398195340183.JavaMail.zimbra@redhat.com>
	<CALbcAPW7ZJRsp3ovpZfenj_WUBfbSwmerSGo0qW3_p5TKCYNKQ@mail.gmail.com>
	<1165286158.14704733.1398207657860.JavaMail.zimbra@redhat.com>
	<CALbcAPV-19V6MpgbTn6yxVSnrn=TrBWOKV8DAnTYA=+ZDMb2Qw@mail.gmail.com>
	<CALbcAPUwm5UfN1BP4uMoDsscithKpdhiD3_y3y8svY-h-2urPg@mail.gmail.com>
	<1655439322.15273081.1398260797795.JavaMail.zimbra@redhat.com>
	<CALbcAPXX=QQV6beU65grxmx-fEduzrfh4RG0C7TqEkmbwkwnXA@mail.gmail.com>
Message-ID: <987634193.15380670.1398266004125.JavaMail.zimbra@redhat.com>

I would think so. See https://www.openshift.com/content/support-for-jdk-8.


----- Original Message -----
> From: "Jim McGuinness" <dador92 at gmail.com>
> To: "Farah Juma" <fjuma at redhat.com>
> Cc: "WildFly Dev" <wildfly-dev at lists.jboss.org>
> Sent: Wednesday, April 23, 2014 9:50:01 AM
> Subject: Re: [wildfly-dev] WildFly 8.1.0.CR1 on OpenShift
> 
> Is this the sort of thing that geard will address going forward?
> 
> 
> On Wed, Apr 23, 2014 at 8:46 AM, Farah Juma <fjuma at redhat.com> wrote:
> 
> >
> > > From: "Jim McGuinness" <dador92 at gmail.com>
> > > To: "Farah Juma" <fjuma at redhat.com>, wildfly-dev at lists.jboss.org
> > > Sent: Wednesday, April 23, 2014 9:10:02 AM
> > > Subject: Re: [wildfly-dev] WildFly 8.1.0.CR1 on OpenShift
> > >
> > > Farah,
> > >
> > > I've been looking at this some more, and the marker for Java just toggles
> > > back and forth between Java 6 and Java 7. If the Java 7 marker is not
> > > present, then a cartridge just defaults back to Java 6.
> > >
> > > But you still have to have the version of Java installed on the gear in
> > > order to toggle back and forth.
> > >
> > > Here are the contents of the /usr/lib/jvm directory on the gear where
> > > OpenShift online installed my Wildfly 8.1
> > > cartridge ...
> > >
> > > lrwxrwxrwx.  1 root root   26 Apr 22 13:19 java ->
> > > /etc/alternatives/java_sdk
> > > drwxr-xr-x.  3 root root 4.0K Feb 18  2013 java-1.5.0-gcj-1.5.0.0
> > > lrwxrwxrwx.  1 root root   32 Apr 22 13:19 java-1.6.0 ->
> > > /etc/alternatives/java_sdk_1.6.0
> > > lrwxrwxrwx.  1 root root   26 Apr 22 13:19 java-1.6.0-openjdk ->
> > > java-1.6.0-openjdk-1.6.0.0
> > > drwxr-xr-x.  7 root root 4.0K Apr 11 06:57 java-1.6.0-openjdk-1.6.0.0
> > > lrwxrwxrwx.  1 root root   32 Apr 22 13:18 java-1.7.0 ->
> > > /etc/alternatives/java_sdk_1.7.0
> > > lrwxrwxrwx.  1 root root   27 Apr 22 13:18 java-1.7.0-openjdk ->
> > > java-1.7.0-openjdk-1.7.0.55
> > > drwxr-xr-x.  3 root root 4.0K Feb  3 17:06 java-1.7.0-openjdk-1.7.0.45
> > > drwxr-xr-x.  3 root root 4.0K Apr 22 13:19 java-1.7.0-openjdk-1.7.0.51
> > > drwxr-xr-x.  7 root root 4.0K Apr 22 13:18 java-1.7.0-openjdk-1.7.0.55
> > > drwxr-xr-x.  3 root root 4.0K May  1  2013 java-1.7.0-openjdk-1.7.0.9
> > > lrwxrwxrwx.  1 root root   34 Apr 22 13:19 java-openjdk ->
> > > /etc/alternatives/java_sdk_openjdk
> > > lrwxrwxrwx.  1 root root   21 Apr 22 13:19 jre -> /etc/alternatives/jre
> > > lrwxrwxrwx.  1 root root   27 Feb 18  2013 jre-1.5.0 ->
> > > /etc/alternatives/jre_1.5.0
> > > lrwxrwxrwx.  1 root root   26 Feb 18  2013 jre-1.5.0-gcj ->
> > > java-1.5.0-gcj-1.5.0.0/jre
> > > lrwxrwxrwx.  1 root root   27 Apr 22 13:19 jre-1.6.0 ->
> > > /etc/alternatives/jre_1.6.0
> > > lrwxrwxrwx.  1 root root   30 Apr 22 13:19 jre-1.6.0-openjdk ->
> > > java-1.6.0-openjdk-1.6.0.0/jre
> > > lrwxrwxrwx.  1 root root   27 Apr 22 13:18 jre-1.7.0 ->
> > > /etc/alternatives/jre_1.7.0
> > > lrwxrwxrwx.  1 root root   31 Apr 22 13:18 jre-1.7.0-openjdk ->
> > > java-1.7.0-openjdk-1.7.0.55/jre
> > > lrwxrwxrwx.  1 root root   25 Feb 18  2013 jre-gcj ->
> > > /etc/alternatives/jre_gcj
> > > lrwxrwxrwx.  1 root root   29 Apr 22 13:19 jre-openjdk ->
> > > /etc/alternatives/jre_openjdk
> > >
> > > I truly think the answer is that the gear needs to add Java 8 SE in order
> > > for the Wildfly cartridge to be able to use it. And the Wildfly cartridge
> > > will then need to be updated to respond to a Java 8 marker..
> >
> > That's correct. Since OpenShift hasn't yet made JDK 8 available though,
> > the idea is to update the WildFly cartridge so that it installs JDK 8 on
> > the gear.
> >
> > Farah
> >
> > >
> > >
> > > On Tue, Apr 22, 2014 at 6:57 PM, Jim McGuinness <dador92 at gmail.com>
> > wrote:
> > >
> > > > Doesn't the marker just indicate the JDK version(s) used/usable by the
> > app
> > > > (in this case wildfly)? The gear still has to have a JDK 8 installed
> > > > doesn't it?
> > > >
> > > >
> > > > On Tue, Apr 22, 2014 at 6:00 PM, Farah Juma <fjuma at redhat.com> wrote:
> > > >
> > > >>
> > > >> > From: "Jim McGuinness" <dador92 at gmail.com>
> > > >> > To: "Farah Juma" <fjuma at redhat.com>
> > > >> > Sent: Tuesday, April 22, 2014 5:57:07 PM
> > > >> > Subject: Re: [wildfly-dev] WildFly 8.1.0.CR1 on OpenShift
> > > >> >
> > > >> > Would it be better to create a JDK 8 cartridge which could be
> > deployed
> > > >> in
> > > >> > the same gear as the Wildfly 8.1 cartridge? Ideally you'll want to
> > use
> > > >> the
> > > >> > JDK 8 for more than just Wildfly.
> > > >>
> > > >> Support for different JDK versions is added using marker files (e.g.,
> > > >> this post describes how JDK7 support was added:
> > > >>
> > https://www.openshift.com/blogs/new-openshift-release-aug-8-2012-java-7-cakephp-origin-updates-and-more
> > > >> ).
> > > >>
> > > >> > Is the gear's lack of a JDK 8 caused by the requirements of SELinux?
> > > >>
> > > >> It just hasn't been added by OpenShift yet.
> > > >>
> > > >> >
> > > >> > On Tue, Apr 22, 2014 at 2:35 PM, Farah Juma <fjuma at redhat.com>
> > wrote:
> > > >> >
> > > >> > > OpenShift hasn't added support for JDK8 yet but it should be
> > possible
> > > >> for
> > > >> > > us to add it into the WildFly cartridge. I'll look into this.
> > > >> > >
> > > >> > > Farah
> > > >> > >
> > > >> > > ----- Original Message -----
> > > >> > > > From: "Toma? Cerar" <tomaz.cerar at gmail.com>
> > > >> > > > To: "Farah Juma" <fjuma at redhat.com>
> > > >> > > > Cc: "WildFly Dev" <wildfly-dev at lists.jboss.org>
> > > >> > > > Sent: Tuesday, April 22, 2014 3:22:45 PM
> > > >> > > > Subject: Re: [wildfly-dev] WildFly 8.1.0.CR1 on OpenShift
> > > >> > > >
> > > >> > > > Great news!
> > > >> > > >
> > > >> > > > Btw, did you manage to add support for JDK8 yet?
> > > >> > > > Not sure how far is openshift in this area but it would be
> > great if
> > > >> we
> > > >> > > > would have JDK8 with WildFly on OpenShift.
> > > >> > > >
> > > >> > > > --
> > > >> > > > tomaz
> > > >> > > >
> > > >> > > >
> > > >> > > > On Tue, Apr 22, 2014 at 9:17 PM, Farah Juma <fjuma at redhat.com>
> > > >> wrote:
> > > >> > > >
> > > >> > > > > Since WildFly 8.1.0.CR1 was released last week, the OpenShift
> > > >> WildFly
> > > >> > > > > cartridge has been updated as well.
> > > >> > > > >
> > > >> > > > > See
> > > >> > > > >
> > > >> > >
> > > >>
> > https://community.jboss.org/people/fjuma/blog/2014/04/22/wildfly-810cr1-on-openshiftfor
> > > >> > > > > more details on how to get started. Please try it out and
> > provide
> > > >> > > > > feedback.
> > > >> > > > >
> > > >> > > > > _______________________________________________
> > > >> > > > > wildfly-dev mailing list
> > > >> > > > > wildfly-dev at lists.jboss.org
> > > >> > > > > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> > > _______________________________________________
> > > >> > > wildfly-dev mailing list
> > > >> > > wildfly-dev at lists.jboss.org
> > > >> > > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> > > >> > >
> > > >> >
> > > >>
> > > >
> > > >
> > >
> >
>


From Anil.Saldhana at redhat.com  Wed Apr 23 12:00:36 2014
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Wed, 23 Apr 2014 11:00:36 -0500
Subject: [wildfly-dev] my 2 cents on Security Manager discussion
In-Reply-To: <C45EC292-C255-4676-9B58-D2B96755157B@redhat.com>
References: <5351AAE8.5010107@redhat.com>	<5351AC23.1090903@gmail.com>	<7EC05876-28DA-44EA-8CF0-CFD5D85A37E7@redhat.com>	<CAE=-AhDGUmJKJHuv0TnDEsnfGXXNy3aWvyARr1B=Kpx9ndZc8g@mail.gmail.com>	<1966656146.15206399.1398256857398.JavaMail.zimbra@redhat.com>	<5357C260.9080005@redhat.com>
	<C45EC292-C255-4676-9B58-D2B96755157B@redhat.com>
Message-ID: <5357E3A4.3060804@redhat.com>

Well explained, Jason.  I feel the JVM needs to be a true multi-tenant 
system to be a serious contender in the multi-tenant cloud env. I doubt 
any efforts are being made at the VM level.

On 04/23/2014 09:10 AM, Jason Greene wrote:
> Right. An operating system is able to segment code by using page mapping and traps. Each process gets a dedicated memory area that another process can?t access at a very low level (without special permissions). The JVM + SM on the other hand relies on protection at a higher level. Fundamentally the entire JVM memory area is shared between all code. The only thing that prevents it is lots of security checks on every possible method that might leak a reference. So the fundamental flaw is that the SM requires a perfect policy, and is essentially trust-by-default. If a developer forgets to add a check, then a vulnerability is possible. This happens frequently, even in the JDK itself (hence the multiple CVEs)
>
> The only way the JVM could fix this, is if it introduced real multi-tenancy at the lowest levels. You would have to operate similar to an OS and assign blocks of heap to a particular app, and allow sharing for certain ?safe? things like code pages tied to class implementations.
>
> On Apr 23, 2014, at 8:38 AM, Bill Burke <bburke at redhat.com> wrote:
>
>> As much as we like to think the app server is an operating system, it
>> isn't.  The app server isn't a place where untrusted apps run.
>>
>> On 4/23/2014 8:40 AM, Josef Cacek wrote:
>>> Hi Arjan,
>>>
>>> let me give you few examples. Do you really want to allow users/deployed-apps/3rd-party-libs
>>>
>>>   * call System.exit()?
>>>   * change behavior of the whole JVM by changing some system properties (keystores and truststores for instance)?
>>>   * use reflection to read/change private data (caches, etc)?
>>>   * access the filesystem (e.g. rewrite the WildFly configuration files)?
>>>   * ...
>>>
>>> If the answer is always yes, then you don't need the JSM I think.
>>>
>>> But if you care what can do the parts of code which you don't have under full control, then you should really use the Java Security Manager.
>>>
>>> Best regards,
>>>
>>> -- Josef
>>>
>>> ----- Original Message -----
>>>> From: "arjan tijms" <arjan.tijms at gmail.com>
>>>> To: "Jason T. Greene" <jgreene at redhat.com>
>>>> Cc: wildfly-dev at lists.jboss.org
>>>> Sent: Saturday, April 19, 2014 7:43:24 PM
>>>> Subject: Re: [wildfly-dev] my 2 cents on Security Manager discussion
>>>>
>>>> Hi,
>>>>
>>>> Just wondering, but what is the primary use case for a security manager
>>>> server side?
>>>>
>>>> While the model obviously makes sense for Applets and Webstart where
>>>> untrusted code is executed on the user's machine, I found it to be extremely
>>>> rare for a server to run untrusted code. In fact, I don't think I've ever
>>>> seen this situation.
>>>>
>>>> There's maybe a case to prevent privilege escalation in case of a legitimate
>>>> app being hacked, but in practice it doesn't look like a security manager is
>>>> really being used a lot for that, is it? Instead the default thing to do
>>>> there seems to be to run the AS under a user with limited rights on the host
>>>> OS and/or use things like SELinix or Virtual Servers (e.g. XEN) to isolate
>>>> the complete AS.
>>>>
>>>> Kind regards,
>>>> Arjan Tijms
>>>>

From jason.greene at redhat.com  Wed Apr 23 18:21:18 2014
From: jason.greene at redhat.com (Jason Greene)
Date: Wed, 23 Apr 2014 17:21:18 -0500
Subject: [wildfly-dev] IMPORTANT - Intermittent Test Ban Redux
Message-ID: <2E5793CC-BE7F-4AA1-B854-5DEE6D359E60@redhat.com>

Hi Everyone,

Almost 2 years ago we agreed to disable all intermittent tests[1]; however, this is still a major problem today, and is still a major hassle for everyone that submits a PR (?retest this please? is now a common part of our process).

I think it?s finally time to enforce this policy, and disallow all tests that lead to even occasional intermittent failures, even if that leads to loss of coverage. The most fundamental need of our test suite, is to catch regressions, and right now it?s not really serving that purpose.

So I propose that after 8.1.0.Final is shipped that we immediately disable all tests with a failing history, and create a JIRA issue for the component author to fix them or the bug that is producing the failure. If after 3 weeks, a JIRA issue has for this has made no progress, I propose we completely remove the test from our codebase. 

In addition, I propose that any repaired test be shown to be intermittent free using a custom CI job (Tomaz can set them) for several runs before accepting them back in.

Thanks!

[1] http://wildfly-development.1055759.n5.nabble.com/IMPORTANT-New-Policy-Proposal-No-More-Intermittent-Test-Failures-td5709984.html#a5709993
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat



From tomaz.cerar at gmail.com  Wed Apr 23 18:36:06 2014
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Thu, 24 Apr 2014 00:36:06 +0200
Subject: [wildfly-dev] IMPORTANT - Intermittent Test Ban Redux
In-Reply-To: <2E5793CC-BE7F-4AA1-B854-5DEE6D359E60@redhat.com>
References: <2E5793CC-BE7F-4AA1-B854-5DEE6D359E60@redhat.com>
Message-ID: <CAMquZP6Hg1BZj4HvVWzgkNgwg=GEXLgDACGFb4xKsWXbVDt8dQ@mail.gmail.com>

+1000

Also when we will have stable testsuite, we can have PR testing against
multiple platforms, so you could get linux & windows results directly on PR.
Currently that would just mean lots and lots of wasted hardware resources

--
tomaz


On Thu, Apr 24, 2014 at 12:21 AM, Jason Greene <jason.greene at redhat.com>wrote:

> Hi Everyone,
>
> Almost 2 years ago we agreed to disable all intermittent tests[1];
> however, this is still a major problem today, and is still a major hassle
> for everyone that submits a PR (?retest this please? is now a common part
> of our process).
>
> I think it?s finally time to enforce this policy, and disallow all tests
> that lead to even occasional intermittent failures, even if that leads to
> loss of coverage. The most fundamental need of our test suite, is to catch
> regressions, and right now it?s not really serving that purpose.
>
> So I propose that after 8.1.0.Final is shipped that we immediately disable
> all tests with a failing history, and create a JIRA issue for the component
> author to fix them or the bug that is producing the failure. If after 3
> weeks, a JIRA issue has for this has made no progress, I propose we
> completely remove the test from our codebase.
>
> In addition, I propose that any repaired test be shown to be intermittent
> free using a custom CI job (Tomaz can set them) for several runs before
> accepting them back in.
>
> Thanks!
>
> [1]
> http://wildfly-development.1055759.n5.nabble.com/IMPORTANT-New-Policy-Proposal-No-More-Intermittent-Test-Failures-td5709984.html#a5709993
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140424/42c8819c/attachment.html 

From jason.greene at redhat.com  Wed Apr 23 18:44:28 2014
From: jason.greene at redhat.com (Jason Greene)
Date: Wed, 23 Apr 2014 17:44:28 -0500
Subject: [wildfly-dev] IMPORTANT - Intermittent Test Ban Redux
In-Reply-To: <2E5793CC-BE7F-4AA1-B854-5DEE6D359E60@redhat.com>
References: <2E5793CC-BE7F-4AA1-B854-5DEE6D359E60@redhat.com>
Message-ID: <D9004C8C-8EFA-4668-85DD-BBEE26941710@redhat.com>

On Apr 23, 2014, at 5:21 PM, Jason Greene <jason.greene at redhat.com> wrote:
> So I propose that after 8.1.0.Final is shipped that we immediately disable all tests with a failing history, and create a JIRA issue for the component author to fix them or the bug that is producing the failure. If after 3 weeks, a JIRA issue has for this has made no progress, I propose we completely remove the test from our codebase. 

One small caveat that I forgot to mention, is that we are aware of some failures being caused by arquillian. We should try to work around any such cases if possible, and create a master issue to track the arq problems. A separate initiative will be to address those problems by either fixing arquillian or moving some tests off of it.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat



From jason.greene at redhat.com  Wed Apr 23 18:47:33 2014
From: jason.greene at redhat.com (Jason Greene)
Date: Wed, 23 Apr 2014 17:47:33 -0500
Subject: [wildfly-dev] 8.1.0.Final Criteria
Message-ID: <FEDBDE64-9D3B-4D33-ADA1-671D4BA73C84@redhat.com>

In order to keep the release window small, I am requesting that only blocker level fixes be allowed into 8.1.0.Final at this time. If you believe you have one, please raise the status on the Jira issue and let me know about it.

We are in the process of shifting master to 9, and so these will be applied to a separate branch. Expect a further announcement on that.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat



From pbielicki at gmail.com  Thu Apr 24 03:49:53 2014
From: pbielicki at gmail.com (Przemyslaw Bielicki)
Date: Thu, 24 Apr 2014 09:49:53 +0200
Subject: [wildfly-dev] my 2 cents on Security Manager discussion
In-Reply-To: <5357E3A4.3060804@redhat.com>
References: <5351AAE8.5010107@redhat.com> <5351AC23.1090903@gmail.com>
	<7EC05876-28DA-44EA-8CF0-CFD5D85A37E7@redhat.com>
	<CAE=-AhDGUmJKJHuv0TnDEsnfGXXNy3aWvyARr1B=Kpx9ndZc8g@mail.gmail.com>
	<1966656146.15206399.1398256857398.JavaMail.zimbra@redhat.com>
	<5357C260.9080005@redhat.com>
	<C45EC292-C255-4676-9B58-D2B96755157B@redhat.com>
	<5357E3A4.3060804@redhat.com>
Message-ID: <CAMvdueDTh4zSEwj+PynSB-3w_kzhdi2Z39pEr7nfYVxdaVGKsQ@mail.gmail.com>

Do we really need multi-tenancy in server-side Java?

We all know that Java has a serious limitation of max heap size - 16GB is
the max I've ever seen (used by Hadoop name node). Now, consider modern
commodity hardware that ships with 500GB - 1000GB of RAM. Let's assume that
your application's max heap usage is really 16GB and another 16GB off-heap
memory (in case of mentioned name node it can be up to max RAM available if
your application uses IO heavily and it can be cached by the OS). My humble
calculations let me think that on such machine we can easily run 16 - 32
separate JVMs (considering RAM only, CPU is another story).

Knowing this, I don't think JVM can be a serious host of multi-tenant
applications in the cloud. I rather see JVM instance per application and in
such case we don't have  security issues and SM is not needed. If one
application is dead (e.g. malicious System.exit, JVM core dump, etc.) all
the rest is safe.


On Wed, Apr 23, 2014 at 6:00 PM, Anil Saldhana <Anil.Saldhana at redhat.com>wrote:

> Well explained, Jason.  I feel the JVM needs to be a true multi-tenant
> system to be a serious contender in the multi-tenant cloud env. I doubt
> any efforts are being made at the VM level.
>
> On 04/23/2014 09:10 AM, Jason Greene wrote:
> > Right. An operating system is able to segment code by using page mapping
> and traps. Each process gets a dedicated memory area that another process
> can?t access at a very low level (without special permissions). The JVM +
> SM on the other hand relies on protection at a higher level. Fundamentally
> the entire JVM memory area is shared between all code. The only thing that
> prevents it is lots of security checks on every possible method that might
> leak a reference. So the fundamental flaw is that the SM requires a perfect
> policy, and is essentially trust-by-default. If a developer forgets to add
> a check, then a vulnerability is possible. This happens frequently, even in
> the JDK itself (hence the multiple CVEs)
> >
> > The only way the JVM could fix this, is if it introduced real
> multi-tenancy at the lowest levels. You would have to operate similar to an
> OS and assign blocks of heap to a particular app, and allow sharing for
> certain ?safe? things like code pages tied to class implementations.
> >
> > On Apr 23, 2014, at 8:38 AM, Bill Burke <bburke at redhat.com> wrote:
> >
> >> As much as we like to think the app server is an operating system, it
> >> isn't.  The app server isn't a place where untrusted apps run.
> >>
> >> On 4/23/2014 8:40 AM, Josef Cacek wrote:
> >>> Hi Arjan,
> >>>
> >>> let me give you few examples. Do you really want to allow
> users/deployed-apps/3rd-party-libs
> >>>
> >>>   * call System.exit()?
> >>>   * change behavior of the whole JVM by changing some system
> properties (keystores and truststores for instance)?
> >>>   * use reflection to read/change private data (caches, etc)?
> >>>   * access the filesystem (e.g. rewrite the WildFly configuration
> files)?
> >>>   * ...
> >>>
> >>> If the answer is always yes, then you don't need the JSM I think.
> >>>
> >>> But if you care what can do the parts of code which you don't have
> under full control, then you should really use the Java Security Manager.
> >>>
> >>> Best regards,
> >>>
> >>> -- Josef
> >>>
> >>> ----- Original Message -----
> >>>> From: "arjan tijms" <arjan.tijms at gmail.com>
> >>>> To: "Jason T. Greene" <jgreene at redhat.com>
> >>>> Cc: wildfly-dev at lists.jboss.org
> >>>> Sent: Saturday, April 19, 2014 7:43:24 PM
> >>>> Subject: Re: [wildfly-dev] my 2 cents on Security Manager discussion
> >>>>
> >>>> Hi,
> >>>>
> >>>> Just wondering, but what is the primary use case for a security
> manager
> >>>> server side?
> >>>>
> >>>> While the model obviously makes sense for Applets and Webstart where
> >>>> untrusted code is executed on the user's machine, I found it to be
> extremely
> >>>> rare for a server to run untrusted code. In fact, I don't think I've
> ever
> >>>> seen this situation.
> >>>>
> >>>> There's maybe a case to prevent privilege escalation in case of a
> legitimate
> >>>> app being hacked, but in practice it doesn't look like a security
> manager is
> >>>> really being used a lot for that, is it? Instead the default thing to
> do
> >>>> there seems to be to run the AS under a user with limited rights on
> the host
> >>>> OS and/or use things like SELinix or Virtual Servers (e.g. XEN) to
> isolate
> >>>> the complete AS.
> >>>>
> >>>> Kind regards,
> >>>> Arjan Tijms
> >>>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140424/50815d85/attachment.html 

From david.lloyd at redhat.com  Thu Apr 24 08:49:07 2014
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Thu, 24 Apr 2014 07:49:07 -0500
Subject: [wildfly-dev] my 2 cents on Security Manager discussion
In-Reply-To: <CAMvdueDTh4zSEwj+PynSB-3w_kzhdi2Z39pEr7nfYVxdaVGKsQ@mail.gmail.com>
References: <5351AAE8.5010107@redhat.com>
	<5351AC23.1090903@gmail.com>	<7EC05876-28DA-44EA-8CF0-CFD5D85A37E7@redhat.com>	<CAE=-AhDGUmJKJHuv0TnDEsnfGXXNy3aWvyARr1B=Kpx9ndZc8g@mail.gmail.com>	<1966656146.15206399.1398256857398.JavaMail.zimbra@redhat.com>	<5357C260.9080005@redhat.com>	<C45EC292-C255-4676-9B58-D2B96755157B@redhat.com>	<5357E3A4.3060804@redhat.com>
	<CAMvdueDTh4zSEwj+PynSB-3w_kzhdi2Z39pEr7nfYVxdaVGKsQ@mail.gmail.com>
Message-ID: <53590843.4060302@redhat.com>

Consider also that there are currently *zero* viable multi-tenant JVMs 
in existence - just some experimental work, that I know of at least.

Using a JVM per application combined with OS-level safeguards is far 
simpler (and more capable) for the small minority of users who feel the 
need to run untrusted code on their system.

On 04/24/2014 02:49 AM, Przemyslaw Bielicki wrote:
> Do we really need multi-tenancy in server-side Java?
>
> We all know that Java has a serious limitation of max heap size - 16GB
> is the max I've ever seen (used by Hadoop name node). Now, consider
> modern commodity hardware that ships with 500GB - 1000GB of RAM. Let's
> assume that your application's max heap usage is really 16GB and another
> 16GB off-heap memory (in case of mentioned name node it can be up to max
> RAM available if your application uses IO heavily and it can be cached
> by the OS). My humble calculations let me think that on such machine we
> can easily run 16 - 32 separate JVMs (considering RAM only, CPU is
> another story).
>
> Knowing this, I don't think JVM can be a serious host of multi-tenant
> applications in the cloud. I rather see JVM instance per application and
> in such case we don't have  security issues and SM is not needed. If one
> application is dead (e.g. malicious System.exit, JVM core dump, etc.)
> all the rest is safe.
>
>
> On Wed, Apr 23, 2014 at 6:00 PM, Anil Saldhana <Anil.Saldhana at redhat.com
> <mailto:Anil.Saldhana at redhat.com>> wrote:
>
>     Well explained, Jason.  I feel the JVM needs to be a true multi-tenant
>     system to be a serious contender in the multi-tenant cloud env. I doubt
>     any efforts are being made at the VM level.
>
>     On 04/23/2014 09:10 AM, Jason Greene wrote:
>      > Right. An operating system is able to segment code by using page
>     mapping and traps. Each process gets a dedicated memory area that
>     another process can?t access at a very low level (without special
>     permissions). The JVM + SM on the other hand relies on protection at
>     a higher level. Fundamentally the entire JVM memory area is shared
>     between all code. The only thing that prevents it is lots of
>     security checks on every possible method that might leak a
>     reference. So the fundamental flaw is that the SM requires a perfect
>     policy, and is essentially trust-by-default. If a developer forgets
>     to add a check, then a vulnerability is possible. This happens
>     frequently, even in the JDK itself (hence the multiple CVEs)
>      >
>      > The only way the JVM could fix this, is if it introduced real
>     multi-tenancy at the lowest levels. You would have to operate
>     similar to an OS and assign blocks of heap to a particular app, and
>     allow sharing for certain ?safe? things like code pages tied to
>     class implementations.
>      >
>      > On Apr 23, 2014, at 8:38 AM, Bill Burke <bburke at redhat.com
>     <mailto:bburke at redhat.com>> wrote:
>      >
>      >> As much as we like to think the app server is an operating
>     system, it
>      >> isn't.  The app server isn't a place where untrusted apps run.
>      >>
>      >> On 4/23/2014 8:40 AM, Josef Cacek wrote:
>      >>> Hi Arjan,
>      >>>
>      >>> let me give you few examples. Do you really want to allow
>     users/deployed-apps/3rd-party-libs
>      >>>
>      >>>   * call System.exit()?
>      >>>   * change behavior of the whole JVM by changing some system
>     properties (keystores and truststores for instance)?
>      >>>   * use reflection to read/change private data (caches, etc)?
>      >>>   * access the filesystem (e.g. rewrite the WildFly
>     configuration files)?
>      >>>   * ...
>      >>>
>      >>> If the answer is always yes, then you don't need the JSM I think.
>      >>>
>      >>> But if you care what can do the parts of code which you don't
>     have under full control, then you should really use the Java
>     Security Manager.
>      >>>
>      >>> Best regards,
>      >>>
>      >>> -- Josef
>      >>>
>      >>> ----- Original Message -----
>      >>>> From: "arjan tijms" <arjan.tijms at gmail.com
>     <mailto:arjan.tijms at gmail.com>>
>      >>>> To: "Jason T. Greene" <jgreene at redhat.com
>     <mailto:jgreene at redhat.com>>
>      >>>> Cc: wildfly-dev at lists.jboss.org
>     <mailto:wildfly-dev at lists.jboss.org>
>      >>>> Sent: Saturday, April 19, 2014 7:43:24 PM
>      >>>> Subject: Re: [wildfly-dev] my 2 cents on Security Manager
>     discussion
>      >>>>
>      >>>> Hi,
>      >>>>
>      >>>> Just wondering, but what is the primary use case for a
>     security manager
>      >>>> server side?
>      >>>>
>      >>>> While the model obviously makes sense for Applets and Webstart
>     where
>      >>>> untrusted code is executed on the user's machine, I found it
>     to be extremely
>      >>>> rare for a server to run untrusted code. In fact, I don't
>     think I've ever
>      >>>> seen this situation.
>      >>>>
>      >>>> There's maybe a case to prevent privilege escalation in case
>     of a legitimate
>      >>>> app being hacked, but in practice it doesn't look like a
>     security manager is
>      >>>> really being used a lot for that, is it? Instead the default
>     thing to do
>      >>>> there seems to be to run the AS under a user with limited
>     rights on the host
>      >>>> OS and/or use things like SELinix or Virtual Servers (e.g.
>     XEN) to isolate
>      >>>> the complete AS.
>      >>>>
>      >>>> Kind regards,
>      >>>> Arjan Tijms
>      >>>>
>     _______________________________________________
>     wildfly-dev mailing list
>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
- DML

From Anil.Saldhana at redhat.com  Thu Apr 24 12:40:14 2014
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Thu, 24 Apr 2014 11:40:14 -0500
Subject: [wildfly-dev] my 2 cents on Security Manager discussion
In-Reply-To: <CAMvdueDTh4zSEwj+PynSB-3w_kzhdi2Z39pEr7nfYVxdaVGKsQ@mail.gmail.com>
References: <5351AAE8.5010107@redhat.com>
	<5351AC23.1090903@gmail.com>	<7EC05876-28DA-44EA-8CF0-CFD5D85A37E7@redhat.com>	<CAE=-AhDGUmJKJHuv0TnDEsnfGXXNy3aWvyARr1B=Kpx9ndZc8g@mail.gmail.com>	<1966656146.15206399.1398256857398.JavaMail.zimbra@redhat.com>	<5357C260.9080005@redhat.com>	<C45EC292-C255-4676-9B58-D2B96755157B@redhat.com>	<5357E3A4.3060804@redhat.com>
	<CAMvdueDTh4zSEwj+PynSB-3w_kzhdi2Z39pEr7nfYVxdaVGKsQ@mail.gmail.com>
Message-ID: <53593E6E.2020109@redhat.com>

Thanks for your excellent observations.  Answers inline.

On 04/24/2014 02:49 AM, Przemyslaw Bielicki wrote:
> Do we really need multi-tenancy in server-side Java?
>
It may be necessary for the following reasons:
- save memory wastage (as outlined by Jason)
- lower management of resources needs that comes with single 
application/singleVM/large box combination (management of ports is a big 
issue along with IP addresses)
    * Additionally if the app is fronted by Apache/NGinx or IIS with 
some proxy capabilities, then you deal with the proxy configuration 
(rewriting for multiple IPs/port combination due to app/vm)

> We all know that Java has a serious limitation of max heap size - 16GB 
> is the max I've ever seen (used by Hadoop name node). Now, consider 
> modern commodity hardware that ships with 500GB - 1000GB of RAM. Let's 
> assume that your application's max heap usage is really 16GB and 
> another 16GB off-heap memory (in case of mentioned name node it can be 
> up to max RAM available if your application uses IO heavily and it can 
> be cached by the OS). My humble calculations let me think that on such 
> machine we can easily run 16 - 32 separate JVMs (considering RAM only, 
> CPU is another story).
>
> Knowing this, I don't think JVM can be a serious host of multi-tenant 
> applications in the cloud. I rather see JVM instance per application 
> and in such case we don't have security issues and SM is not needed. 
> If one application is dead (e.g. malicious System.exit, JVM core dump, 
> etc.) all the rest is safe.
Solving the system exit or core dump issues is really a tall order to 
climb for multi-tenant JVMs.  The complexity/work involved probably 
outweighs the benefits.

I am leaning now toward a single app/single JVM strategy.
>
>
> On Wed, Apr 23, 2014 at 6:00 PM, Anil Saldhana 
> <Anil.Saldhana at redhat.com <mailto:Anil.Saldhana at redhat.com>> wrote:
>
>     Well explained, Jason.  I feel the JVM needs to be a true multi-tenant
>     system to be a serious contender in the multi-tenant cloud env. I
>     doubt
>     any efforts are being made at the VM level.
>
>     On 04/23/2014 09:10 AM, Jason Greene wrote:
>     > Right. An operating system is able to segment code by using page
>     mapping and traps. Each process gets a dedicated memory area that
>     another process can't access at a very low level (without special
>     permissions). The JVM + SM on the other hand relies on protection
>     at a higher level. Fundamentally the entire JVM memory area is
>     shared between all code. The only thing that prevents it is lots
>     of security checks on every possible method that might leak a
>     reference. So the fundamental flaw is that the SM requires a
>     perfect policy, and is essentially trust-by-default. If a
>     developer forgets to add a check, then a vulnerability is
>     possible. This happens frequently, even in the JDK itself (hence
>     the multiple CVEs)
>     >
>     > The only way the JVM could fix this, is if it introduced real
>     multi-tenancy at the lowest levels. You would have to operate
>     similar to an OS and assign blocks of heap to a particular app,
>     and allow sharing for certain "safe" things like code pages tied
>     to class implementations.
>     >
>     > On Apr 23, 2014, at 8:38 AM, Bill Burke <bburke at redhat.com
>     <mailto:bburke at redhat.com>> wrote:
>     >
>     >> As much as we like to think the app server is an operating
>     system, it
>     >> isn't.  The app server isn't a place where untrusted apps run.
>     >>
>     >> On 4/23/2014 8:40 AM, Josef Cacek wrote:
>     >>> Hi Arjan,
>     >>>
>     >>> let me give you few examples. Do you really want to allow
>     users/deployed-apps/3rd-party-libs
>     >>>
>     >>>   * call System.exit()?
>     >>>   * change behavior of the whole JVM by changing some system
>     properties (keystores and truststores for instance)?
>     >>>   * use reflection to read/change private data (caches, etc)?
>     >>>   * access the filesystem (e.g. rewrite the WildFly
>     configuration files)?
>     >>>   * ...
>     >>>
>     >>> If the answer is always yes, then you don't need the JSM I think.
>     >>>
>     >>> But if you care what can do the parts of code which you don't
>     have under full control, then you should really use the Java
>     Security Manager.
>     >>>
>     >>> Best regards,
>     >>>
>     >>> -- Josef
>     >>>
>     >>> ----- Original Message -----
>     >>>> From: "arjan tijms" <arjan.tijms at gmail.com
>     <mailto:arjan.tijms at gmail.com>>
>     >>>> To: "Jason T. Greene" <jgreene at redhat.com
>     <mailto:jgreene at redhat.com>>
>     >>>> Cc: wildfly-dev at lists.jboss.org
>     <mailto:wildfly-dev at lists.jboss.org>
>     >>>> Sent: Saturday, April 19, 2014 7:43:24 PM
>     >>>> Subject: Re: [wildfly-dev] my 2 cents on Security Manager
>     discussion
>     >>>>
>     >>>> Hi,
>     >>>>
>     >>>> Just wondering, but what is the primary use case for a
>     security manager
>     >>>> server side?
>     >>>>
>     >>>> While the model obviously makes sense for Applets and
>     Webstart where
>     >>>> untrusted code is executed on the user's machine, I found it
>     to be extremely
>     >>>> rare for a server to run untrusted code. In fact, I don't
>     think I've ever
>     >>>> seen this situation.
>     >>>>
>     >>>> There's maybe a case to prevent privilege escalation in case
>     of a legitimate
>     >>>> app being hacked, but in practice it doesn't look like a
>     security manager is
>     >>>> really being used a lot for that, is it? Instead the default
>     thing to do
>     >>>> there seems to be to run the AS under a user with limited
>     rights on the host
>     >>>> OS and/or use things like SELinix or Virtual Servers (e.g.
>     XEN) to isolate
>     >>>> the complete AS.
>     >>>>
>     >>>> Kind regards,
>     >>>> Arjan Tijms
>     >>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140424/a4d6d20b/attachment.html 

From sstark at redhat.com  Thu Apr 24 13:13:32 2014
From: sstark at redhat.com (Scott Stark)
Date: Thu, 24 Apr 2014 13:13:32 -0400 (EDT)
Subject: [wildfly-dev] my 2 cents on Security Manager discussion
In-Reply-To: <53593E6E.2020109@redhat.com>
References: <5351AAE8.5010107@redhat.com>
	<CAE=-AhDGUmJKJHuv0TnDEsnfGXXNy3aWvyARr1B=Kpx9ndZc8g@mail.gmail.com>
	<1966656146.15206399.1398256857398.JavaMail.zimbra@redhat.com>
	<5357C260.9080005@redhat.com>
	<C45EC292-C255-4676-9B58-D2B96755157B@redhat.com>
	<5357E3A4.3060804@redhat.com>
	<CAMvdueDTh4zSEwj+PynSB-3w_kzhdi2Z39pEr7nfYVxdaVGKsQ@mail.gmail.com>
	<53593E6E.2020109@redhat.com>
Message-ID: <1009717195.1542049.1398359612507.JavaMail.zimbra@redhat.com>

Andrew Haley, Andrew Dinn and myself looked at a multi-tenat JVM solution that addressed the isolation issues using byte code level traps very much like the modern virtual machines do. It had a nice api for the user space/JVM kernel transitions, but at the end of the day, the concern over unknowable security issues relating to very low level issues such as information leakage across isolated containers due to the shared memory, classes, etc. was deemed to large of a problem for us to handle with our JVM level resources. Multiple JVMs in the cloud are a huge waste of resources that needs to be addressed to make it cost effective.

----- Original Message -----
From: "Anil Saldhana" <Anil.Saldhana at redhat.com>
To: wildfly-dev at lists.jboss.org
Sent: Thursday, April 24, 2014 9:40:14 AM
Subject: Re: [wildfly-dev] my 2 cents on Security Manager discussion

Thanks for your excellent observations. Answers inline. 

On 04/24/2014 02:49 AM, Przemyslaw Bielicki wrote: 



Do we really need multi-tenancy in server-side Java? 

It may be necessary for the following reasons: 
- save memory wastage (as outlined by Jason) 
- lower management of resources needs that comes with single application/singleVM/large box combination (management of ports is a big issue along with IP addresses) 
* Additionally if the app is fronted by Apache/NGinx or IIS with some proxy capabilities, then you deal with the proxy configuration (rewriting for multiple IPs/port combination due to app/vm) 




We all know that Java has a serious limitation of max heap size - 16GB is the max I've ever seen (used by Hadoop name node). Now, consider modern commodity hardware that ships with 500GB - 1000GB of RAM. Let's assume that your application's max heap usage is really 16GB and another 16GB off-heap memory (in case of mentioned name node it can be up to max RAM available if your application uses IO heavily and it can be cached by the OS). My humble calculations let me think that on such machine we can easily run 16 - 32 separate JVMs (considering RAM only, CPU is another story). 

Knowing this, I don't think JVM can be a serious host of multi-tenant applications in the cloud. I rather see JVM instance per application and in such case we don't have security issues and SM is not needed. If one application is dead (e.g. malicious System.exit, JVM core dump, etc.) all the rest is safe. 
Solving the system exit or core dump issues is really a tall order to climb for multi-tenant JVMs. The complexity/work involved probably outweighs the benefits. 

I am leaning now toward a single app/single JVM strategy. 





On Wed, Apr 23, 2014 at 6:00 PM, Anil Saldhana < Anil.Saldhana at redhat.com > wrote: 


Well explained, Jason. I feel the JVM needs to be a true multi-tenant 
system to be a serious contender in the multi-tenant cloud env. I doubt 
any efforts are being made at the VM level. 

On 04/23/2014 09:10 AM, Jason Greene wrote: 
> Right. An operating system is able to segment code by using page mapping and traps. Each process gets a dedicated memory area that another process can?t access at a very low level (without special permissions). The JVM + SM on the other hand relies on protection at a higher level. Fundamentally the entire JVM memory area is shared between all code. The only thing that prevents it is lots of security checks on every possible method that might leak a reference. So the fundamental flaw is that the SM requires a perfect policy, and is essentially trust-by-default. If a developer forgets to add a check, then a vulnerability is possible. This happens frequently, even in the JDK itself (hence the multiple CVEs) 
> 
> The only way the JVM could fix this, is if it introduced real multi-tenancy at the lowest levels. You would have to operate similar to an OS and assign blocks of heap to a particular app, and allow sharing for certain ?safe? things like code pages tied to class implementations. 
> 
> On Apr 23, 2014, at 8:38 AM, Bill Burke < bburke at redhat.com > wrote: 
> 
>> As much as we like to think the app server is an operating system, it 
>> isn't. The app server isn't a place where untrusted apps run. 
>> 
>> On 4/23/2014 8:40 AM, Josef Cacek wrote: 
>>> Hi Arjan, 
>>> 
>>> let me give you few examples. Do you really want to allow users/deployed-apps/3rd-party-libs 
>>> 
>>> * call System.exit()? 
>>> * change behavior of the whole JVM by changing some system properties (keystores and truststores for instance)? 
>>> * use reflection to read/change private data (caches, etc)? 
>>> * access the filesystem (e.g. rewrite the WildFly configuration files)? 
>>> * ... 
>>> 
>>> If the answer is always yes, then you don't need the JSM I think. 
>>> 
>>> But if you care what can do the parts of code which you don't have under full control, then you should really use the Java Security Manager. 
>>> 
>>> Best regards, 
>>> 
>>> -- Josef 
>>> 
>>> ----- Original Message ----- 
>>>> From: "arjan tijms" < arjan.tijms at gmail.com > 
>>>> To: "Jason T. Greene" < jgreene at redhat.com > 
>>>> Cc: wildfly-dev at lists.jboss.org 
>>>> Sent: Saturday, April 19, 2014 7:43:24 PM 
>>>> Subject: Re: [wildfly-dev] my 2 cents on Security Manager discussion 
>>>> 
>>>> Hi, 
>>>> 
>>>> Just wondering, but what is the primary use case for a security manager 
>>>> server side? 
>>>> 
>>>> While the model obviously makes sense for Applets and Webstart where 
>>>> untrusted code is executed on the user's machine, I found it to be extremely 
>>>> rare for a server to run untrusted code. In fact, I don't think I've ever 
>>>> seen this situation. 
>>>> 
>>>> There's maybe a case to prevent privilege escalation in case of a legitimate 
>>>> app being hacked, but in practice it doesn't look like a security manager is 
>>>> really being used a lot for that, is it? Instead the default thing to do 
>>>> there seems to be to run the AS under a user with limited rights on the host 
>>>> OS and/or use things like SELinix or Virtual Servers (e.g. XEN) to isolate 
>>>> the complete AS. 
>>>> 
>>>> Kind regards, 
>>>> Arjan Tijms 
>>>> 

_______________________________________________
wildfly-dev mailing list
wildfly-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev


From Anil.Saldhana at redhat.com  Thu Apr 24 13:17:16 2014
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Thu, 24 Apr 2014 12:17:16 -0500
Subject: [wildfly-dev] my 2 cents on Security Manager discussion
In-Reply-To: <1009717195.1542049.1398359612507.JavaMail.zimbra@redhat.com>
References: <5351AAE8.5010107@redhat.com>	<CAE=-AhDGUmJKJHuv0TnDEsnfGXXNy3aWvyARr1B=Kpx9ndZc8g@mail.gmail.com>	<1966656146.15206399.1398256857398.JavaMail.zimbra@redhat.com>	<5357C260.9080005@redhat.com>	<C45EC292-C255-4676-9B58-D2B96755157B@redhat.com>	<5357E3A4.3060804@redhat.com>	<CAMvdueDTh4zSEwj+PynSB-3w_kzhdi2Z39pEr7nfYVxdaVGKsQ@mail.gmail.com>	<53593E6E.2020109@redhat.com>
	<1009717195.1542049.1398359612507.JavaMail.zimbra@redhat.com>
Message-ID: <5359471C.60500@redhat.com>

Well - anytime you have shared memory - you are going to need additional 
checks/boundaries lest you have the hearbleed/openssl issue. It is a 
tall order.

On 04/24/2014 12:13 PM, Scott Stark wrote:
> Andrew Haley, Andrew Dinn and myself looked at a multi-tenat JVM solution that addressed the isolation issues using byte code level traps very much like the modern virtual machines do. It had a nice api for the user space/JVM kernel transitions, but at the end of the day, the concern over unknowable security issues relating to very low level issues such as information leakage across isolated containers due to the shared memory, classes, etc. was deemed to large of a problem for us to handle with our JVM level resources. Multiple JVMs in the cloud are a huge waste of resources that needs to be addressed to make it cost effective.
>
> ----- Original Message -----
> From: "Anil Saldhana" <Anil.Saldhana at redhat.com>
> To: wildfly-dev at lists.jboss.org
> Sent: Thursday, April 24, 2014 9:40:14 AM
> Subject: Re: [wildfly-dev] my 2 cents on Security Manager discussion
>
> Thanks for your excellent observations. Answers inline.
>
> On 04/24/2014 02:49 AM, Przemyslaw Bielicki wrote:
>
>
>
> Do we really need multi-tenancy in server-side Java?
>
> It may be necessary for the following reasons:
> - save memory wastage (as outlined by Jason)
> - lower management of resources needs that comes with single application/singleVM/large box combination (management of ports is a big issue along with IP addresses)
> * Additionally if the app is fronted by Apache/NGinx or IIS with some proxy capabilities, then you deal with the proxy configuration (rewriting for multiple IPs/port combination due to app/vm)
>
>
>
>
> We all know that Java has a serious limitation of max heap size - 16GB is the max I've ever seen (used by Hadoop name node). Now, consider modern commodity hardware that ships with 500GB - 1000GB of RAM. Let's assume that your application's max heap usage is really 16GB and another 16GB off-heap memory (in case of mentioned name node it can be up to max RAM available if your application uses IO heavily and it can be cached by the OS). My humble calculations let me think that on such machine we can easily run 16 - 32 separate JVMs (considering RAM only, CPU is another story).
>
> Knowing this, I don't think JVM can be a serious host of multi-tenant applications in the cloud. I rather see JVM instance per application and in such case we don't have security issues and SM is not needed. If one application is dead (e.g. malicious System.exit, JVM core dump, etc.) all the rest is safe.
> Solving the system exit or core dump issues is really a tall order to climb for multi-tenant JVMs. The complexity/work involved probably outweighs the benefits.
>
> I am leaning now toward a single app/single JVM strategy.
>
>
>
>
>
> On Wed, Apr 23, 2014 at 6:00 PM, Anil Saldhana < Anil.Saldhana at redhat.com > wrote:
>
>
> Well explained, Jason. I feel the JVM needs to be a true multi-tenant
> system to be a serious contender in the multi-tenant cloud env. I doubt
> any efforts are being made at the VM level.
>
> On 04/23/2014 09:10 AM, Jason Greene wrote:
>> Right. An operating system is able to segment code by using page mapping and traps. Each process gets a dedicated memory area that another process can?t access at a very low level (without special permissions). The JVM + SM on the other hand relies on protection at a higher level. Fundamentally the entire JVM memory area is shared between all code. The only thing that prevents it is lots of security checks on every possible method that might leak a reference. So the fundamental flaw is that the SM requires a perfect policy, and is essentially trust-by-default. If a developer forgets to add a check, then a vulnerability is possible. This happens frequently, even in the JDK itself (hence the multiple CVEs)
>>
>> The only way the JVM could fix this, is if it introduced real multi-tenancy at the lowest levels. You would have to operate similar to an OS and assign blocks of heap to a particular app, and allow sharing for certain ?safe? things like code pages tied to class implementations.
>>
>> On Apr 23, 2014, at 8:38 AM, Bill Burke < bburke at redhat.com > wrote:
>>
>>> As much as we like to think the app server is an operating system, it
>>> isn't. The app server isn't a place where untrusted apps run.
>>>
>>> On 4/23/2014 8:40 AM, Josef Cacek wrote:
>>>> Hi Arjan,
>>>>
>>>> let me give you few examples. Do you really want to allow users/deployed-apps/3rd-party-libs
>>>>
>>>> * call System.exit()?
>>>> * change behavior of the whole JVM by changing some system properties (keystores and truststores for instance)?
>>>> * use reflection to read/change private data (caches, etc)?
>>>> * access the filesystem (e.g. rewrite the WildFly configuration files)?
>>>> * ...
>>>>
>>>> If the answer is always yes, then you don't need the JSM I think.
>>>>
>>>> But if you care what can do the parts of code which you don't have under full control, then you should really use the Java Security Manager.
>>>>
>>>> Best regards,
>>>>
>>>> -- Josef
>>>>
>>>> ----- Original Message -----
>>>>> From: "arjan tijms" < arjan.tijms at gmail.com >
>>>>> To: "Jason T. Greene" < jgreene at redhat.com >
>>>>> Cc: wildfly-dev at lists.jboss.org
>>>>> Sent: Saturday, April 19, 2014 7:43:24 PM
>>>>> Subject: Re: [wildfly-dev] my 2 cents on Security Manager discussion
>>>>>
>>>>> Hi,
>>>>>
>>>>> Just wondering, but what is the primary use case for a security manager
>>>>> server side?
>>>>>
>>>>> While the model obviously makes sense for Applets and Webstart where
>>>>> untrusted code is executed on the user's machine, I found it to be extremely
>>>>> rare for a server to run untrusted code. In fact, I don't think I've ever
>>>>> seen this situation.
>>>>>
>>>>> There's maybe a case to prevent privilege escalation in case of a legitimate
>>>>> app being hacked, but in practice it doesn't look like a security manager is
>>>>> really being used a lot for that, is it? Instead the default thing to do
>>>>> there seems to be to run the AS under a user with limited rights on the host
>>>>> OS and/or use things like SELinix or Virtual Servers (e.g. XEN) to isolate
>>>>> the complete AS.
>>>>>
>>>>> Kind regards,
>>>>> Arjan Tijms
>>>>>
>>>>>

From rory.odonnell at oracle.com  Fri Apr 25 04:25:16 2014
From: rory.odonnell at oracle.com (Rory O'Donnell Oracle, Dublin Ireland)
Date: Fri, 25 Apr 2014 09:25:16 +0100
Subject: [wildfly-dev] Early Access builds for JDK 9 b09,
 JDK 8u20 b10 and JDK 7U60 b15 are available on java.net
Message-ID: <535A1BEC.9010904@oracle.com>

Hi Guys,

Early Access builds for JDK 9 b09 <https://jdk9.java.net/download/>, JDK 
8u20 b10 <https://jdk8.java.net/download.html> and JDK 7U60 b15 
<https://jdk7.java.net/download.html> are available on java.net.

As we enter the later phases of development for JDK 7u60 & JDK 8u20 , 
please log any show
stoppers as soon as possible.

Rgds, Rory

-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140425/e65d0685/attachment.html 

From manderse at redhat.com  Fri Apr 25 04:39:30 2014
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Fri, 25 Apr 2014 10:39:30 +0200
Subject: [wildfly-dev] any reason why ironjacamar XSD's have been
	removed ?
In-Reply-To: <02B0E649-0F40-48A3-B70C-5977B3CD2E02@redhat.com>
References: <02B0E649-0F40-48A3-B70C-5977B3CD2E02@redhat.com>
Message-ID: <D94CF78B-01C7-423E-A183-8C46E0FFF82D@redhat.com>

On 25 Apr 2014, at 10:20, Max Rydahl Andersen wrote:

> Heya,
>
> Is there a reason why https://docs.jboss.org/ironjacamar/ removed 
> their XSD's that are used in documentation and examples ?
>
> Like this: 
> https://docs.jboss.org/ironjacamar/schema/datasources_1_0.xsd
>
> Could we get them restored so you don't get 404 validation errors ?

related EAP bugzilla: 
https://bugzilla.redhat.com/show_bug.cgi?id=1045942 but this affects 
both product and project examples/documentation.

/max
http://about.me/maxandersen

From manderse at redhat.com  Fri Apr 25 04:20:18 2014
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Fri, 25 Apr 2014 10:20:18 +0200
Subject: [wildfly-dev] any reason why ironjacamar XSD's have been removed ?
Message-ID: <02B0E649-0F40-48A3-B70C-5977B3CD2E02@redhat.com>

Heya,

Is there a reason why https://docs.jboss.org/ironjacamar/ removed their 
XSD's that are used in documentation and examples ?

Like this: https://docs.jboss.org/ironjacamar/schema/datasources_1_0.xsd

Could we get them restored so you don't get 404 validation errors ?

/max
http://about.me/maxandersen

From jesper.pedersen at jboss.org  Fri Apr 25 08:14:03 2014
From: jesper.pedersen at jboss.org (Jesper Pedersen)
Date: Fri, 25 Apr 2014 08:14:03 -0400
Subject: [wildfly-dev] any reason why ironjacamar XSD's have been
 removed ?
In-Reply-To: <D94CF78B-01C7-423E-A183-8C46E0FFF82D@redhat.com>
References: <02B0E649-0F40-48A3-B70C-5977B3CD2E02@redhat.com>
	<D94CF78B-01C7-423E-A183-8C46E0FFF82D@redhat.com>
Message-ID: <535A518B.3030303@jboss.org>

Hi,

On 04/25/2014 04:39 AM, Max Rydahl Andersen wrote:
> On 25 Apr 2014, at 10:20, Max Rydahl Andersen wrote:
>> Is there a reason why https://docs.jboss.org/ironjacamar/ removed
>> their XSD's that are used in documentation and examples ?
>>
>> Like this:
>> https://docs.jboss.org/ironjacamar/schema/datasources_1_0.xsd
>>
>> Could we get them restored so you don't get 404 validation errors ?
>

Update your links to

  www.ironjacamar.org/doc/schema/

Or, feel free to create a mirror on docs.jboss.org, if you can't use the 
official site.

Best regards,
  Jesper


From manderse at redhat.com  Sun Apr 27 03:12:13 2014
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Sun, 27 Apr 2014 09:12:13 +0200
Subject: [wildfly-dev] any reason why ironjacamar XSD's have been
 removed ?
In-Reply-To: <535A518B.3030303@jboss.org>
References: <02B0E649-0F40-48A3-B70C-5977B3CD2E02@redhat.com>
	<D94CF78B-01C7-423E-A183-8C46E0FFF82D@redhat.com>
	<535A518B.3030303@jboss.org>
Message-ID: <BA89C548-0648-4E17-8E9F-E1C2E1757A34@redhat.com>

On 25 Apr 2014, at 14:14, Jesper Pedersen wrote:

> Hi,
>
> On 04/25/2014 04:39 AM, Max Rydahl Andersen wrote:
>> On 25 Apr 2014, at 10:20, Max Rydahl Andersen wrote:
>>> Is there a reason why https://docs.jboss.org/ironjacamar/ removed
>>> their XSD's that are used in documentation and examples ?
>>>
>>> Like this:
>>> https://docs.jboss.org/ironjacamar/schema/datasources_1_0.xsd
>>>
>>> Could we get them restored so you don't get 404 validation errors ?
>>
>
> Update your links to

"Your links" ? this is about the official documentation and examples :)

> www.ironjacamar.org/doc/schema/
>
> Or, feel free to create a mirror on docs.jboss.org, if you can't use 
> the
> official site.

Yeah - that is what the bugzilla and org issue is doing now.

But please let this be a lesson in how *NOT* to move urls.

Please setup redirects so your documentation, examples etc. don't 
break/don't validate
if you move them.

What is weird is why it is only recently these errors have been seen 
since the content seem
to have moved in June 2013...haven't figured out why its only started 
showing up now...

/max
http://about.me/maxandersen

From dador92 at gmail.com  Sun Apr 27 12:56:41 2014
From: dador92 at gmail.com (Jim McGuinness)
Date: Sun, 27 Apr 2014 11:56:41 -0500
Subject: [wildfly-dev] css files path
Message-ID: <CALbcAPWV+Ej=p7xQK+MNAXuH6wc2Zb+_TbFhJar4hk5jzAisBg@mail.gmail.com>

A WAR-based facelet reference a syle sheet with something like ...

<h:outputStylesheet library="css" name="default.css" />

... is supposed to send Wildfly looking in "resources/css" for the style
sheet, but instead it appears to be looking in "css". Was there a change in
the Web container specs?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140427/58783770/attachment.html 

From manderse at redhat.com  Sun Apr 27 19:38:37 2014
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Mon, 28 Apr 2014 01:38:37 +0200
Subject: [wildfly-dev] any reason why ironjacamar XSD's have been
 removed ?
In-Reply-To: <535A518B.3030303@jboss.org>
References: <02B0E649-0F40-48A3-B70C-5977B3CD2E02@redhat.com>
	<D94CF78B-01C7-423E-A183-8C46E0FFF82D@redhat.com>
	<535A518B.3030303@jboss.org>
Message-ID: <C76B64F3-249B-4BA2-B405-6A81380FEE86@redhat.com>


>>> Like this:
>>> https://docs.jboss.org/ironjacamar/schema/datasources_1_0.xsd
>>>
>>> Could we get them restored so you don't get 404 validation errors ?
>>
>
> Update your links to
>
> www.ironjacamar.org/doc/schema/
>
> Or, feel free to create a mirror on docs.jboss.org, if you can't use 
> the
> official site.

This is actual worse than original thought - it is not just a missing 
redirect.

The actual namespace changed.

Jesper - can you help with https://issues.jboss.org/browse/ORG-2023 and 
restore the content that was once at 
https://docs.jboss.org/ironjacamar/schema/* ? with the *original* 
non-changed namespace content ? (see 
https://web.archive.org/web/20130410192516/http://docs.jboss.org/ironjacamar/schema 
of the content that is missing)

Much appreciated, Thanks,
/max
http://about.me/maxandersen

p.s. why this validation errors first shows up now I cannot understand - 
its as if docs.jboss.org returned the correct content until a few days 
ago but wayback machine and the bugzilla said it happened sooner...a 
mystery.


From jperkins at redhat.com  Mon Apr 28 11:26:14 2014
From: jperkins at redhat.com (James R. Perkins)
Date: Mon, 28 Apr 2014 15:19:14 -0007
Subject: [wildfly-dev] IMPORTANT - Intermittent Test Ban Redux
In-Reply-To: <2E5793CC-BE7F-4AA1-B854-5DEE6D359E60@redhat.com>
References: <2E5793CC-BE7F-4AA1-B854-5DEE6D359E60@redhat.com>
Message-ID: <1398698774.12714.0@localhost>

+1

On Wed, Apr 23, 2014 at 3:21 PM, Jason Greene <jason.greene at redhat.com> 
wrote:
> Hi Everyone,
> 
> Almost 2 years ago we agreed to disable all intermittent tests[1]; 
> however, this is still a major problem today, and is still a major 
> hassle for everyone that submits a PR (?retest this please? is 
> now a common part of our process).
> 
> I think it?s finally time to enforce this policy, and disallow all 
> tests that lead to even occasional intermittent failures, even if 
> that leads to loss of coverage. The most fundamental need of our test 
> suite, is to catch regressions, and right now it?s not really 
> serving that purpose.
> 
> So I propose that after 8.1.0.Final is shipped that we immediately 
> disable all tests with a failing history, and create a JIRA issue for 
> the component author to fix them or the bug that is producing the 
> failure. If after 3 weeks, a JIRA issue has for this has made no 
> progress, I propose we completely remove the test from our codebase. 
> 
> In addition, I propose that any repaired test be shown to be 
> intermittent free using a custom CI job (Tomaz can set them) for 
> several runs before accepting them back in.
> 
> Thanks!
> 
> [1] 
> http://wildfly-development.1055759.n5.nabble.com/IMPORTANT-New-Policy-Proposal-No-More-Intermittent-Test-Failures-td5709984.html#a5709993
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140428/dc0aade9/attachment.html 

From smarlow at redhat.com  Mon Apr 28 11:34:07 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Mon, 28 Apr 2014 11:34:07 -0400
Subject: [wildfly-dev] 8.1.0.Final Criteria
In-Reply-To: <FEDBDE64-9D3B-4D33-ADA1-671D4BA73C84@redhat.com>
References: <FEDBDE64-9D3B-4D33-ADA1-671D4BA73C84@redhat.com>
Message-ID: <535E74EF.6070302@redhat.com>

For TCK testing, I'll focus on the separate branch until we finish 
8.1.0.Final and then switch back to master.

On 04/23/2014 06:47 PM, Jason Greene wrote:
> In order to keep the release window small, I am requesting that only blocker level fixes be allowed into 8.1.0.Final at this time. If you believe you have one, please raise the status on the Jira issue and let me know about it.
>
> We are in the process of shifting master to 9, and so these will be applied to a separate branch. Expect a further announcement on that.
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


From emartins at redhat.com  Mon Apr 28 11:54:49 2014
From: emartins at redhat.com (Eduardo Martins)
Date: Mon, 28 Apr 2014 16:54:49 +0100
Subject: [wildfly-dev] 8.1.0.Final Criteria
In-Reply-To: <FEDBDE64-9D3B-4D33-ADA1-671D4BA73C84@redhat.com>
References: <FEDBDE64-9D3B-4D33-ADA1-671D4BA73C84@redhat.com>
Message-ID: <D355AACE-40C4-499C-A288-51F7EBEF5A39@redhat.com>

I?m a bit undecided wrt https://github.com/wildfly/wildfly/pull/6208 , while the initial goal was to enhance the code wrt ee resource definitions, I end up finding and fixing several issues (see PR description) that probably should be included in 8.1.

I will raise the status of the JIRA and leave to you the final call.

?E

On 23 Apr 2014, at 23:47, Jason Greene <jason.greene at redhat.com> wrote:

> In order to keep the release window small, I am requesting that only blocker level fixes be allowed into 8.1.0.Final at this time. If you believe you have one, please raise the status on the Jira issue and let me know about it.
> 
> We are in the process of shifting master to 9, and so these will be applied to a separate branch. Expect a further announcement on that.
> 
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



From stuart.w.douglas at gmail.com  Mon Apr 28 12:01:02 2014
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Mon, 28 Apr 2014 09:01:02 -0700
Subject: [wildfly-dev] 8.1.0.Final Criteria
In-Reply-To: <D355AACE-40C4-499C-A288-51F7EBEF5A39@redhat.com>
References: <FEDBDE64-9D3B-4D33-ADA1-671D4BA73C84@redhat.com>
	<D355AACE-40C4-499C-A288-51F7EBEF5A39@redhat.com>
Message-ID: <535E7B3E.3060305@gmail.com>

I think this is too big a change for this point in the release cycle.

Stuart

Eduardo Martins wrote:
> I?m a bit undecided wrt https://github.com/wildfly/wildfly/pull/6208 , while the initial goal was to enhance the code wrt ee resource definitions, I end up finding and fixing several issues (see PR description) that probably should be included in 8.1.
>
> I will raise the status of the JIRA and leave to you the final call.
>
> ?E
>
> On 23 Apr 2014, at 23:47, Jason Greene<jason.greene at redhat.com>  wrote:
>
>> In order to keep the release window small, I am requesting that only blocker level fixes be allowed into 8.1.0.Final at this time. If you believe you have one, please raise the status on the Jira issue and let me know about it.
>>
>> We are in the process of shifting master to 9, and so these will be applied to a separate branch. Expect a further announcement on that.
>>
>> --
>> Jason T. Greene
>> WildFly Lead / JBoss EAP Platform Architect
>> JBoss, a division of Red Hat
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

From emartins at redhat.com  Mon Apr 28 12:11:17 2014
From: emartins at redhat.com (Eduardo Martins)
Date: Mon, 28 Apr 2014 17:11:17 +0100
Subject: [wildfly-dev] 8.1.0.Final Criteria
In-Reply-To: <535E7B3E.3060305@gmail.com>
References: <FEDBDE64-9D3B-4D33-ADA1-671D4BA73C84@redhat.com>
	<D355AACE-40C4-499C-A288-51F7EBEF5A39@redhat.com>
	<535E7B3E.3060305@gmail.com>
Message-ID: <9B898432-AA81-4B63-B0FE-31E7B45723D9@redhat.com>

Yes probably, would fit better for CR1 but I had no idea of these issues before.

?E

On 28 Apr 2014, at 17:01, Stuart Douglas <stuart.w.douglas at gmail.com> wrote:

> I think this is too big a change for this point in the release cycle.
> 
> Stuart
> 
> Eduardo Martins wrote:
>> I?m a bit undecided wrt https://github.com/wildfly/wildfly/pull/6208 , while the initial goal was to enhance the code wrt ee resource definitions, I end up finding and fixing several issues (see PR description) that probably should be included in 8.1.
>> 
>> I will raise the status of the JIRA and leave to you the final call.
>> 
>> ?E
>> 
>> On 23 Apr 2014, at 23:47, Jason Greene<jason.greene at redhat.com>  wrote:
>> 
>>> In order to keep the release window small, I am requesting that only blocker level fixes be allowed into 8.1.0.Final at this time. If you believe you have one, please raise the status on the Jira issue and let me know about it.
>>> 
>>> We are in the process of shifting master to 9, and so these will be applied to a separate branch. Expect a further announcement on that.
>>> 
>>> --
>>> Jason T. Greene
>>> WildFly Lead / JBoss EAP Platform Architect
>>> JBoss, a division of Red Hat
>>> 
>>> 
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> 
>> 
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev



From kustos at gmx.net  Mon Apr 28 13:46:52 2014
From: kustos at gmx.net (Philippe Marschall)
Date: Mon, 28 Apr 2014 19:46:52 +0200
Subject: [wildfly-dev] Adding timeout section to datasource management GUI
Message-ID: <535E940C.2060706@gmx.net>

Hi

We would like to have the <timeout> section from datasource 
configuration available in the web based management interface. We tried 
to implement it ourselves and then submit submit a pull request. We got 
as far as this commit [1] on github. The section and widgets show up in 
the management interface but they don't seem connected to the underlying 
values. They don't display or update the underlying values. Also the 
help does not seem to work. We're still willing to create a pull request 
should we be able to get it to work.

  [1] 
https://github.com/marschall/core/commit/89df3cb84e26ef5fc525858e3529095af5c53668

Cheers
Philippe

From hpehl at redhat.com  Tue Apr 29 03:48:24 2014
From: hpehl at redhat.com (Harald Pehl)
Date: Tue, 29 Apr 2014 09:48:24 +0200
Subject: [wildfly-dev] Adding timeout section to datasource management
	GUI
In-Reply-To: <535E940C.2060706@gmx.net>
References: <535E940C.2060706@gmx.net>
Message-ID: <3DA0B7DD-486C-4F53-9378-774807CD5D84@redhat.com>

Well done! You just missed to add the timeout properties to the AutoBean interface. See my comment on your commit [1] for all the details. 

[1] https://github.com/marschall/core/commit/89df3cb84e26ef5fc525858e3529095af5c53668#commitcomment-6151911

Cheers 
Harald

Am 28.04.2014 um 19:46 schrieb Philippe Marschall <kustos at gmx.net>:

> Hi
> 
> We would like to have the <timeout> section from datasource 
> configuration available in the web based management interface. We tried 
> to implement it ourselves and then submit submit a pull request. We got 
> as far as this commit [1] on github. The section and widgets show up in 
> the management interface but they don't seem connected to the underlying 
> values. They don't display or update the underlying values. Also the 
> help does not seem to work. We're still willing to create a pull request 
> should we be able to get it to work.
> 
>  [1] 
> https://github.com/marschall/core/commit/89df3cb84e26ef5fc525858e3529095af5c53668
> 
> Cheers
> Philippe
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

---
Harald Pehl
JBoss by Red Hat
http://hpehl.info