From eduardo.santanadasilva at gmail.com Sun Nov 1 09:46:35 2015 From: eduardo.santanadasilva at gmail.com (=?UTF-8?Q?Eduardo_Sant=C2=B4Ana_da_Silva?=) Date: Sun, 1 Nov 2015 12:46:35 -0200 Subject: [wildfly-dev] ./standalone.sh -b=192.168.1.106 -bmanagement==192.168.1.106 - WFLYCTL0013: Operation ("add") failed Message-ID: Is this a correct startup command? ./standalone.sh -b=192.168.1.106 -bmanagement==192.168.1.106 I've got the following error: wildfly-10.0.0.CR5-SNAPSHOT >>> uname -a (Mac OSX 10.9.5) Darwin orange.local 13.4.0 Darwin Kernel Version 13.4.0: Wed Mar 18 16:20:14 PDT 2015; root:xnu-2422.115.14~1/RELEASE_X86_64 x86_64 >>> java -version java version "1.8.0_05" Java(TM) SE Runtime Environment (build 1.8.0_05-b13) Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode) 12:33:44,356 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ ("core-service" => "management"), ("management-interface" => "http-interface") ]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => { "Services that were unable to start:" => [ "jboss.serverManagement.controller.management.http", "jboss.serverManagement.controller.management.http.shutdown" ], "Services that may be the cause:" => ["jboss.network.management"] }} 12:33:44,357 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ ("socket-binding-group" => "standard-sockets"), ("socket-binding" => "management-http") ]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.network.socket-binding.management-http is missing [jboss.network.management]"]} ======================================================================================================================================================== wildfly-9.0.2.Final >>>>uname -a (Rapberry pi 2) Linux strawberry 3.18.11-v7+ #781 SMP PREEMPT Tue Apr 21 18:07:59 BST 2015 armv7l GNU/Linux >>> java -version java version "1.8.0" Java(TM) SE Runtime Environment (build 1.8.0-b132) Java HotSpot(TM) Client VM (build 25.0-b70, mixed mode) 14:31:02,782 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ ("core-service" => "management"), ("management-interface" => "http-interface") ]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => { "Services that were unable to start:" => [ "jboss.serverManagement.controller.management.http", "jboss.serverManagement.controller.management.http.shutdown" ], "Services that may be the cause:" => ["jboss.network.management"] }} 14:31:02,793 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ ("socket-binding-group" => "standard-sockets"), ("socket-binding" => "management-http") ]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.binding.management-http is missing [jboss.network.management]"]} -- __________________________ Eduardo Sant'Ana da Silva - Ph.D. Researcher / IT Consultant -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151101/8df68860/attachment.html From lfugaro at redhat.com Sun Nov 1 10:34:32 2015 From: lfugaro at redhat.com (Luigi Fugaro) Date: Sun, 1 Nov 2015 10:34:32 -0500 (EST) Subject: [wildfly-dev] ./standalone.sh -b=192.168.1.106 -bmanagement==192.168.1.106 - WFLYCTL0013: Operation ("add") failed In-Reply-To: References: Message-ID: <4F8F75F7-CAA1-405F-A7B9-32AADCA61256@redhat.com> ./standalone.sh -b 192.168.1.106 -bmanagement 192.168.1.106 Inviato da iPhone > Il giorno 01 nov 2015, alle ore 15:47, Eduardo Sant?Ana da Silva ha scritto: > > Is this a correct startup command? > > ./standalone.sh -b=192.168.1.106 -bmanagement==192.168.1.106 > > > I've got the following error: > > > > wildfly-10.0.0.CR5-SNAPSHOT > >>> uname -a (Mac OSX 10.9.5) > Darwin orange.local 13.4.0 Darwin Kernel Version 13.4.0: Wed Mar 18 16:20:14 PDT 2015; root:xnu-2422.115.14~1/RELEASE_X86_64 x86_64 > > >>> java -version > java version "1.8.0_05" > Java(TM) SE Runtime Environment (build 1.8.0_05-b13) > Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode) > > > > 12:33:44,356 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > > ("core-service" => "management"), > > ("management-interface" => "http-interface") > > ]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => { > > "Services that were unable to start:" => [ > > "jboss.serverManagement.controller.management.http", > > "jboss.serverManagement.controller.management.http.shutdown" > > ], > > "Services that may be the cause:" => ["jboss.network.management"] > > }} > > 12:33:44,357 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > > ("socket-binding-group" => "standard-sockets"), > > ("socket-binding" => "management-http") > > ]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.network.socket-binding.management-http is missing [jboss.network.management]"]} > > > > ======================================================================================================================================================== > > wildfly-9.0.2.Final > >>>>uname -a (Rapberry pi 2) > Linux strawberry 3.18.11-v7+ #781 SMP PREEMPT Tue Apr 21 18:07:59 BST 2015 armv7l GNU/Linux > > >>> java -version > java version "1.8.0" > Java(TM) SE Runtime Environment (build 1.8.0-b132) > Java HotSpot(TM) Client VM (build 25.0-b70, mixed mode) > > > 14:31:02,782 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > > ("core-service" => "management"), > > ("management-interface" => "http-interface") > > ]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => { > > "Services that were unable to start:" => [ > > "jboss.serverManagement.controller.management.http", > > "jboss.serverManagement.controller.management.http.shutdown" > > ], > > "Services that may be the cause:" => ["jboss.network.management"] > > }} > > 14:31:02,793 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > > ("socket-binding-group" => "standard-sockets"), > > ("socket-binding" => "management-http") > > ]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.binding.management-http is missing [jboss.network.management]"]} > > > > > -- > __________________________ > Eduardo Sant'Ana da Silva - Ph.D. > Researcher / IT Consultant > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From eduardo.santanadasilva at gmail.com Sun Nov 1 12:39:10 2015 From: eduardo.santanadasilva at gmail.com (=?UTF-8?Q?Eduardo_Sant=C2=B4Ana_da_Silva?=) Date: Sun, 1 Nov 2015 15:39:10 -0200 Subject: [wildfly-dev] ./standalone.sh -b=192.168.1.106 -bmanagement==192.168.1.106 - WFLYCTL0013: Operation ("add") failed In-Reply-To: <4F8F75F7-CAA1-405F-A7B9-32AADCA61256@redhat.com> References: <4F8F75F7-CAA1-405F-A7B9-32AADCA61256@redhat.com> Message-ID: Ive read on documentation that both are valid and the preferable option is with = On Nov 1, 2015 1:34 PM, "Luigi Fugaro" wrote: > ./standalone.sh -b 192.168.1.106 -bmanagement 192.168.1.106 > > Inviato da iPhone > > > Il giorno 01 nov 2015, alle ore 15:47, Eduardo Sant?Ana da Silva < > eduardo.santanadasilva at gmail.com> ha scritto: > > > > Is this a correct startup command? > > > > ./standalone.sh -b=192.168.1.106 -bmanagement==192.168.1.106 > > > > > > I've got the following error: > > > > > > > > wildfly-10.0.0.CR5-SNAPSHOT > > >>> uname -a (Mac OSX 10.9.5) > > Darwin orange.local 13.4.0 Darwin Kernel Version 13.4.0: Wed Mar 18 > 16:20:14 PDT 2015; root:xnu-2422.115.14~1/RELEASE_X86_64 x86_64 > > > > >>> java -version > > java version "1.8.0_05" > > Java(TM) SE Runtime Environment (build 1.8.0_05-b13) > > Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode) > > > > > > > > 12:33:44,356 ERROR [org.jboss.as.controller.management-operation] > (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > > > > ("core-service" => "management"), > > > > ("management-interface" => "http-interface") > > > > ]) - failure description: {"WFLYCTL0288: One or more services were > unable to start due to one or more indirect dependencies not being > available." => { > > > > "Services that were unable to start:" => [ > > > > "jboss.serverManagement.controller.management.http", > > > > "jboss.serverManagement.controller.management.http.shutdown" > > > > ], > > > > "Services that may be the cause:" => ["jboss.network.management"] > > > > }} > > > > 12:33:44,357 ERROR [org.jboss.as.controller.management-operation] > (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > > > > ("socket-binding-group" => "standard-sockets"), > > > > ("socket-binding" => "management-http") > > > > ]) - failure description: {"WFLYCTL0180: Services with > missing/unavailable dependencies" => > ["org.wildfly.network.socket-binding.management-http is missing > [jboss.network.management]"]} > > > > > > > > > ======================================================================================================================================================== > > > > wildfly-9.0.2.Final > > >>>>uname -a (Rapberry pi 2) > > Linux strawberry 3.18.11-v7+ #781 SMP PREEMPT Tue Apr 21 18:07:59 BST > 2015 armv7l GNU/Linux > > > > >>> java -version > > java version "1.8.0" > > Java(TM) SE Runtime Environment (build 1.8.0-b132) > > Java HotSpot(TM) Client VM (build 25.0-b70, mixed mode) > > > > > > 14:31:02,782 ERROR [org.jboss.as.controller.management-operation] > (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > > > > ("core-service" => "management"), > > > > ("management-interface" => "http-interface") > > > > ]) - failure description: {"WFLYCTL0288: One or more services were > unable to start due to one or more indirect dependencies not being > available." => { > > > > "Services that were unable to start:" => [ > > > > "jboss.serverManagement.controller.management.http", > > > > "jboss.serverManagement.controller.management.http.shutdown" > > > > ], > > > > "Services that may be the cause:" => ["jboss.network.management"] > > > > }} > > > > 14:31:02,793 ERROR [org.jboss.as.controller.management-operation] > (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > > > > ("socket-binding-group" => "standard-sockets"), > > > > ("socket-binding" => "management-http") > > > > ]) - failure description: {"WFLYCTL0180: Services with > missing/unavailable dependencies" => ["jboss.binding.management-http is > missing [jboss.network.management]"]} > > > > > > > > > > -- > > __________________________ > > Eduardo Sant'Ana da Silva - Ph.D. > > Researcher / IT Consultant > > _______________________________________________ > > 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/20151101/a32b9d74/attachment-0001.html From jai.forums2013 at gmail.com Sun Nov 1 15:01:01 2015 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Mon, 02 Nov 2015 01:31:01 +0530 Subject: [wildfly-dev] ./standalone.sh -b=192.168.1.106 -bmanagement==192.168.1.106 - WFLYCTL0013: Operation ("add") failed In-Reply-To: References: Message-ID: <56366F7D.7090803@gmail.com> Is there anything more (like a stacktrace) in the server.log? -Jaikiran On Sunday 01 November 2015 08:16 PM, Eduardo Sant?Ana da Silva wrote: > Is this a correct startup command? > > ./standalone.sh -b=192.168.1.106 -bmanagement==192.168.1.106 > > > I've got the following error: > > > > wildfly-10.0.0.CR5-SNAPSHOT > >>> uname -a (Mac OSX 10.9.5) > Darwin orange.local 13.4.0 Darwin Kernel Version 13.4.0: Wed Mar 18 > 16:20:14 PDT 2015; root:xnu-2422.115.14~1/RELEASE_X86_64 x86_64 > > >>> java -version > java version "1.8.0_05" > Java(TM) SE Runtime Environment (build 1.8.0_05-b13) > Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode) > > > > 12:33:44,356 ERROR [org.jboss.as.controller.management-operation] > (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - > address: ([ > > ("core-service" => "management"), > > ("management-interface" => "http-interface") > > ]) - failure description: {"WFLYCTL0288: One or more services were > unable to start due to one or more indirect dependencies not being > available." => { > > "Services that were unable to start:" => [ > > "jboss.serverManagement.controller.management.http", > > "jboss.serverManagement.controller.management.http.shutdown" > > ], > > "Services that may be the cause:" => ["jboss.network.management"] > > }} > > 12:33:44,357 ERROR [org.jboss.as.controller.management-operation] > (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - > address: ([ > > ("socket-binding-group" => "standard-sockets"), > > ("socket-binding" => "management-http") > > ]) - failure description: {"WFLYCTL0180: Services with > missing/unavailable dependencies" => > ["org.wildfly.network.socket-binding.management-http is missing > [jboss.network.management]"]} > > > > ======================================================================================================================================================== > > wildfly-9.0.2.Final > >>>>uname -a (Rapberry pi 2) > Linux strawberry 3.18.11-v7+ #781 SMP PREEMPT Tue Apr 21 18:07:59 BST > 2015 armv7l GNU/Linux > > >>> java -version > java version "1.8.0" > Java(TM) SE Runtime Environment (build 1.8.0-b132) > Java HotSpot(TM) Client VM (build 25.0-b70, mixed mode) > > > 14:31:02,782 ERROR [org.jboss.as.controller.management-operation] > (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - > address: ([ > > ("core-service" => "management"), > > ("management-interface" => "http-interface") > > ]) - failure description: {"WFLYCTL0288: One or more services were > unable to start due to one or more indirect dependencies not being > available." => { > > "Services that were unable to start:" => [ > > "jboss.serverManagement.controller.management.http", > > "jboss.serverManagement.controller.management.http.shutdown" > > ], > > "Services that may be the cause:" => ["jboss.network.management"] > > }} > > 14:31:02,793 ERROR [org.jboss.as.controller.management-operation] > (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - > address: ([ > > ("socket-binding-group" => "standard-sockets"), > > ("socket-binding" => "management-http") > > ]) - failure description: {"WFLYCTL0180: Services with > missing/unavailable dependencies" => ["jboss.binding.management-http > is missing [jboss.network.management]"]} > > > > > -- > __________________________ > Eduardo Sant'Ana da Silva - Ph.D. > Researcher / IT Consultant > > > _______________________________________________ > 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/20151102/7deacc64/attachment.html From myfear at web.de Mon Nov 2 03:05:14 2015 From: myfear at web.de (Markus Eisele) Date: Mon, 2 Nov 2015 09:05:14 +0100 Subject: [wildfly-dev] Running standalone.bat on Windows gives "The syntax of the command is incorrect." Message-ID: Hi, was just trying out latest CR4 on Windows 7 and getting the following : D:\wildfly-10.0.0.CR4\bin>standalone.bat Calling "D:\wildfly-10.0.0.CR4\bin\standalone.conf.bat" The syntax of the command is incorrect. Any idea what's wrong? Cheers, Markus From hrupp at redhat.com Mon Nov 2 03:09:52 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Mon, 02 Nov 2015 09:09:52 +0100 Subject: [wildfly-dev] Running standalone.bat on Windows gives "The syntax of the command is incorrect." In-Reply-To: References: Message-ID: <50A7174F-6CE8-4DCD-A436-3BEF233547D5@redhat.com> On 2 Nov 2015, at 9:05, Markus Eisele wrote: > was just trying out latest CR4 on Windows 7 and getting the following : > > D:\wildfly-10.0.0.CR4\bin>standalone.bat > Calling "D:\wildfly-10.0.0.CR4\bin\standalone.conf.bat" Is that supposed to be called standalone or only from within standalone.bat ? From myfear at web.de Mon Nov 2 03:11:06 2015 From: myfear at web.de (Markus Eisele) Date: Mon, 2 Nov 2015 09:11:06 +0100 Subject: [wildfly-dev] Running standalone.bat on Windows gives "The syntax of the command is incorrect." In-Reply-To: <50A7174F-6CE8-4DCD-A436-3BEF233547D5@redhat.com> References: <50A7174F-6CE8-4DCD-A436-3BEF233547D5@redhat.com> Message-ID: Only from within standalone.bat. But this is what I am doing. M On 2 November 2015 at 09:09, Heiko W.Rupp wrote: > On 2 Nov 2015, at 9:05, Markus Eisele wrote: > >> was just trying out latest CR4 on Windows 7 and getting the following : >> >> D:\wildfly-10.0.0.CR4\bin>standalone.bat >> Calling "D:\wildfly-10.0.0.CR4\bin\standalone.conf.bat" > > Is that supposed to be called standalone or only from within > standalone.bat ? > From hrupp at redhat.com Mon Nov 2 03:12:23 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Mon, 02 Nov 2015 09:12:23 +0100 Subject: [wildfly-dev] Running standalone.bat on Windows gives "The syntax of the command is incorrect." In-Reply-To: References: <50A7174F-6CE8-4DCD-A436-3BEF233547D5@redhat.com> Message-ID: On 2 Nov 2015, at 9:11, Markus Eisele wrote: > Only from within standalone.bat. > > But this is what I am doing. Right, I misread. Sorry for the noise. From eduardo.santanadasilva at gmail.com Mon Nov 2 10:30:21 2015 From: eduardo.santanadasilva at gmail.com (=?UTF-8?Q?Eduardo_Sant=C2=B4Ana_da_Silva?=) Date: Mon, 2 Nov 2015 13:30:21 -0200 Subject: [wildfly-dev] ./standalone.sh -b=192.168.1.106 -bmanagement==192.168.1.106 - WFLYCTL0013: Operation ("add") failed In-Reply-To: <56366F7D.7090803@gmail.com> References: <56366F7D.7090803@gmail.com> Message-ID: My mistake, I used == instead of = ./standalone.sh -b=192.168.1.106 -bmanagement==192.168.1.106 It's working now. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151102/5c9453e9/attachment.html From tomaz.cerar at gmail.com Mon Nov 2 11:28:36 2015 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Mon, 2 Nov 2015 17:28:36 +0100 Subject: [wildfly-dev] Running standalone.bat on Windows gives "The syntax of the command is incorrect." In-Reply-To: References: Message-ID: Is that without any modifications to both of those .bat files? as i cannot reproduce this locally, running windows 10. Also does standalone.ps1 work for you? On Mon, Nov 2, 2015 at 9:05 AM, Markus Eisele wrote: > Hi, > > was just trying out latest CR4 on Windows 7 and getting the following : > > D:\wildfly-10.0.0.CR4\bin>standalone.bat > Calling "D:\wildfly-10.0.0.CR4\bin\standalone.conf.bat" > The syntax of the command is incorrect. > > Any idea what's wrong? > > Cheers, > Markus > _______________________________________________ > 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/20151102/2acdf825/attachment.html From myfear at web.de Mon Nov 2 11:31:06 2015 From: myfear at web.de (Markus Eisele) Date: Mon, 2 Nov 2015 17:31:06 +0100 Subject: [wildfly-dev] Running standalone.bat on Windows gives "The syntax of the command is incorrect." In-Reply-To: References: Message-ID: Yes. Happens the first time I unzip the distribution. If I start with defining JAVA_HOME=D:\XX without quotes and start once, everything works fine. Need to dig into this more. M On Nov 2, 2015 5:28 PM, "Toma? Cerar" wrote: > Is that without any modifications to both of those .bat files? > as i cannot reproduce this locally, running windows 10. > > Also does standalone.ps1 work for you? > > On Mon, Nov 2, 2015 at 9:05 AM, Markus Eisele wrote: > >> Hi, >> >> was just trying out latest CR4 on Windows 7 and getting the following : >> >> D:\wildfly-10.0.0.CR4\bin>standalone.bat >> Calling "D:\wildfly-10.0.0.CR4\bin\standalone.conf.bat" >> The syntax of the command is incorrect. >> >> Any idea what's wrong? >> >> Cheers, >> Markus >> _______________________________________________ >> 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/20151102/51d4647b/attachment-0001.html From jsightle at redhat.com Mon Nov 2 11:44:05 2015 From: jsightle at redhat.com (Jess Sightler) Date: Mon, 2 Nov 2015 11:44:05 -0500 Subject: [wildfly-dev] Running standalone.bat on Windows gives "The syntax of the command is incorrect." In-Reply-To: References: Message-ID: <563792D5.10102@redhat.com> Hi Markus, This sounds like a quoting error with your variable. Quoting in windows batch files should be like this: set "JAVA_HOME=c:\Path to java\jdk\" You may be setting it like this: set JAVA_HOME="c:\Path to java\jdk" In that case, the quote may become part of the value itself, which will break with many scripts. On 11/02/2015 11:31 AM, Markus Eisele wrote: > > Yes. Happens the first time I unzip the distribution. > If I start with defining JAVA_HOME=D:\XX without quotes and start > once, everything works fine. > > Need to dig into this more. > > M > > On Nov 2, 2015 5:28 PM, "Toma? Cerar" > wrote: > > Is that without any modifications to both of those .bat files? > as i cannot reproduce this locally, running windows 10. > > Also does standalone.ps1 work for you? > > On Mon, Nov 2, 2015 at 9:05 AM, Markus Eisele > wrote: > > Hi, > > was just trying out latest CR4 on Windows 7 and getting the > following : > > D:\wildfly-10.0.0.CR4\bin>standalone.bat > Calling "D:\wildfly-10.0.0.CR4\bin\standalone.conf.bat" > The syntax of the command is incorrect. > > Any idea what's wrong? > > Cheers, > Markus > _______________________________________________ > 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/20151102/fe14d9bf/attachment.html From lgao at redhat.com Tue Nov 3 03:41:01 2015 From: lgao at redhat.com (Lin Gao) Date: Tue, 3 Nov 2015 03:41:01 -0500 (EST) Subject: [wildfly-dev] Shall we limit size of the deployment in WildFly? In-Reply-To: <1327621174.2101881.1446535152401.JavaMail.zimbra@redhat.com> Message-ID: <24706283.2168206.1446540061297.JavaMail.zimbra@redhat.com> Hi, WildFly does not limit the deployment file size, users with appropriate privilege(deployer) can select any file to deploy from both CLI and web console. For the too big file, it may exhaust all available disk space, and in some cases, even small file can exhaust the disk space if the current disk space is not big enough. So shall we limit file size of the deployment in WildFly? or shall we limit the available disk space? or shall we just show a warning message to users? If we do, where in the management API configuration for this should be done, if it is done this way? Arbitrary limits will break users, so if we have an arbitrary limit it needs to be easily adjusted. In case of domain mode, different hosts may have different disk space, which means they are likely have different capacity to hold deployment files. For example, servers in server-group-A may have 2GB available disk space, servers in server-group-B may have 200MB available disk space. An unified limit for the whole domain seems not fair for the servers with more available disk space. Also, WildFly does not limit type of the deployment file, but it might need a separate discussion if necessary? Any thoughts? FYI: https://issues.jboss.org/browse/WFCORE-1057 Best Regards -- Lin Gao Software Engineer JBoss by Red Hat From david.lloyd at redhat.com Tue Nov 3 08:19:38 2015 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 3 Nov 2015 07:19:38 -0600 Subject: [wildfly-dev] Shall we limit size of the deployment in WildFly? In-Reply-To: <24706283.2168206.1446540061297.JavaMail.zimbra@redhat.com> References: <24706283.2168206.1446540061297.JavaMail.zimbra@redhat.com> Message-ID: <5638B46A.9050103@redhat.com> On 11/03/2015 02:41 AM, Lin Gao wrote: > Hi, > > WildFly does not limit the deployment file size, users with appropriate privilege(deployer) can select any file to deploy from both CLI and web console. > > For the too big file, it may exhaust all available disk space, and in some cases, even small file can exhaust the disk space if the current disk space is not big enough. > > So shall we limit file size of the deployment in WildFly? or shall we limit the available disk space? or shall we just show a warning message to users? > > If we do, where in the management API configuration for this should be done, if it is done this way? > > Arbitrary limits will break users, so if we have an arbitrary limit it needs to be easily adjusted. > > In case of domain mode, different hosts may have different disk space, which means they are likely have different capacity to hold deployment files. For example, servers in server-group-A may have 2GB available disk space, servers in server-group-B may have 200MB available disk space. An unified limit for the whole domain seems not fair for the servers with more available disk space. > > Also, WildFly does not limit type of the deployment file, but it might need a separate discussion if necessary? > > Any thoughts? Is this in response to a real observed problem? In general, if the user doesn't have space for a deployment, the deployment will fail with an error and (I am fairly certain) will delete the partial deployment. If there is space, then the deployment will succeed regardless of size. It's interesting that the JIRA you reference speaks in terms of security. If an admin wants to lock down storage space, it's probably best to do it at the operating system level using e.g. disk quotas - there are too many ways to get the application server to write arbitrary amounts of data to the file system, regardless of the presence of a security manager or any other application-level control. I'm pretty sure that if an attacker has permission to upload deployments to the server, they already essentially have control over the server. This should be an OS level concern. > FYI: https://issues.jboss.org/browse/WFCORE-1057 > > Best Regards > -- > Lin Gao > Software Engineer > JBoss by Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- - DML From hrupp at redhat.com Tue Nov 3 08:30:21 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Tue, 03 Nov 2015 14:30:21 +0100 Subject: [wildfly-dev] Shall we limit size of the deployment in WildFly? In-Reply-To: <5638B46A.9050103@redhat.com> References: <24706283.2168206.1446540061297.JavaMail.zimbra@redhat.com> <5638B46A.9050103@redhat.com> Message-ID: On 3 Nov 2015, at 14:19, David M. Lloyd wrote: > I'm pretty sure that if an attacker has permission to upload deployments > to the server, they already essentially have control over the server. Well, uploads can be remotely, so this can be seen as a DOS attack vector that does not necessarily require privileges for (physical) access like (remote) shell. And then I recall there being the zip bombs where a very small file would unzip to a huge one. This is probably nothing that could be caught by limiting the size of the upload. Do we know if WF continues to work when e.g. the partition for log files or other data is full? -- Reg. Adresse: Red Hat GmbH, Technopark II, Haus C, Werner-von-Siemens-Ring 14, D-85630 Grasbrunn Handelsregister: Amtsgericht M?nchen HRB 153243 Gesch?ftsf?hrer: Charles Cachera, Michael Cunningham, Paul Hickey, Charlie Peters -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151103/2fb6dfe4/attachment.bin From david.lloyd at redhat.com Tue Nov 3 08:36:42 2015 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 3 Nov 2015 07:36:42 -0600 Subject: [wildfly-dev] Shall we limit size of the deployment in WildFly? In-Reply-To: References: <24706283.2168206.1446540061297.JavaMail.zimbra@redhat.com> <5638B46A.9050103@redhat.com> Message-ID: <5638B86A.8010107@redhat.com> On 11/03/2015 07:30 AM, Heiko W.Rupp wrote: > On 3 Nov 2015, at 14:19, David M. Lloyd wrote: >> I'm pretty sure that if an attacker has permission to upload deployments >> to the server, they already essentially have control over the server. > > Well, uploads can be remotely, so this can be seen as a DOS > attack vector that does not necessarily require privileges > for (physical) access like (remote) shell. It does require permissions within our security framework though. I'm reasonably sure we're not letting anonymous users upload arbitrary data to the server without authorization checks. > And then I recall there being the zip bombs where a very small > file would unzip to a huge one. This is probably nothing that > could be caught by limiting the size of the upload. Sure, but this is only one of many possible attacks that you can perform if you have the ability to upload deployments to the server. Even with a locked down security manager I would never recommend running untrusted Java code on a server that isn't itself isolated and/or protected at an OS/VM level. -- - DML From darran.lofthouse at jboss.com Tue Nov 3 08:46:10 2015 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Tue, 3 Nov 2015 13:46:10 +0000 Subject: [wildfly-dev] Shall we limit size of the deployment in WildFly? In-Reply-To: References: <24706283.2168206.1446540061297.JavaMail.zimbra@redhat.com> <5638B46A.9050103@redhat.com> Message-ID: <5638BAA2.4040803@jboss.com> On 03/11/15 13:30, Heiko W.Rupp wrote: > On 3 Nov 2015, at 14:19, David M. Lloyd wrote: >> I'm pretty sure that if an attacker has permission to upload deployments >> to the server, they already essentially have control over the server. > > Well, uploads can be remotely, so this can be seen as a DOS > attack vector that does not necessarily require privileges > for (physical) access like (remote) shell. Any user performing these uploads would have an account for managing the server in the first place - and if the user has that permission there is nothing to stop their deployment from creating large files at runtime. > And then I recall there being the zip bombs where a very small > file would unzip to a huge one. This is probably nothing that > could be caught by limiting the size of the upload. > > Do we know if WF continues to work when e.g. the partition for > log files or other data is full? > > From eduardo.santanadasilva at gmail.com Tue Nov 3 09:01:51 2015 From: eduardo.santanadasilva at gmail.com (=?UTF-8?Q?Eduardo_Sant=C2=B4Ana_da_Silva?=) Date: Tue, 3 Nov 2015 12:01:51 -0200 Subject: [wildfly-dev] Shall we limit size of the deployment in WildFly? In-Reply-To: References: <24706283.2168206.1446540061297.JavaMail.zimbra@redhat.com> <5638B46A.9050103@redhat.com> Message-ID: Do we know if WF continues to work when e.g. the partition for log files or other data is full? >> You can try to down the server with a DOS like this: http://sourceforge.net/p/jmdns/bugs/130/ As far as I know the server continue to run, but nothing else on the server will be doing something useful since there is no space left. This was what I report this year: I saw single files log with more than 2.5G of information on my standalone log directory: 2015-07-20 06:53:46,024 SEVERE [javax.jmdns.impl.constants.DNSRecordType] (SocketListener(45-55-77-19.local.)) Could not find reco rd type for index: -1 2015-07-20 06:53:46,042 SEVERE [javax.jmdns.impl.DNSIncoming] (SocketListener(45-55-77-19.local.)) Could not find record type: dns [query,192.99.0.161:52050, length=184, id=0x5c78, flags=0x3030] 0: 5c7830305c783030 5c7830305c783030 5c7830305c783031 5c7830305c783030 \x00\x00 \x00\x00 \x00\x01 \x00\x00 20: 5c7830305c783030 5c7830305c783030 5c7830395c783546 5c7837335c783635 \x00\x00 \x00\x00 \x09\x5F \x73\x65 40: 5c7837325c783736 5c7836395c783633 5c7836355c783733 5c7830375c783546 \x72\x76 \x69\x63 \x65\x73 \x07\x5F 60: 5c7836345c783645 5c7837335c783244 5c7837335c783634 5c7830345c783546 \x64\x6E \x73\x2D \x73\x64 \x04\x5F 80: 5c7837355c783634 5c7837305c783035 5c7836435c783646 5c7836335c783631 \x75\x64 \x70\x05 \x6C\x6F \x63\x61 a0: 5c7836435c783030 5c7830305c783043 5c7830305c783031 \x6C\x00 \x00\x0C \x00\x01 2015-07-20 06:53:46,076 WARNING [javax.jmdns.impl.constants.DNSRecordClass] (SocketListener(45-55-77-19.local.)) Could not find re cord class for index: -1 2015-07-20 06:53:46,260 SEVERE [javax.jmdns.impl.DNSIncoming$MessageInputStream] (SocketListener(45-55-77-19.local.)) bad domain n ame: possible circular name detected. Bad offset: 0xffffffff at 0xb6 2015-07-20 06:53:46,270 SEVERE [javax.jmdns.impl.constants.DNSRecordType] (SocketListener(45-55-77-19.local.)) Could not find reco rd type for index: -1 2015-07-20 06:53:46,296 SEVERE [javax.jmdns.impl.DNSIncoming] (SocketListener(45-55-77-19.local.)) Could not find record type: dns [query,192.99.0.161:52050, length=184, id=0x5c78, flags=0x3030, questions=1 questions: [DNSQuestion at 2024648779 type: TYPE_IGNORE index 0, class: CLASS_UNKNOWN index 0, name: 0\x00\x01\x00\x00\x00\x00\x00\x00\x 09\x5F\x73\x6.\x72\x76\x69\x63\x65\x73\x07\x5F\x64\x6E\x73\x2D\x73\.4\x04\x5F\x75\x64\x70\x05\x6C\x6F\x63\x61\x6C\x00\x00\.C\x00\x 01????????????????????.]] question: [DNSQuestion at 2024648779 type: TYPE_IGNORE index 0, class: CLASS_UNKNOWN index 0, name: 0\x00\x01\x00\x00\x0 0\x00\x00\x00\x09\x5F\x73\x6.\x72\x76\x69\x63\x65\x73\x07\x5F\x64\x6E\x73\x2D\x73\.4\x04\x5F\x75\x64\x70\x05\x6C\x6F\x63\x61\x6C\x 00\x00\.C\x00\x01????????????????????.] 0: 5c7830305c783030 5c7830305c783030 5c7830305c783031 5c7830305c783030 \x00\x00 \x00\x00 \x00\x01 \x00\x00 20: 5c7830305c783030 5c7830305c783030 5c7830395c783546 5c7837335c783635 \x00\x00 \x00\x00 \x09\x5F \x73\x65 40: 5c7837325c783736 5c7836395c783633 5c7836355c783733 5c7830375c783546 \x72\x76 \x69\x63 \x65\x73 \x07\x5F 60: 5c7836345c783645 5c7837335c783244 5c7837335c783634 5c7830345c783546 \x64\x6E \x73\x2D \x73\x64 \x04\x5F 80: 5c7837355c783634 5c7837305c783035 5c7836435c783646 5c7836335c783631 \x75\x64 \x70\x05 \x6C\x6F \x63\x61 a0: 5c7836435c783030 5c7830305c783043 5c7830305c783031 \x6C\x00 \x00\x0C \x00\x01 Jason said me to use this: In the CLI do: /subsystem=logging/logger=javax.jmdns:add /subsystem=logging/logger=javax.jmdns:write-attribute(name=level,value=OFF) Or you can edit the XML and add: I think that maybe some kind of listener could be used to report on UI administration the left space when it is too small. This could be very useful, since there are a lot of masked problems that report a totally different exception since porr try/catch statements that usually report other unrelated message. 2015-11-03 11:30 GMT-02:00 Heiko W.Rupp : > On 3 Nov 2015, at 14:19, David M. Lloyd wrote: > > I'm pretty sure that if an attacker has permission to upload deployments > > to the server, they already essentially have control over the server. > > Well, uploads can be remotely, so this can be seen as a DOS > attack vector that does not necessarily require privileges > for (physical) access like (remote) shell. > > And then I recall there being the zip bombs where a very small > file would unzip to a huge one. This is probably nothing that > could be caught by limiting the size of the upload. > > Do we know if WF continues to work when e.g. the partition for > log files or other data is full? > > > -- > Reg. Adresse: Red Hat GmbH, Technopark II, Haus C, > Werner-von-Siemens-Ring 14, D-85630 Grasbrunn > Handelsregister: Amtsgericht M?nchen HRB 153243 > Gesch?ftsf?hrer: Charles Cachera, Michael Cunningham, Paul Hickey, Charlie > Peters > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- __________________________ Eduardo Sant'Ana da Silva - Dr. Pesquisador / Consultor de TI -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151103/c7c0a2a5/attachment-0001.html From lgao at redhat.com Tue Nov 3 20:13:49 2015 From: lgao at redhat.com (Lin Gao) Date: Tue, 3 Nov 2015 20:13:49 -0500 (EST) Subject: [wildfly-dev] Shall we limit size of the deployment in WildFly? In-Reply-To: <5638B46A.9050103@redhat.com> References: <24706283.2168206.1446540061297.JavaMail.zimbra@redhat.com> <5638B46A.9050103@redhat.com> Message-ID: <432170035.3201449.1446599629356.JavaMail.zimbra@redhat.com> > On 11/03/2015 02:41 AM, Lin Gao wrote: > > Hi, > > > > WildFly does not limit the deployment file size, users with appropriate > > privilege(deployer) can select any file to deploy from both CLI and web > > console. > > > > For the too big file, it may exhaust all available disk space, and in > > some cases, even small file can exhaust the disk space if the current > > disk space is not big enough. > > > > So shall we limit file size of the deployment in WildFly? or shall we > > limit the available disk space? or shall we just show a warning message > > to users? > > > > If we do, where in the management API configuration for this should be > > done, if it is done this way? > > > > Arbitrary limits will break users, so if we have an arbitrary limit it > > needs to be easily adjusted. > > > > In case of domain mode, different hosts may have different disk space, > > which means they are likely have different capacity to hold deployment > > files. For example, servers in server-group-A may have 2GB available > > disk space, servers in server-group-B may have 200MB available disk > > space. An unified limit for the whole domain seems not fair for the > > servers with more available disk space. > > > > Also, WildFly does not limit type of the deployment file, but it might > > need a separate discussion if necessary? > > > > Any thoughts? > > Is this in response to a real observed problem? Yes it is. > In general, if the user > doesn't have space for a deployment, the deployment will fail with an > error and (I am fairly certain) will delete the partial deployment. If > there is space, then the deployment will succeed regardless of size. > It's interesting that the JIRA you reference speaks in terms of > security. If an admin wants to lock down storage space, it's probably > best to do it at the operating system level using e.g. disk quotas - > there are too many ways to get the application server to write arbitrary > amounts of data to the file system, regardless of the presence of a > security manager or any other application-level control. > > I'm pretty sure that if an attacker has permission to upload deployments > to the server, they already essentially have control over the server. > This should be an OS level concern. The JIRA in question was a 'bug' related to security at first, after several rounds of discussion, it is agreed that it is not a security vulnerability, but an 'Enhancement'. The proposed requirement for the enhancement is: Provide an option in config to alert user that a) File is larger than a configurable limit b) File type is/is not valid. but it may need more discussion in community on both the requirement and design if it will be done, that is why this thread comes out in first place. :-) > > FYI: https://issues.jboss.org/browse/WFCORE-1057 > > Best Regards -- Lin Gao Software Engineer JBoss by Red Hat From darran.lofthouse at jboss.com Wed Nov 4 04:11:13 2015 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Wed, 4 Nov 2015 09:11:13 +0000 Subject: [wildfly-dev] Shall we limit size of the deployment in WildFly? In-Reply-To: <432170035.3201449.1446599629356.JavaMail.zimbra@redhat.com> References: <24706283.2168206.1446540061297.JavaMail.zimbra@redhat.com> <5638B46A.9050103@redhat.com> <432170035.3201449.1446599629356.JavaMail.zimbra@redhat.com> Message-ID: <5639CBB1.5050805@jboss.com> From within GWT is there any option to detect the file size before uploading? I wonder if it is better if we had something where we ask the server "Can you accept a file of size X?" before commencing an upload rather than setting some arbitrary limit. Something like that could also be used in domain mode before deployments are distributed allowing them to fail early. You may have 8Gb free on your disk and have 2Gb deployments, after a couple of deployments the space would be gone but the arbitrary value would still allow 2Gb uploads. Regards, Darran Lofthouse. On 04/11/15 01:13, Lin Gao wrote: >> On 11/03/2015 02:41 AM, Lin Gao wrote: >>> Hi, >>> >>> WildFly does not limit the deployment file size, users with appropriate >>> privilege(deployer) can select any file to deploy from both CLI and web >>> console. >>> >>> For the too big file, it may exhaust all available disk space, and in >>> some cases, even small file can exhaust the disk space if the current >>> disk space is not big enough. >>> >>> So shall we limit file size of the deployment in WildFly? or shall we >>> limit the available disk space? or shall we just show a warning message >>> to users? >>> >>> If we do, where in the management API configuration for this should be >>> done, if it is done this way? >>> >>> Arbitrary limits will break users, so if we have an arbitrary limit it >>> needs to be easily adjusted. >>> >>> In case of domain mode, different hosts may have different disk space, >>> which means they are likely have different capacity to hold deployment >>> files. For example, servers in server-group-A may have 2GB available >>> disk space, servers in server-group-B may have 200MB available disk >>> space. An unified limit for the whole domain seems not fair for the >>> servers with more available disk space. >>> >>> Also, WildFly does not limit type of the deployment file, but it might >>> need a separate discussion if necessary? >>> >>> Any thoughts? >> >> Is this in response to a real observed problem? > > Yes it is. > >> In general, if the user >> doesn't have space for a deployment, the deployment will fail with an >> error and (I am fairly certain) will delete the partial deployment. If >> there is space, then the deployment will succeed regardless of size. > >> It's interesting that the JIRA you reference speaks in terms of >> security. If an admin wants to lock down storage space, it's probably >> best to do it at the operating system level using e.g. disk quotas - >> there are too many ways to get the application server to write arbitrary >> amounts of data to the file system, regardless of the presence of a >> security manager or any other application-level control. >> >> I'm pretty sure that if an attacker has permission to upload deployments >> to the server, they already essentially have control over the server. >> This should be an OS level concern. > > The JIRA in question was a 'bug' related to security at first, after several > rounds of discussion, it is agreed that it is not a security vulnerability, but > an 'Enhancement'. > > The proposed requirement for the enhancement is: > > Provide an option in config to alert user that > a) File is larger than a configurable limit > b) File type is/is not valid. > > but it may need more discussion in community on both the requirement and design > if it will be done, that is why this thread comes out in first place. :-) > >>> FYI: https://issues.jboss.org/browse/WFCORE-1057 >>> > > Best Regards > -- > Lin Gao > Software Engineer > JBoss by 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 Wed Nov 4 04:26:33 2015 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Wed, 04 Nov 2015 09:26:33 +0000 Subject: [wildfly-dev] Shall we limit size of the deployment in WildFly? In-Reply-To: <5639CBB1.5050805@jboss.com> References: <24706283.2168206.1446540061297.JavaMail.zimbra@redhat.com> <5638B46A.9050103@redhat.com> <432170035.3201449.1446599629356.JavaMail.zimbra@redhat.com> <5639CBB1.5050805@jboss.com> Message-ID: Is this actually a real world problem that users are running into? If not then adding any kind of limit seems like it has the potential to cause more problems than it will solve. As others have pointed out I think the security angle is moot, as if you can deploy to the server your deployment can DOS the server in any number of ways, security manager or no security manager (the simplest way is just to put while(true){} in a Servlet then send some requests, after a while you will lock up every web thread and use 100% CPU, and there is no way to configure the security manager to stop this). Stuart On Wed, 4 Nov 2015 at 20:12 Darran Lofthouse wrote: > From within GWT is there any option to detect the file size before > uploading? > > I wonder if it is better if we had something where we ask the server > "Can you accept a file of size X?" before commencing an upload rather > than setting some arbitrary limit. Something like that could also be > used in domain mode before deployments are distributed allowing them to > fail early. > > You may have 8Gb free on your disk and have 2Gb deployments, after a > couple of deployments the space would be gone but the arbitrary value > would still allow 2Gb uploads. > > Regards, > Darran Lofthouse. > > > On 04/11/15 01:13, Lin Gao wrote: > >> On 11/03/2015 02:41 AM, Lin Gao wrote: > >>> Hi, > >>> > >>> WildFly does not limit the deployment file size, users with > appropriate > >>> privilege(deployer) can select any file to deploy from both CLI > and web > >>> console. > >>> > >>> For the too big file, it may exhaust all available disk space, and > in > >>> some cases, even small file can exhaust the disk space if the > current > >>> disk space is not big enough. > >>> > >>> So shall we limit file size of the deployment in WildFly? or shall > we > >>> limit the available disk space? or shall we just show a warning > message > >>> to users? > >>> > >>> If we do, where in the management API configuration for this > should be > >>> done, if it is done this way? > >>> > >>> Arbitrary limits will break users, so if we have an arbitrary > limit it > >>> needs to be easily adjusted. > >>> > >>> In case of domain mode, different hosts may have different disk > space, > >>> which means they are likely have different capacity to hold > deployment > >>> files. For example, servers in server-group-A may have 2GB > available > >>> disk space, servers in server-group-B may have 200MB available disk > >>> space. An unified limit for the whole domain seems not fair for the > >>> servers with more available disk space. > >>> > >>> Also, WildFly does not limit type of the deployment file, but it > might > >>> need a separate discussion if necessary? > >>> > >>> Any thoughts? > >> > >> Is this in response to a real observed problem? > > > > Yes it is. > > > >> In general, if the user > >> doesn't have space for a deployment, the deployment will fail with an > >> error and (I am fairly certain) will delete the partial deployment. If > >> there is space, then the deployment will succeed regardless of size. > > > >> It's interesting that the JIRA you reference speaks in terms of > >> security. If an admin wants to lock down storage space, it's probably > >> best to do it at the operating system level using e.g. disk quotas - > >> there are too many ways to get the application server to write arbitrary > >> amounts of data to the file system, regardless of the presence of a > >> security manager or any other application-level control. > >> > >> I'm pretty sure that if an attacker has permission to upload deployments > >> to the server, they already essentially have control over the server. > >> This should be an OS level concern. > > > > The JIRA in question was a 'bug' related to security at first, after > several > > rounds of discussion, it is agreed that it is not a security > vulnerability, but > > an 'Enhancement'. > > > > The proposed requirement for the enhancement is: > > > > Provide an option in config to alert user that > > a) File is larger than a configurable limit > > b) File type is/is not valid. > > > > but it may need more discussion in community on both the requirement and > design > > if it will be done, that is why this thread comes out in first place. :-) > > > >>> FYI: https://issues.jboss.org/browse/WFCORE-1057 > >>> > > > > Best Regards > > -- > > Lin Gao > > Software Engineer > > JBoss by 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151104/c7a78e93/attachment.html From arjan.tijms at gmail.com Wed Nov 4 04:37:49 2015 From: arjan.tijms at gmail.com (arjan tijms) Date: Wed, 4 Nov 2015 10:37:49 +0100 Subject: [wildfly-dev] Adding additional security domain to standalone.xml? In-Reply-To: References: Message-ID: Hi, On Fri, Oct 30, 2015 at 10:19 AM, arjan tijms wrote: > I wonder if it would make sense to put the generic jaspic security domain > by default in standalone.xml. It's always the same anyway. With the domain > present in a stock WildFly it's much easier for people to start with JASPIC > on WildFly. > Anyone has any thoughts on this? WildFly currently has one of the best JASPIC implementations out there, but this relatively tiny problem is a big hurdle for usability, and especially impedes using WildFly for JSR 375 demonstrations. Hope something can be done here. Kind regards, Arjan Tijms > > It concerns this fragment: > > > > > > > > > > > Kind regards, > Arjan Tijms > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151104/71b5a674/attachment-0001.html From darran.lofthouse at jboss.com Wed Nov 4 04:40:22 2015 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Wed, 4 Nov 2015 09:40:22 +0000 Subject: [wildfly-dev] Adding additional security domain to standalone.xml? In-Reply-To: References: Message-ID: <5639D286.3070401@jboss.com> I will have a look at what we can do, as we are transitioning to Elytron long term we should be aiming to avoid all workarounds like this. On 04/11/15 09:37, arjan tijms wrote: > Hi, > > On Fri, Oct 30, 2015 at 10:19 AM, arjan tijms > wrote: > > I wonder if it would make sense to put the generic jaspic security > domain by default in standalone.xml. It's always the same anyway. > With the domain present in a stock WildFly it's much easier for > people to start with JASPIC on WildFly. > > > Anyone has any thoughts on this? > > WildFly currently has one of the best JASPIC implementations out there, > but this relatively tiny problem is a big hurdle for usability, and > especially impedes using WildFly for JSR 375 demonstrations. > > Hope something can be done here. > > Kind regards, > Arjan Tijms > > > > > It concerns this fragment: > > > > > > > > > > > Kind regards, > Arjan Tijms > > From arjan.tijms at gmail.com Wed Nov 4 04:57:12 2015 From: arjan.tijms at gmail.com (arjan tijms) Date: Wed, 4 Nov 2015 10:57:12 +0100 Subject: [wildfly-dev] Adding additional security domain to standalone.xml? In-Reply-To: <5639D286.3070401@jboss.com> References: <5639D286.3070401@jboss.com> Message-ID: Thanks a lot in advance! Any idea on the Elytron timeline btw? Is that post EAP 7 or earlier? Kind regards, Arjan Tijms On Wed, Nov 4, 2015 at 10:40 AM, Darran Lofthouse < darran.lofthouse at jboss.com> wrote: > I will have a look at what we can do, as we are transitioning to Elytron > long term we should be aiming to avoid all workarounds like this. > > > On 04/11/15 09:37, arjan tijms wrote: > >> Hi, >> >> On Fri, Oct 30, 2015 at 10:19 AM, arjan tijms > > wrote: >> >> I wonder if it would make sense to put the generic jaspic security >> domain by default in standalone.xml. It's always the same anyway. >> With the domain present in a stock WildFly it's much easier for >> people to start with JASPIC on WildFly. >> >> >> Anyone has any thoughts on this? >> >> WildFly currently has one of the best JASPIC implementations out there, >> but this relatively tiny problem is a big hurdle for usability, and >> especially impedes using WildFly for JSR 375 demonstrations. >> >> Hope something can be done here. >> >> Kind regards, >> Arjan Tijms >> >> >> >> >> It concerns this fragment: >> >> >> >> >> >> >> >> >> >> >> Kind regards, >> Arjan Tijms >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151104/380c91e2/attachment.html From hbraun at redhat.com Wed Nov 4 05:35:58 2015 From: hbraun at redhat.com (Heiko Braun) Date: Wed, 4 Nov 2015 11:35:58 +0100 Subject: [wildfly-dev] Shall we limit size of the deployment in WildFly? In-Reply-To: <5639CBB1.5050805@jboss.com> References: <24706283.2168206.1446540061297.JavaMail.zimbra@redhat.com> <5638B46A.9050103@redhat.com> <432170035.3201449.1446599629356.JavaMail.zimbra@redhat.com> <5639CBB1.5050805@jboss.com> Message-ID: <5874D840-F955-41D1-A617-DECD1498CF64@redhat.com> GWT boils down to plain web technologies. And no, AFAIKT there is no way to check the size of an uploaded file across web browsers. Most browsers do however have an implicit limitation on the file size, which for majority is about 2 GB. > On 04 Nov 2015, at 10:11, Darran Lofthouse wrote: > > From within GWT is there any option to detect the file size before > uploading? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151104/9ddf94d7/attachment.html From darran.lofthouse at jboss.com Wed Nov 4 05:40:01 2015 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Wed, 4 Nov 2015 10:40:01 +0000 Subject: [wildfly-dev] Shall we limit size of the deployment in WildFly? In-Reply-To: <5874D840-F955-41D1-A617-DECD1498CF64@redhat.com> References: <24706283.2168206.1446540061297.JavaMail.zimbra@redhat.com> <5638B46A.9050103@redhat.com> <432170035.3201449.1446599629356.JavaMail.zimbra@redhat.com> <5639CBB1.5050805@jboss.com> <5874D840-F955-41D1-A617-DECD1498CF64@redhat.com> Message-ID: <5639E081.4040800@jboss.com> Haven't checked uploads for a while, do we support chunked encoding or always send a content length? On 04/11/15 10:35, Heiko Braun wrote: > GWT boils down to plain web technologies. And no, AFAIKT there is no > way to check the size of an uploaded file across web browsers. Most > browsers do however have an implicit limitation on the file size, which > for majority is about 2 GB. > >> On 04 Nov 2015, at 10:11, Darran Lofthouse > > wrote: >> >> From within GWT is there any option to detect the file size before >> uploading? > From stuart.w.douglas at gmail.com Wed Nov 4 05:42:08 2015 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Wed, 04 Nov 2015 10:42:08 +0000 Subject: [wildfly-dev] Shall we limit size of the deployment in WildFly? In-Reply-To: <5639E081.4040800@jboss.com> References: <24706283.2168206.1446540061297.JavaMail.zimbra@redhat.com> <5638B46A.9050103@redhat.com> <432170035.3201449.1446599629356.JavaMail.zimbra@redhat.com> <5639CBB1.5050805@jboss.com> <5874D840-F955-41D1-A617-DECD1498CF64@redhat.com> <5639E081.4040800@jboss.com> Message-ID: Undertow supports chunked request encoding, so if a client sends a chunked request it will handle it, however AFAIK all browsers will set a content length when uploading a file. Stuart On Wed, 4 Nov 2015 at 21:40 Darran Lofthouse wrote: > Haven't checked uploads for a while, do we support chunked encoding or > always send a content length? > > On 04/11/15 10:35, Heiko Braun wrote: > > GWT boils down to plain web technologies. And no, AFAIKT there is no > > way to check the size of an uploaded file across web browsers. Most > > browsers do however have an implicit limitation on the file size, which > > for majority is about 2 GB. > > > >> On 04 Nov 2015, at 10:11, Darran Lofthouse >> > wrote: > >> > >> From within GWT is there any option to detect the file size before > >> uploading? > > > _______________________________________________ > 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/20151104/882d45b8/attachment.html From eduardo.santanadasilva at gmail.com Wed Nov 4 05:43:13 2015 From: eduardo.santanadasilva at gmail.com (=?UTF-8?Q?Eduardo_Sant=C2=B4Ana_da_Silva?=) Date: Wed, 4 Nov 2015 08:43:13 -0200 Subject: [wildfly-dev] Adding additional security domain to standalone.xml? In-Reply-To: References: <5639D286.3070401@jboss.com> Message-ID: Probably EAP 7.1 according to the latest info that I've got on elytron hipchat. >>>>>>>>>>> Sorry by bother you guys, but what is the target distribution of the elytron, replacing JAAS among the other authentication methods? Darran Lofthouse?10:06 AM By using names I could even see us providing organisations a way to coordinate transitioning users passwords David M. Lloyd?10:07 AM or even having different passwords for different situations Darran Lofthouse?10:12 AM Elytron replaces JAAS as the integration point with the backing store of identities, in addition to that is also provides a set of strong authenitcation mechanisms for both HTTP and native access - other features will be identity propagation of identities between processes and a general imporovement of overall security context handling. Here is the follow up issue for getCredentialSupport https://issues.jboss.org/browse/ELY-299 Eduardo Sant'Ana da Silva?10:14 AM I saw that it will be on EAP 7 as well, thanks for the information David M. Lloyd?10:15 AM EAP 7.1 probably, but yes 2015-11-04 7:57 GMT-02:00 arjan tijms : > Thanks a lot in advance! > > Any idea on the Elytron timeline btw? Is that post EAP 7 or earlier? > > Kind regards, > Arjan Tijms > > On Wed, Nov 4, 2015 at 10:40 AM, Darran Lofthouse < > darran.lofthouse at jboss.com> wrote: > >> I will have a look at what we can do, as we are transitioning to Elytron >> long term we should be aiming to avoid all workarounds like this. >> >> >> On 04/11/15 09:37, arjan tijms wrote: >> >>> Hi, >>> >>> On Fri, Oct 30, 2015 at 10:19 AM, arjan tijms >> > wrote: >>> >>> I wonder if it would make sense to put the generic jaspic security >>> domain by default in standalone.xml. It's always the same anyway. >>> With the domain present in a stock WildFly it's much easier for >>> people to start with JASPIC on WildFly. >>> >>> >>> Anyone has any thoughts on this? >>> >>> WildFly currently has one of the best JASPIC implementations out there, >>> but this relatively tiny problem is a big hurdle for usability, and >>> especially impedes using WildFly for JSR 375 demonstrations. >>> >>> Hope something can be done here. >>> >>> Kind regards, >>> Arjan Tijms >>> >>> >>> >>> >>> It concerns this fragment: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Kind regards, >>> Arjan Tijms >>> >>> >>> > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- __________________________ Eduardo Sant'Ana da Silva - Dr. Pesquisador / Consultor de TI -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151104/bc7fab64/attachment-0001.html From jason.greene at redhat.com Wed Nov 4 07:29:09 2015 From: jason.greene at redhat.com (Jason T. Greene) Date: Wed, 4 Nov 2015 07:29:09 -0500 (EST) Subject: [wildfly-dev] Shall we limit size of the deployment in WildFly? In-Reply-To: <5874D840-F955-41D1-A617-DECD1498CF64@redhat.com> References: <24706283.2168206.1446540061297.JavaMail.zimbra@redhat.com> <5638B46A.9050103@redhat.com> <432170035.3201449.1446599629356.JavaMail.zimbra@redhat.com> <5639CBB1.5050805@jboss.com> <5874D840-F955-41D1-A617-DECD1498CF64@redhat.com> Message-ID: > On Nov 4, 2015, at 4:36 AM, Heiko Braun wrote: > > GWT boils down to plain web technologies. And no, AFAIKT there is no way to check the size of an uploaded file across web browsers. Most browsers do however have an implicit limitation on the file size, which for majority is about 2 GB. You can now that we have switched to XHR to do the upload. The File object returned from a file list has a size property that you can use. So you could in theory check that there is available space before posting, however, since as Stuart mentions, browsers set a content length, the server knows it anyway so it's less racy checking at the server level, if one was to check. > >> On 04 Nov 2015, at 10:11, Darran Lofthouse wrote: >> >> From within GWT is there any option to detect the file size before >> uploading? > > _______________________________________________ > 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/20151104/e5d96738/attachment.html From jason.greene at redhat.com Wed Nov 4 07:37:39 2015 From: jason.greene at redhat.com (Jason T. Greene) Date: Wed, 4 Nov 2015 07:37:39 -0500 (EST) Subject: [wildfly-dev] Shall we limit size of the deployment in WildFly? In-Reply-To: <432170035.3201449.1446599629356.JavaMail.zimbra@redhat.com> References: <24706283.2168206.1446540061297.JavaMail.zimbra@redhat.com> <5638B46A.9050103@redhat.com> <432170035.3201449.1446599629356.JavaMail.zimbra@redhat.com> Message-ID: <556E0C61-5F39-4557-B640-4035474E8563@redhat.com> On Nov 3, 2015, at 7:14 PM, Lin Gao wrote: >>> On 11/03/2015 02:41 AM, Lin Gao wrote: >>> Hi, >>> >>> WildFly does not limit the deployment file size, users with appropriate >>> privilege(deployer) can select any file to deploy from both CLI and web >>> console. >>> >>> For the too big file, it may exhaust all available disk space, and in >>> some cases, even small file can exhaust the disk space if the current >>> disk space is not big enough. >>> >>> So shall we limit file size of the deployment in WildFly? or shall we >>> limit the available disk space? or shall we just show a warning message >>> to users? >>> >>> If we do, where in the management API configuration for this should be >>> done, if it is done this way? >>> >>> Arbitrary limits will break users, so if we have an arbitrary limit it >>> needs to be easily adjusted. >>> >>> In case of domain mode, different hosts may have different disk space, >>> which means they are likely have different capacity to hold deployment >>> files. For example, servers in server-group-A may have 2GB available >>> disk space, servers in server-group-B may have 200MB available disk >>> space. An unified limit for the whole domain seems not fair for the >>> servers with more available disk space. >>> >>> Also, WildFly does not limit type of the deployment file, but it might >>> need a separate discussion if necessary? >>> >>> Any thoughts? >> >> Is this in response to a real observed problem? > > Yes it is. My understanding was that this was reported by a user but it was reported as something they were concerned with, and not actually something that was occurring in their environment. I agree with David that disk quotas on the processing running the app server is the most appropriate solution to prevent interference with other processes. I do not think we should have a hard coded limit as a constant because that will prevent legit deployments from working, and you can still run out of disk space (e.g you have 20k left and you upload a 21k deployment, which is under 1G) We could have an extra check that verifies enough disk space in the add content management op, however Java does not give us access to quota information so the best we could do is only verify available disk space (unless we exec a command for every platform we support). IMO this one is pretty low priority, but perhaps those that monitor this list see it as a need. If so can you speak up? > >> In general, if the user >> doesn't have space for a deployment, the deployment will fail with an >> error and (I am fairly certain) will delete the partial deployment. If >> there is space, then the deployment will succeed regardless of size. > >> It's interesting that the JIRA you reference speaks in terms of >> security. If an admin wants to lock down storage space, it's probably >> best to do it at the operating system level using e.g. disk quotas - >> there are too many ways to get the application server to write arbitrary >> amounts of data to the file system, regardless of the presence of a >> security manager or any other application-level control. >> >> I'm pretty sure that if an attacker has permission to upload deployments >> to the server, they already essentially have control over the server. >> This should be an OS level concern. > > The JIRA in question was a 'bug' related to security at first, after several > rounds of discussion, it is agreed that it is not a security vulnerability, but > an 'Enhancement'. > > The proposed requirement for the enhancement is: > > Provide an option in config to alert user that > a) File is larger than a configurable limit > b) File type is/is not valid. > > but it may need more discussion in community on both the requirement and design > if it will be done, that is why this thread comes out in first place. :-) > >>> FYI: https://issues.jboss.org/browse/WFCORE-1057 > > Best Regards > -- > Lin Gao > Software Engineer > JBoss by Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From brian.stansberry at redhat.com Wed Nov 4 08:26:56 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 4 Nov 2015 07:26:56 -0600 Subject: [wildfly-dev] Limit type of the deployment in WildFly? In-Reply-To: <24706283.2168206.1446540061297.JavaMail.zimbra@redhat.com> References: <24706283.2168206.1446540061297.JavaMail.zimbra@redhat.com> Message-ID: <563A07A0.80301@redhat.com> On 11/3/15 2:41 AM, Lin Gao wrote: > > Also, WildFly does not limit type of the deployment file, but it might need a separate discussion if necessary? It's a very different thing, so a separate branch of the thread is appropriate. I don't see the file type thing as being a security issue, since deployments are just bits to WildFly unless one of our deployment unit processors recognizes the deployment type. Enforcing file types just helps prevent users trying to deploy the wrong file. Doing this would require forcing all extensions to register expected file types with the kernel. This probably wouldn't be that big of a deal for extensions that are part of WildFly itself, but it would be a breaking change for any externally developed extensions that use different file extensions. It doesn't seem worth it to me, given the long list of things we have to work on. By "file types" here, I mean file extension. If checking for a particular file structure is meant (e.g. the file structures named by media type suffixes in https://tools.ietf.org/html/rfc6839) then that's a significantly different requirement that needs clarification. -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From jason.greene at redhat.com Wed Nov 4 08:41:36 2015 From: jason.greene at redhat.com (Jason T. Greene) Date: Wed, 4 Nov 2015 08:41:36 -0500 (EST) Subject: [wildfly-dev] Shall we limit size of the deployment in WildFly? In-Reply-To: <556E0C61-5F39-4557-B640-4035474E8563@redhat.com> References: <24706283.2168206.1446540061297.JavaMail.zimbra@redhat.com> <5638B46A.9050103@redhat.com> <432170035.3201449.1446599629356.JavaMail.zimbra@redhat.com> <556E0C61-5F39-4557-B640-4035474E8563@redhat.com> Message-ID: > On Nov 4, 2015, at 6:48 AM, Jason T. Greene wrote: > > I do not think we should have a hard coded limit as a constant because that will prevent legit deployments from working, and you can still run out of disk space (e.g you have 20k left and you upload a 21k deployment, which is under 1G) > > We could have an extra check that verifies enough disk space in the add content management op, however Java does not give us access to quota information so the best we could do is only verify available disk space (unless we exec a command for every platform we support). One thing I forgot to get into was domain mode. Runtime verification is straight forward on standalone, but on domain mode the deployment is pulled by arbitrary hosts, which each may have varying disk capacity. So in the host case we can only error later on and after the fact. Hosts try to pull down content in the content repository (where deployments are stored) only when they need them, and this can happen well after a deployment is added. As an example, 3 weeks later you could add a server to a host that's in a server group that requires a download of a deployment, and at that point go over capacity. From darran.lofthouse at jboss.com Wed Nov 4 08:50:22 2015 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Wed, 4 Nov 2015 13:50:22 +0000 Subject: [wildfly-dev] Shall we limit size of the deployment in WildFly? In-Reply-To: References: <24706283.2168206.1446540061297.JavaMail.zimbra@redhat.com> <5638B46A.9050103@redhat.com> <432170035.3201449.1446599629356.JavaMail.zimbra@redhat.com> <5639CBB1.5050805@jboss.com> Message-ID: <563A0D1E.9000704@jboss.com> +1 That is why I am thinking if any check is needed can it be a meaningful check such as "Is there room to store the file I am about to upload" rather than some arbitrary value which will be wrong for someone and as I point out even if you allow a large value that still does not actually solve the problem. On 04/11/15 09:26, Stuart Douglas wrote: > Is this actually a real world problem that users are running into? > > If not then adding any kind of limit seems like it has the potential to > cause more problems than it will solve. > > As others have pointed out I think the security angle is moot, as if you > can deploy to the server your deployment can DOS the server in any > number of ways, security manager or no security manager (the simplest > way is just to put while(true){} in a Servlet then send some requests, > after a while you will lock up every web thread and use 100% CPU, and > there is no way to configure the security manager to stop this). > > Stuart > > On Wed, 4 Nov 2015 at 20:12 Darran Lofthouse > wrote: > > From within GWT is there any option to detect the file size before > uploading? > > I wonder if it is better if we had something where we ask the server > "Can you accept a file of size X?" before commencing an upload rather > than setting some arbitrary limit. Something like that could also be > used in domain mode before deployments are distributed allowing them to > fail early. > > You may have 8Gb free on your disk and have 2Gb deployments, after a > couple of deployments the space would be gone but the arbitrary value > would still allow 2Gb uploads. > > Regards, > Darran Lofthouse. > > > On 04/11/15 01:13, Lin Gao wrote: > >> On 11/03/2015 02:41 AM, Lin Gao wrote: > >>> Hi, > >>> > >>> WildFly does not limit the deployment file size, users with > appropriate > >>> privilege(deployer) can select any file to deploy from both > CLI and web > >>> console. > >>> > >>> For the too big file, it may exhaust all available disk > space, and in > >>> some cases, even small file can exhaust the disk space if > the current > >>> disk space is not big enough. > >>> > >>> So shall we limit file size of the deployment in WildFly? > or shall we > >>> limit the available disk space? or shall we just show a > warning message > >>> to users? > >>> > >>> If we do, where in the management API configuration for > this should be > >>> done, if it is done this way? > >>> > >>> Arbitrary limits will break users, so if we have an > arbitrary limit it > >>> needs to be easily adjusted. > >>> > >>> In case of domain mode, different hosts may have different > disk space, > >>> which means they are likely have different capacity to hold > deployment > >>> files. For example, servers in server-group-A may have 2GB > available > >>> disk space, servers in server-group-B may have 200MB > available disk > >>> space. An unified limit for the whole domain seems not fair > for the > >>> servers with more available disk space. > >>> > >>> Also, WildFly does not limit type of the deployment file, > but it might > >>> need a separate discussion if necessary? > >>> > >>> Any thoughts? > >> > >> Is this in response to a real observed problem? > > > > Yes it is. > > > >> In general, if the user > >> doesn't have space for a deployment, the deployment will fail > with an > >> error and (I am fairly certain) will delete the partial > deployment. If > >> there is space, then the deployment will succeed regardless of size. > > > >> It's interesting that the JIRA you reference speaks in terms of > >> security. If an admin wants to lock down storage space, it's > probably > >> best to do it at the operating system level using e.g. disk quotas - > >> there are too many ways to get the application server to write > arbitrary > >> amounts of data to the file system, regardless of the presence of a > >> security manager or any other application-level control. > >> > >> I'm pretty sure that if an attacker has permission to upload > deployments > >> to the server, they already essentially have control over the > server. > >> This should be an OS level concern. > > > > The JIRA in question was a 'bug' related to security at first, > after several > > rounds of discussion, it is agreed that it is not a security > vulnerability, but > > an 'Enhancement'. > > > > The proposed requirement for the enhancement is: > > > > Provide an option in config to alert user that > > a) File is larger than a configurable limit > > b) File type is/is not valid. > > > > but it may need more discussion in community on both the > requirement and design > > if it will be done, that is why this thread comes out in first > place. :-) > > > >>> FYI: https://issues.jboss.org/browse/WFCORE-1057 > >>> > > > > Best Regards > > -- > > Lin Gao > > Software Engineer > > JBoss by 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 darran.lofthouse at jboss.com Wed Nov 4 08:52:22 2015 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Wed, 4 Nov 2015 13:52:22 +0000 Subject: [wildfly-dev] Shall we limit size of the deployment in WildFly? In-Reply-To: References: <24706283.2168206.1446540061297.JavaMail.zimbra@redhat.com> <5638B46A.9050103@redhat.com> <432170035.3201449.1446599629356.JavaMail.zimbra@redhat.com> <5639CBB1.5050805@jboss.com> <5874D840-F955-41D1-A617-DECD1498CF64@redhat.com> Message-ID: <563A0D96.40905@jboss.com> Does the op in the CLI send any length information? That would help the two be consistent. On 04/11/15 12:29, Jason T. Greene wrote: > > On Nov 4, 2015, at 4:36 AM, Heiko Braun > wrote: > >> GWT boils down to plain web technologies. And no, AFAIKT there is no >> way to check the size of an uploaded file across web browsers. Most >> browsers do however have an implicit limitation on the file size, >> which for majority is about 2 GB. > > You can now that we have switched to XHR to do the upload. The File > object returned from a file list has a size property that you can use. > > So you could in theory check that there is available space before > posting, however, since as Stuart mentions, browsers set a content > length, the server knows it anyway so it's less racy checking at the > server level, if one was to check. > > >> >>> On 04 Nov 2015, at 10:11, Darran Lofthouse >>> > wrote: >>> >>> From within GWT is there any option to detect the file size before >>> uploading? >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev From brian.stansberry at redhat.com Wed Nov 4 09:06:43 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 4 Nov 2015 08:06:43 -0600 Subject: [wildfly-dev] Shall we limit size of the deployment in WildFly? In-Reply-To: <563A0D96.40905@jboss.com> References: <24706283.2168206.1446540061297.JavaMail.zimbra@redhat.com> <5638B46A.9050103@redhat.com> <432170035.3201449.1446599629356.JavaMail.zimbra@redhat.com> <5639CBB1.5050805@jboss.com> <5874D840-F955-41D1-A617-DECD1498CF64@redhat.com> <563A0D96.40905@jboss.com> Message-ID: <563A10F3.5030508@redhat.com> It shouldn't as part of the management API, no.[1] Any total size information that gets exchanged is part of the underlying management communication protocol used for propagating streams and isn't exposed outside that layer. I'd like to see even that bit go away too, as it's unnecessary and wastes resources on the client. [1] In some cases the CLI actually sends the deployment bytes base 64 encoded as a param to the op, in which case the size info is available to the operation step handler. I consider that CLI behavior to be a bug though. On 11/4/15 7:52 AM, Darran Lofthouse wrote: > Does the op in the CLI send any length information? That would help the > two be consistent. > > On 04/11/15 12:29, Jason T. Greene wrote: >> >> On Nov 4, 2015, at 4:36 AM, Heiko Braun > > wrote: >> >>> GWT boils down to plain web technologies. And no, AFAIKT there is no >>> way to check the size of an uploaded file across web browsers. Most >>> browsers do however have an implicit limitation on the file size, >>> which for majority is about 2 GB. >> >> You can now that we have switched to XHR to do the upload. The File >> object returned from a file list has a size property that you can use. >> >> So you could in theory check that there is available space before >> posting, however, since as Stuart mentions, browsers set a content >> length, the server knows it anyway so it's less racy checking at the >> server level, if one was to check. >> >> >>> >>>> On 04 Nov 2015, at 10:11, Darran Lofthouse >>>> > wrote: >>>> >>>> From within GWT is there any option to detect the file size before >>>> uploading? >>> >>> _______________________________________________ >>> 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 > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From darran.lofthouse at jboss.com Wed Nov 4 09:09:30 2015 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Wed, 4 Nov 2015 14:09:30 +0000 Subject: [wildfly-dev] Shall we limit size of the deployment in WildFly? In-Reply-To: <563A10F3.5030508@redhat.com> References: <24706283.2168206.1446540061297.JavaMail.zimbra@redhat.com> <5638B46A.9050103@redhat.com> <432170035.3201449.1446599629356.JavaMail.zimbra@redhat.com> <5639CBB1.5050805@jboss.com> <5874D840-F955-41D1-A617-DECD1498CF64@redhat.com> <563A0D96.40905@jboss.com> <563A10F3.5030508@redhat.com> Message-ID: <563A119A.90607@jboss.com> Actually - this makes me think 'Content Length' on a HTTP upload is not a suitable measure of the file size - this is the length being sent to the server, not necessarily the actual size of the resulting file. On 04/11/15 14:06, Brian Stansberry wrote: > It shouldn't as part of the management API, no.[1] Any total size > information that gets exchanged is part of the underlying management > communication protocol used for propagating streams and isn't exposed > outside that layer. I'd like to see even that bit go away too, as it's > unnecessary and wastes resources on the client. > > [1] In some cases the CLI actually sends the deployment bytes base 64 > encoded as a param to the op, in which case the size info is available > to the operation step handler. I consider that CLI behavior to be a bug > though. > > On 11/4/15 7:52 AM, Darran Lofthouse wrote: >> Does the op in the CLI send any length information? That would help the >> two be consistent. >> >> On 04/11/15 12:29, Jason T. Greene wrote: >>> >>> On Nov 4, 2015, at 4:36 AM, Heiko Braun >> > wrote: >>> >>>> GWT boils down to plain web technologies. And no, AFAIKT there is no >>>> way to check the size of an uploaded file across web browsers. Most >>>> browsers do however have an implicit limitation on the file size, >>>> which for majority is about 2 GB. >>> >>> You can now that we have switched to XHR to do the upload. The File >>> object returned from a file list has a size property that you can use. >>> >>> So you could in theory check that there is available space before >>> posting, however, since as Stuart mentions, browsers set a content >>> length, the server knows it anyway so it's less racy checking at the >>> server level, if one was to check. >>> >>> >>>> >>>>> On 04 Nov 2015, at 10:11, Darran Lofthouse >>>>> > wrote: >>>>> >>>>> From within GWT is there any option to detect the file size before >>>>> uploading? >>>> >>>> _______________________________________________ >>>> 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 jason.greene at redhat.com Wed Nov 4 09:10:17 2015 From: jason.greene at redhat.com (Jason T. Greene) Date: Wed, 4 Nov 2015 09:10:17 -0500 (EST) Subject: [wildfly-dev] Shall we limit size of the deployment in WildFly? In-Reply-To: <563A0D96.40905@jboss.com> References: <24706283.2168206.1446540061297.JavaMail.zimbra@redhat.com> <5638B46A.9050103@redhat.com> <432170035.3201449.1446599629356.JavaMail.zimbra@redhat.com> <5639CBB1.5050805@jboss.com> <5874D840-F955-41D1-A617-DECD1498CF64@redhat.com> <563A0D96.40905@jboss.com> Message-ID: <3AF85B48-671B-49F1-8426-1309D5A2A699@redhat.com> It doesn't, since it's just a stream. However we could add that info and only validate it if it's there. > On Nov 4, 2015, at 7:52 AM, Darran Lofthouse wrote: > > Does the op in the CLI send any length information? That would help the two be consistent. > >> On 04/11/15 12:29, Jason T. Greene wrote: >> >> On Nov 4, 2015, at 4:36 AM, Heiko Braun > > wrote: >> >>> GWT boils down to plain web technologies. And no, AFAIKT there is no >>> way to check the size of an uploaded file across web browsers. Most >>> browsers do however have an implicit limitation on the file size, >>> which for majority is about 2 GB. >> >> You can now that we have switched to XHR to do the upload. The File >> object returned from a file list has a size property that you can use. >> >> So you could in theory check that there is available space before >> posting, however, since as Stuart mentions, browsers set a content >> length, the server knows it anyway so it's less racy checking at the >> server level, if one was to check. >> >> >>> >>>> On 04 Nov 2015, at 10:11, Darran Lofthouse >>>> > wrote: >>>> >>>> From within GWT is there any option to detect the file size before >>>> uploading? >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev From jason.greene at redhat.com Wed Nov 4 09:25:54 2015 From: jason.greene at redhat.com (Jason T. Greene) Date: Wed, 4 Nov 2015 09:25:54 -0500 (EST) Subject: [wildfly-dev] Shall we limit size of the deployment in WildFly? In-Reply-To: <563A119A.90607@jboss.com> References: <24706283.2168206.1446540061297.JavaMail.zimbra@redhat.com> <5638B46A.9050103@redhat.com> <432170035.3201449.1446599629356.JavaMail.zimbra@redhat.com> <5639CBB1.5050805@jboss.com> <5874D840-F955-41D1-A617-DECD1498CF64@redhat.com> <563A0D96.40905@jboss.com> <563A10F3.5030508@redhat.com> <563A119A.90607@jboss.com> Message-ID: <367343B8-A7CB-4EEF-ACBE-280B5DC18433@redhat.com> Sent from my iPhone > On Nov 4, 2015, at 8:09 AM, Darran Lofthouse wrote: > > Actually - this makes me think 'Content Length' on a HTTP upload is not > a suitable measure of the file size - this is the length being sent to > the server, not necessarily the actual size of the resulting file. Well technically we use multipart/form-data, so the file that is appended is actually a part with its own content-length independent of the http message body. It's a fair point though that this value is the network size which is not necessarily the disk size . It just so happens we only support the cases where hey correspond (on the http side). You can't add a gzip encoding to a part for example. You could only do that as a special mime-type. > >> On 04/11/15 14:06, Brian Stansberry wrote: >> It shouldn't as part of the management API, no.[1] Any total size >> information that gets exchanged is part of the underlying management >> communication protocol used for propagating streams and isn't exposed >> outside that layer. I'd like to see even that bit go away too, as it's >> unnecessary and wastes resources on the client. >> >> [1] In some cases the CLI actually sends the deployment bytes base 64 >> encoded as a param to the op, in which case the size info is available >> to the operation step handler. I consider that CLI behavior to be a bug >> though. >> >>> On 11/4/15 7:52 AM, Darran Lofthouse wrote: >>> Does the op in the CLI send any length information? That would help the >>> two be consistent. >>> >>>> On 04/11/15 12:29, Jason T. Greene wrote: >>>> >>>> On Nov 4, 2015, at 4:36 AM, Heiko Braun >>> > wrote: >>>> >>>>> GWT boils down to plain web technologies. And no, AFAIKT there is no >>>>> way to check the size of an uploaded file across web browsers. Most >>>>> browsers do however have an implicit limitation on the file size, >>>>> which for majority is about 2 GB. >>>> >>>> You can now that we have switched to XHR to do the upload. The File >>>> object returned from a file list has a size property that you can use. >>>> >>>> So you could in theory check that there is available space before >>>> posting, however, since as Stuart mentions, browsers set a content >>>> length, the server knows it anyway so it's less racy checking at the >>>> server level, if one was to check. >>>> >>>> >>>>> >>>>>> On 04 Nov 2015, at 10:11, Darran Lofthouse >>>>>> > wrote: >>>>>> >>>>>> From within GWT is there any option to detect the file size before >>>>>> uploading? >>>>> >>>>> _______________________________________________ >>>>> 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 > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From ttarrant at redhat.com Wed Nov 4 09:37:59 2015 From: ttarrant at redhat.com (Tristan Tarrant) Date: Wed, 4 Nov 2015 15:37:59 +0100 Subject: [wildfly-dev] Shall we limit size of the deployment in WildFly? In-Reply-To: <556E0C61-5F39-4557-B640-4035474E8563@redhat.com> References: <24706283.2168206.1446540061297.JavaMail.zimbra@redhat.com> <5638B46A.9050103@redhat.com> <432170035.3201449.1446599629356.JavaMail.zimbra@redhat.com> <556E0C61-5F39-4557-B640-4035474E8563@redhat.com> Message-ID: <563A1847.6010309@redhat.com> While we're on filesystem space availability, for monitoring purposes, would it be possible to expose this as a runtime metric for known server locations (data, tmp, logs) ? Tristan On 04/11/2015 13:37, Jason T. Greene wrote: > On Nov 3, 2015, at 7:14 PM, Lin Gao wrote: > >>>> On 11/03/2015 02:41 AM, Lin Gao wrote: >>>> Hi, >>>> >>>> WildFly does not limit the deployment file size, users with appropriate >>>> privilege(deployer) can select any file to deploy from both CLI and web >>>> console. >>>> >>>> For the too big file, it may exhaust all available disk space, and in >>>> some cases, even small file can exhaust the disk space if the current >>>> disk space is not big enough. >>>> >>>> So shall we limit file size of the deployment in WildFly? or shall we >>>> limit the available disk space? or shall we just show a warning message >>>> to users? >>>> >>>> If we do, where in the management API configuration for this should be >>>> done, if it is done this way? >>>> >>>> Arbitrary limits will break users, so if we have an arbitrary limit it >>>> needs to be easily adjusted. >>>> >>>> In case of domain mode, different hosts may have different disk space, >>>> which means they are likely have different capacity to hold deployment >>>> files. For example, servers in server-group-A may have 2GB available >>>> disk space, servers in server-group-B may have 200MB available disk >>>> space. An unified limit for the whole domain seems not fair for the >>>> servers with more available disk space. >>>> >>>> Also, WildFly does not limit type of the deployment file, but it might >>>> need a separate discussion if necessary? >>>> >>>> Any thoughts? >>> >>> Is this in response to a real observed problem? >> >> Yes it is. > > My understanding was that this was reported by a user but it was reported as something they were concerned with, and not actually something that was occurring in their environment. > > I agree with David that disk quotas on the processing running the app server is the most appropriate solution to prevent interference with other processes. > > I do not think we should have a hard coded limit as a constant because that will prevent legit deployments from working, and you can still run out of disk space (e.g you have 20k left and you upload a 21k deployment, which is under 1G) > > We could have an extra check that verifies enough disk space in the add content management op, however Java does not give us access to quota information so the best we could do is only verify available disk space (unless we exec a command for every platform we support). > > IMO this one is pretty low priority, but perhaps those that monitor this list see it as a need. If so can you speak up? > > > >> >>> In general, if the user >>> doesn't have space for a deployment, the deployment will fail with an >>> error and (I am fairly certain) will delete the partial deployment. If >>> there is space, then the deployment will succeed regardless of size. >> >>> It's interesting that the JIRA you reference speaks in terms of >>> security. If an admin wants to lock down storage space, it's probably >>> best to do it at the operating system level using e.g. disk quotas - >>> there are too many ways to get the application server to write arbitrary >>> amounts of data to the file system, regardless of the presence of a >>> security manager or any other application-level control. >>> >>> I'm pretty sure that if an attacker has permission to upload deployments >>> to the server, they already essentially have control over the server. >>> This should be an OS level concern. >> >> The JIRA in question was a 'bug' related to security at first, after several >> rounds of discussion, it is agreed that it is not a security vulnerability, but >> an 'Enhancement'. >> >> The proposed requirement for the enhancement is: >> >> Provide an option in config to alert user that >> a) File is larger than a configurable limit >> b) File type is/is not valid. >> >> but it may need more discussion in community on both the requirement and design >> if it will be done, that is why this thread comes out in first place. :-) >> >>>> FYI: https://issues.jboss.org/browse/WFCORE-1057 >> >> Best Regards >> -- >> Lin Gao >> Software Engineer >> JBoss by 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 > -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat From jason.greene at redhat.com Wed Nov 4 10:02:19 2015 From: jason.greene at redhat.com (Jason T. Greene) Date: Wed, 4 Nov 2015 10:02:19 -0500 (EST) Subject: [wildfly-dev] Shall we limit size of the deployment in WildFly? In-Reply-To: <563A1847.6010309@redhat.com> References: <24706283.2168206.1446540061297.JavaMail.zimbra@redhat.com> <5638B46A.9050103@redhat.com> <432170035.3201449.1446599629356.JavaMail.zimbra@redhat.com> <556E0C61-5F39-4557-B640-4035474E8563@redhat.com> <563A1847.6010309@redhat.com> Message-ID: <54988A69-18D3-4FAB-A5E6-5F3F47D8D6A6@redhat.com> Yes that would be very clear cut and easy to do. > On Nov 4, 2015, at 8:38 AM, Tristan Tarrant wrote: > > While we're on filesystem space availability, for monitoring purposes, > would it be possible to expose this as a runtime metric for known server > locations (data, tmp, logs) ? > > Tristan > >> On 04/11/2015 13:37, Jason T. Greene wrote: >> On Nov 3, 2015, at 7:14 PM, Lin Gao wrote: >> >>>>> On 11/03/2015 02:41 AM, Lin Gao wrote: >>>>> Hi, >>>>> >>>>> WildFly does not limit the deployment file size, users with appropriate >>>>> privilege(deployer) can select any file to deploy from both CLI and web >>>>> console. >>>>> >>>>> For the too big file, it may exhaust all available disk space, and in >>>>> some cases, even small file can exhaust the disk space if the current >>>>> disk space is not big enough. >>>>> >>>>> So shall we limit file size of the deployment in WildFly? or shall we >>>>> limit the available disk space? or shall we just show a warning message >>>>> to users? >>>>> >>>>> If we do, where in the management API configuration for this should be >>>>> done, if it is done this way? >>>>> >>>>> Arbitrary limits will break users, so if we have an arbitrary limit it >>>>> needs to be easily adjusted. >>>>> >>>>> In case of domain mode, different hosts may have different disk space, >>>>> which means they are likely have different capacity to hold deployment >>>>> files. For example, servers in server-group-A may have 2GB available >>>>> disk space, servers in server-group-B may have 200MB available disk >>>>> space. An unified limit for the whole domain seems not fair for the >>>>> servers with more available disk space. >>>>> >>>>> Also, WildFly does not limit type of the deployment file, but it might >>>>> need a separate discussion if necessary? >>>>> >>>>> Any thoughts? >>>> >>>> Is this in response to a real observed problem? >>> >>> Yes it is. >> >> My understanding was that this was reported by a user but it was reported as something they were concerned with, and not actually something that was occurring in their environment. >> >> I agree with David that disk quotas on the processing running the app server is the most appropriate solution to prevent interference with other processes. >> >> I do not think we should have a hard coded limit as a constant because that will prevent legit deployments from working, and you can still run out of disk space (e.g you have 20k left and you upload a 21k deployment, which is under 1G) >> >> We could have an extra check that verifies enough disk space in the add content management op, however Java does not give us access to quota information so the best we could do is only verify available disk space (unless we exec a command for every platform we support). >> >> IMO this one is pretty low priority, but perhaps those that monitor this list see it as a need. If so can you speak up? >> >> >> >>> >>>> In general, if the user >>>> doesn't have space for a deployment, the deployment will fail with an >>>> error and (I am fairly certain) will delete the partial deployment. If >>>> there is space, then the deployment will succeed regardless of size. >>> >>>> It's interesting that the JIRA you reference speaks in terms of >>>> security. If an admin wants to lock down storage space, it's probably >>>> best to do it at the operating system level using e.g. disk quotas - >>>> there are too many ways to get the application server to write arbitrary >>>> amounts of data to the file system, regardless of the presence of a >>>> security manager or any other application-level control. >>>> >>>> I'm pretty sure that if an attacker has permission to upload deployments >>>> to the server, they already essentially have control over the server. >>>> This should be an OS level concern. >>> >>> The JIRA in question was a 'bug' related to security at first, after several >>> rounds of discussion, it is agreed that it is not a security vulnerability, but >>> an 'Enhancement'. >>> >>> The proposed requirement for the enhancement is: >>> >>> Provide an option in config to alert user that >>> a) File is larger than a configurable limit >>> b) File type is/is not valid. >>> >>> but it may need more discussion in community on both the requirement and design >>> if it will be done, that is why this thread comes out in first place. :-) >>> >>>>> FYI: https://issues.jboss.org/browse/WFCORE-1057 >>> >>> Best Regards >>> -- >>> Lin Gao >>> Software Engineer >>> JBoss by 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 > > -- > Tristan Tarrant > Infinispan Lead > 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 darran.lofthouse at jboss.com Wed Nov 4 10:21:11 2015 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Wed, 4 Nov 2015 15:21:11 +0000 Subject: [wildfly-dev] Shall we limit size of the deployment in WildFly? In-Reply-To: <54988A69-18D3-4FAB-A5E6-5F3F47D8D6A6@redhat.com> References: <24706283.2168206.1446540061297.JavaMail.zimbra@redhat.com> <5638B46A.9050103@redhat.com> <432170035.3201449.1446599629356.JavaMail.zimbra@redhat.com> <556E0C61-5F39-4557-B640-4035474E8563@redhat.com> <563A1847.6010309@redhat.com> <54988A69-18D3-4FAB-A5E6-5F3F47D8D6A6@redhat.com> Message-ID: <563A2267.7010307@jboss.com> This would also be something ideal to report on in the "administrator encouragement" service I keep meaning to look into again ;-) On 04/11/15 15:02, Jason T. Greene wrote: > Yes that would be very clear cut and easy to do. > >> On Nov 4, 2015, at 8:38 AM, Tristan Tarrant wrote: >> >> While we're on filesystem space availability, for monitoring purposes, >> would it be possible to expose this as a runtime metric for known server >> locations (data, tmp, logs) ? >> >> Tristan >> >>> On 04/11/2015 13:37, Jason T. Greene wrote: >>> On Nov 3, 2015, at 7:14 PM, Lin Gao wrote: >>> >>>>>> On 11/03/2015 02:41 AM, Lin Gao wrote: >>>>>> Hi, >>>>>> >>>>>> WildFly does not limit the deployment file size, users with appropriate >>>>>> privilege(deployer) can select any file to deploy from both CLI and web >>>>>> console. >>>>>> >>>>>> For the too big file, it may exhaust all available disk space, and in >>>>>> some cases, even small file can exhaust the disk space if the current >>>>>> disk space is not big enough. >>>>>> >>>>>> So shall we limit file size of the deployment in WildFly? or shall we >>>>>> limit the available disk space? or shall we just show a warning message >>>>>> to users? >>>>>> >>>>>> If we do, where in the management API configuration for this should be >>>>>> done, if it is done this way? >>>>>> >>>>>> Arbitrary limits will break users, so if we have an arbitrary limit it >>>>>> needs to be easily adjusted. >>>>>> >>>>>> In case of domain mode, different hosts may have different disk space, >>>>>> which means they are likely have different capacity to hold deployment >>>>>> files. For example, servers in server-group-A may have 2GB available >>>>>> disk space, servers in server-group-B may have 200MB available disk >>>>>> space. An unified limit for the whole domain seems not fair for the >>>>>> servers with more available disk space. >>>>>> >>>>>> Also, WildFly does not limit type of the deployment file, but it might >>>>>> need a separate discussion if necessary? >>>>>> >>>>>> Any thoughts? >>>>> >>>>> Is this in response to a real observed problem? >>>> >>>> Yes it is. >>> >>> My understanding was that this was reported by a user but it was reported as something they were concerned with, and not actually something that was occurring in their environment. >>> >>> I agree with David that disk quotas on the processing running the app server is the most appropriate solution to prevent interference with other processes. >>> >>> I do not think we should have a hard coded limit as a constant because that will prevent legit deployments from working, and you can still run out of disk space (e.g you have 20k left and you upload a 21k deployment, which is under 1G) >>> >>> We could have an extra check that verifies enough disk space in the add content management op, however Java does not give us access to quota information so the best we could do is only verify available disk space (unless we exec a command for every platform we support). >>> >>> IMO this one is pretty low priority, but perhaps those that monitor this list see it as a need. If so can you speak up? >>> >>> >>> >>>> >>>>> In general, if the user >>>>> doesn't have space for a deployment, the deployment will fail with an >>>>> error and (I am fairly certain) will delete the partial deployment. If >>>>> there is space, then the deployment will succeed regardless of size. >>>> >>>>> It's interesting that the JIRA you reference speaks in terms of >>>>> security. If an admin wants to lock down storage space, it's probably >>>>> best to do it at the operating system level using e.g. disk quotas - >>>>> there are too many ways to get the application server to write arbitrary >>>>> amounts of data to the file system, regardless of the presence of a >>>>> security manager or any other application-level control. >>>>> >>>>> I'm pretty sure that if an attacker has permission to upload deployments >>>>> to the server, they already essentially have control over the server. >>>>> This should be an OS level concern. >>>> >>>> The JIRA in question was a 'bug' related to security at first, after several >>>> rounds of discussion, it is agreed that it is not a security vulnerability, but >>>> an 'Enhancement'. >>>> >>>> The proposed requirement for the enhancement is: >>>> >>>> Provide an option in config to alert user that >>>> a) File is larger than a configurable limit >>>> b) File type is/is not valid. >>>> >>>> but it may need more discussion in community on both the requirement and design >>>> if it will be done, that is why this thread comes out in first place. :-) >>>> >>>>>> FYI: https://issues.jboss.org/browse/WFCORE-1057 >>>> >>>> Best Regards >>>> -- >>>> Lin Gao >>>> Software Engineer >>>> JBoss by 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 >> >> -- >> Tristan Tarrant >> Infinispan Lead >> 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 brunosantos at copergas.com.br Wed Nov 4 13:33:23 2015 From: brunosantos at copergas.com.br (Bruno Santos) Date: Wed, 4 Nov 2015 18:33:23 +0000 Subject: [wildfly-dev] java.net.SocketException: Permission denied - Openshift Message-ID: I have a Restful Web Service, the server application is located on Server A and the client application is located on Openshift. If I try to run the client from any computer it works perfect but if I run from the Openshift I get the following error message: An Error Occurred: java.net.SocketException: Permission denied Stack Trace com.sun.jersey.api.client.ClientHandlerException: java.net.SocketException: Permission denied at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:155) at com.sun.jersey.api.client.Client.handle(Client.java:652) at com.sun.jersey.api.client.WebResource.handle(WebResource.java:682) at com.sun.jersey.api.client.WebResource.get(WebResource.java:193) at br.com.lidertec.meucinemaclient.mb.CinemaMB.getFilmesEmCartaz(CinemaMB.java:22) at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at javax.el.BeanELResolver.getValue(BeanELResolver.java:363) at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176) at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203) at com.sun.el.parser.AstValue.getValue(AstValue.java:140) at com.sun.el.parser.AstValue.getValue(AstValue.java:204) at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:226) at com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:109) at javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:194) at javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:182) at javax.faces.component.UIData.getValue(UIData.java:732) at javax.faces.component.UIData.getDataModel(UIData.java:1822) at javax.faces.component.UIData.setRowIndexWithoutRowStatePreserved(UIData.java:484) at javax.faces.component.UIData.setRowIndex(UIData.java:473) at com.sun.faces.renderkit.html_basic.TableRenderer.encodeBegin(TableRenderer.java:81) at javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:864) at javax.faces.component.UIData.encodeBegin(UIData.java:1133) at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1854) at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1859) at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1859) at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:456) at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:133) at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120) at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:655) at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86) at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72) at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Caused by: java.net.SocketException: Permission denied at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at java.net.Socket.connect(Socket.java:589) at java.net.Socket.connect(Socket.java:538) at sun.net.NetworkClient.doConnect(NetworkClient.java:180) at sun.net.www.http.HttpClient.openServer(HttpClient.java:432) at sun.net.www.http.HttpClient.openServer(HttpClient.java:527) at sun.net.www.http.HttpClient.(HttpClient.java:211) at sun.net.www.http.HttpClient.New(HttpClient.java:308) at sun.net.www.http.HttpClient.New(HttpClient.java:326) at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1168) at sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1104) at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:998) at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:932) at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1512) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1440) at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:480) at com.sun.jersey.client.urlconnection.URLConnectionClientHandler._invoke(URLConnectionClientHandler.java:253) at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:153) ... 60 more Can Anyone help??? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151104/a13f5565/attachment-0001.html From fjuma at redhat.com Wed Nov 4 16:35:35 2015 From: fjuma at redhat.com (Farah Juma) Date: Wed, 4 Nov 2015 16:35:35 -0500 (EST) Subject: [wildfly-dev] java.net.SocketException: Permission denied - Openshift In-Reply-To: References: Message-ID: <439650486.2948031.1446672935284.JavaMail.zimbra@redhat.com> As a quick test, what's the output of the following command after ssh'ing into your client instance on OpenShift? telnet YOUR_OUTBOUND_HTTP_URL 80 Farah ----- Original Message ----- > From: "Bruno Santos" > To: wildfly-dev at lists.jboss.org > Sent: Wednesday, November 4, 2015 1:33:23 PM > Subject: [wildfly-dev] java.net.SocketException: Permission denied - Openshift > > > > > > I have a Restful Web Service, the server application is located on Server A > and the client application is located on Openshift. If I try to run the > client from any computer it works perfect but if I run from the Openshift I > get the following error message: > > An Error Occurred: > > > java.net.SocketException: Permission denied Stack Trace > com.sun.jersey.api.client.ClientHandlerException: java.net.SocketException: > Permission denied > at > com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:155) > at com.sun.jersey.api.client.Client.handle(Client.java:652) > at com.sun.jersey.api.client.WebResource.handle(WebResource.java:682) > at com.sun.jersey.api.client.WebResource.get(WebResource.java:193) > at > br.com.lidertec.meucinemaclient.mb.CinemaMB.getFilmesEmCartaz(CinemaMB.java:22) > at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at javax.el.BeanELResolver.getValue(BeanELResolver.java:363) > at > com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176) > at > com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203) > at com.sun.el.parser.AstValue.getValue(AstValue.java:140) > at com.sun.el.parser.AstValue.getValue(AstValue.java:204) > at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:226) > at > com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:109) > at > javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:194) > at > javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:182) > at javax.faces.component.UIData.getValue(UIData.java:732) > at javax.faces.component.UIData.getDataModel(UIData.java:1822) > at > javax.faces.component.UIData.setRowIndexWithoutRowStatePreserved(UIData.java:484) > at javax.faces.component.UIData.setRowIndex(UIData.java:473) > at > com.sun.faces.renderkit.html_basic.TableRenderer.encodeBegin(TableRenderer.java:81) > at > javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:864) > at javax.faces.component.UIData.encodeBegin(UIData.java:1133) > at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1854) > at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1859) > at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1859) > at > com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:456) > at > com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:133) > at > javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) > at > com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120) > at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) > at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219) > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:655) > at > io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86) > at > io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > at > io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at > org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at > io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at > io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at > io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) > at > io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72) > at > io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > at > io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282) > at > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261) > at > io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80) > at > io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.net.SocketException: Permission denied > at java.net.PlainSocketImpl.socketConnect(Native Method) > at > java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345) > at > java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) > at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) > at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) > at java.net.Socket.connect(Socket.java:589) > at java.net.Socket.connect(Socket.java:538) > at sun.net.NetworkClient.doConnect(NetworkClient.java:180) > at sun.net.www.http.HttpClient.openServer(HttpClient.java:432) > at sun.net.www.http.HttpClient.openServer(HttpClient.java:527) > at sun.net.www.http.HttpClient.(HttpClient.java:211) > at sun.net.www.http.HttpClient.New(HttpClient.java:308) > at sun.net.www.http.HttpClient.New(HttpClient.java:326) > at > sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1168) > at > sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1104) > at > sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:998) > at > sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:932) > at > sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1512) > at > sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1440) > at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:480) > at > com.sun.jersey.client.urlconnection.URLConnectionClientHandler._invoke(URLConnectionClientHandler.java:253) > at > com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:153) > ... 60 more > > > > > Can Anyone help??? > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From emond.papegaaij at topicus.nl Tue Nov 10 03:29:17 2015 From: emond.papegaaij at topicus.nl (Emond Papegaaij) Date: Tue, 10 Nov 2015 09:29:17 +0100 Subject: [wildfly-dev] Concerns about deserialization attacks Message-ID: <60299780.F3egqTU4DQ@papegaaij> Hi all, As you probably know, there has recently been quite some discussion about remotely exploitable attacks via deserialization, for instance [1] and [2]. These exploits are demonstrated against commons-collections 3 and 4, spring 4 and groovy 2.4.4, but it is very likely other libraries (if not the jdk itself) also contain vulnerable code. In general, the advise is to not accept any serialized objects on a public interface. WildFly multiplexes its remote EJB invocation over the http port via http- remoting. I've found a way to make a WilfFly instance, configured with the default standalone.xml, accept arbitrary serialized objects. Access to port 8080 is all you need. I've been able to verify the commons-collections exploit by adding commons-collections to the right module and let WildFly deserialize my objects. So far, I've not been able to exploit WildFly using only the classes available via this route, but I've got the feeling that this is only a matter of time. As this is potentially sensitive information, I'm looking for a less public channel to share the details. Best regards, Emond Papegaaij [1] http://www.infoq.com/news/2015/11/commons-exploit [2] http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability From stuart.w.douglas at gmail.com Tue Nov 10 05:06:58 2015 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Tue, 10 Nov 2015 10:06:58 +0000 Subject: [wildfly-dev] Concerns about deserialization attacks In-Reply-To: <60299780.F3egqTU4DQ@papegaaij> References: <60299780.F3egqTU4DQ@papegaaij> Message-ID: Can you send me the details? I don't think we are actually vulnerable to the commons attack out of the box, modular class loading provides a very effective barrier against these kind of attacks. There are only a few modules that reference commons-collections, and they are not in any way involved with remote communication. Stuart On Tue, 10 Nov 2015 at 19:31 Emond Papegaaij wrote: > Hi all, > > As you probably know, there has recently been quite some discussion about > remotely exploitable attacks via deserialization, for instance [1] and [2]. > These exploits are demonstrated against commons-collections 3 and 4, > spring 4 > and groovy 2.4.4, but it is very likely other libraries (if not the jdk > itself) also contain vulnerable code. In general, the advise is to not > accept > any serialized objects on a public interface. > > WildFly multiplexes its remote EJB invocation over the http port via http- > remoting. I've found a way to make a WilfFly instance, configured with the > default standalone.xml, accept arbitrary serialized objects. Access to port > 8080 is all you need. I've been able to verify the commons-collections > exploit > by adding commons-collections to the right module and let WildFly > deserialize > my objects. So far, I've not been able to exploit WildFly using only the > classes available via this route, but I've got the feeling that this is > only a > matter of time. > > As this is potentially sensitive information, I'm looking for a less public > channel to share the details. > > Best regards, > Emond Papegaaij > > > [1] http://www.infoq.com/news/2015/11/commons-exploit > [2] > http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability > > _______________________________________________ > 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/20151110/b13cd79e/attachment.html From tomaz.cerar at gmail.com Tue Nov 10 05:17:04 2015 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Tue, 10 Nov 2015 11:17:04 +0100 Subject: [wildfly-dev] Concerns about deserialization attacks In-Reply-To: <60299780.F3egqTU4DQ@papegaaij> References: <60299780.F3egqTU4DQ@papegaaij> Message-ID: See https://access.redhat.com/solutions/2045023 https://access.redhat.com/security/cve/CVE-2012-0874 for best explanation. On Tue, Nov 10, 2015 at 9:29 AM, Emond Papegaaij wrote: > Hi all, > > As you probably know, there has recently been quite some discussion about > remotely exploitable attacks via deserialization, for instance [1] and [2]. > These exploits are demonstrated against commons-collections 3 and 4, > spring 4 > and groovy 2.4.4, but it is very likely other libraries (if not the jdk > itself) also contain vulnerable code. In general, the advise is to not > accept > any serialized objects on a public interface. > > WildFly multiplexes its remote EJB invocation over the http port via http- > remoting. I've found a way to make a WilfFly instance, configured with the > default standalone.xml, accept arbitrary serialized objects. Access to port > 8080 is all you need. I've been able to verify the commons-collections > exploit > by adding commons-collections to the right module and let WildFly > deserialize > my objects. So far, I've not been able to exploit WildFly using only the > classes available via this route, but I've got the feeling that this is > only a > matter of time. > > As this is potentially sensitive information, I'm looking for a less public > channel to share the details. > > Best regards, > Emond Papegaaij > > > [1] http://www.infoq.com/news/2015/11/commons-exploit > [2] > http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability > > _______________________________________________ > 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/20151110/2647c2fc/attachment.html From stuart.w.douglas at gmail.com Tue Nov 10 06:12:45 2015 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Tue, 10 Nov 2015 11:12:45 +0000 Subject: [wildfly-dev] Concerns about deserialization attacks In-Reply-To: References: <60299780.F3egqTU4DQ@papegaaij> Message-ID: After talking with Emond the derialization is only possible for authenticated users. Because we have transparent local auth for users running under the same user as the server if you test from if you test locally it can give different results to what an actual remote user could see. There is no way around this for authenticated users, protocols such as remote EJB rely on serialization to send their data. Even then if you have a malicious authenticated user modular class loading should prevent exploitation of the commons-collections problem unless the deployment depends on (or includes) common-collections. Stuart On Tue, 10 Nov 2015 at 21:06 Stuart Douglas wrote: > Can you send me the details? > > I don't think we are actually vulnerable to the commons attack out of the > box, modular class loading provides a very effective barrier against these > kind of attacks. There are only a few modules that reference > commons-collections, and they are not in any way involved with remote > communication. > > Stuart > > > > On Tue, 10 Nov 2015 at 19:31 Emond Papegaaij > wrote: > >> Hi all, >> >> As you probably know, there has recently been quite some discussion about >> remotely exploitable attacks via deserialization, for instance [1] and >> [2]. >> These exploits are demonstrated against commons-collections 3 and 4, >> spring 4 >> and groovy 2.4.4, but it is very likely other libraries (if not the jdk >> itself) also contain vulnerable code. In general, the advise is to not >> accept >> any serialized objects on a public interface. >> >> WildFly multiplexes its remote EJB invocation over the http port via http- >> remoting. I've found a way to make a WilfFly instance, configured with the >> default standalone.xml, accept arbitrary serialized objects. Access to >> port >> 8080 is all you need. I've been able to verify the commons-collections >> exploit >> by adding commons-collections to the right module and let WildFly >> deserialize >> my objects. So far, I've not been able to exploit WildFly using only the >> classes available via this route, but I've got the feeling that this is >> only a >> matter of time. >> >> As this is potentially sensitive information, I'm looking for a less >> public >> channel to share the details. >> >> Best regards, >> Emond Papegaaij >> >> >> [1] http://www.infoq.com/news/2015/11/commons-exploit >> [2] >> http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability >> >> _______________________________________________ >> 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/20151110/af2933c4/attachment-0001.html From sourin-v at bridgestone-bae.com Wed Nov 11 16:29:36 2015 From: sourin-v at bridgestone-bae.com (Vincent Sourin) Date: Wed, 11 Nov 2015 22:29:36 +0100 Subject: [wildfly-dev] Adding openwire protocol to Artemis server - Wildfly 10 Message-ID: <5643B340.3090209@bridgestone-bae.com> Hello, As I need openwire protocol for messaging, I enable it by doing that : https://github.com/Vinche59/wildfly/commit/6dfab60d309db0706964e7aef054d3a18c0f0ba8 After few tests, it seems functionnal but I'd like to know if that's the correct way to add features in Wildfly ? Thanks for your advices. Vincent. From arjan.tijms at gmail.com Mon Nov 16 09:10:39 2015 From: arjan.tijms at gmail.com (arjan tijms) Date: Mon, 16 Nov 2015 15:10:39 +0100 Subject: [wildfly-dev] Adding additional security domain to standalone.xml? In-Reply-To: <5639D286.3070401@jboss.com> References: <5639D286.3070401@jboss.com> Message-ID: Hi, On Wed, Nov 4, 2015 at 10:40 AM, Darran Lofthouse < darran.lofthouse at jboss.com> wrote: > I will have a look at what we can do, Did you already had a chance to look at this? And any idea of the direction? A new attribute in jboss-web.xml? Actually adding the security domain as proposed, or something else? Kind regards, Arjan Tijms -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151116/faec89da/attachment.html From jmesnil at redhat.com Tue Nov 17 08:02:13 2015 From: jmesnil at redhat.com (Jeff Mesnil) Date: Tue, 17 Nov 2015 14:02:13 +0100 Subject: [wildfly-dev] Adding openwire protocol to Artemis server - Wildfly 10 In-Reply-To: <5643B340.3090209@bridgestone-bae.com> References: <5643B340.3090209@bridgestone-bae.com> Message-ID: Hi, > On 11 Nov 2015, at 22:29, Vincent Sourin wrote: > > Hello, > > As I need openwire protocol for messaging, I enable it by doing that : > > https://github.com/Vinche59/wildfly/commit/6dfab60d309db0706964e7aef054d3a18c0f0ba8 > > After few tests, it seems functionnal but I'd like to know if that's the > correct way to add features in Wildfly ? I had a quick look at your commit and it looks good. That?s the same mechanism used to load all protocols supported by ActiveMQ Artemis. jeff -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ From remerson at redhat.com Thu Nov 19 05:25:56 2015 From: remerson at redhat.com (Ryan Emerson) Date: Thu, 19 Nov 2015 05:25:56 -0500 (EST) Subject: [wildfly-dev] Supporting FIPS in domain mode In-Reply-To: <672151587.9650789.1447719510682.JavaMail.zimbra@redhat.com> References: <1977413026.7907861.1447442465150.JavaMail.zimbra@redhat.com> <1767350107.13865039.1447494555396.JavaMail.zimbra@redhat.com> <1488409485.9384147.1447699158696.JavaMail.zimbra@redhat.com> <672151587.9650789.1447719510682.JavaMail.zimbra@redhat.com> Message-ID: <690456102.15453402.1447928756296.JavaMail.zimbra@redhat.com> Hello All, Currently domain mode is unable to execute when the JVM has FIPS enabled. See [1] for example config files and the resulting stacktrace. I am looking into this issue (SET engineer), however my current knowledge of core and FIPS is limited. What are your thoughts on how to implement FIPS compatibility? Is there any fundamental reasons why such a feature shouldn't be supported? [1] https://issues.jboss.org/browse/WFCORE-1135 Thanks Ryan From darran.lofthouse at jboss.com Thu Nov 19 07:50:11 2015 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Thu, 19 Nov 2015 12:50:11 +0000 Subject: [wildfly-dev] Supporting FIPS in domain mode In-Reply-To: <690456102.15453402.1447928756296.JavaMail.zimbra@redhat.com> References: <1977413026.7907861.1447442465150.JavaMail.zimbra@redhat.com> <1767350107.13865039.1447494555396.JavaMail.zimbra@redhat.com> <1488409485.9384147.1447699158696.JavaMail.zimbra@redhat.com> <672151587.9650789.1447719510682.JavaMail.zimbra@redhat.com> <690456102.15453402.1447928756296.JavaMail.zimbra@redhat.com> Message-ID: <564DC583.1020503@jboss.com> The problem with this issue is that it is going to be quite complex to solve, especially once we start to expand on all the scenarios we need to support. Add to that it becomes even more complex once we need to consider backwards compatibility. Generally the scenarios we need are: - - Using a FIPS configured JVM - Using a non-FIPS configured JVM Combined with: - - TLS enabled for the host controller connection. - TLS not enabled. Although the issue raised only talks about an error message for one we need to ensure we cover them all. Firstly the connection that is being talked about here is the connection from the individual application server process back to it's host controller all running on the same machine. The reason for the simple trusting solution is because although a connection is used it is always local - the reason we need to be able to support TLS for this connection is because we connect to the same Remoting connector as remote clients also used so once TLS is enabled it is enabled for all. Firstly I think it is worth exploring if there is anything else we can do to automatically configure the client side of this connection without requiring any additional configuration from the administrator. If we can identify the certificate the server will be using for the connection there may be something we can do to send this to the application server process so that it can instantiate a SunJSSE compatible KeyStore and subsequently a SunJSSE TrustManager that will be accepted into the SSLContext. When it comes to host controller and application server initialisation those two processes are always guaranteed to be the same version so this gives us some leeway on how the application server process is initially configured. If that is not possible then an alternative is that to achieve a FIPS mode compliant connection from the application server to the host controller is going to require a custom configuration. The problem is we do not have the management model available on the application server at this time so we would probably still need a way to define it within the host controller and convert it to a format that can be used on the application server. In this case I don't think using the standard system properties would be a good idea as existing installations could already be relying on these elsewhere. If we needed to go down the custom configuration route then I would suggest lack of configuration means stick with the current behaviour so existing installations are unaffected leaving the configuration to be set by those that do require it. If automatically obtaining the certificate is viable then that could be used for all cases without breaking compatibility but additional verification is probably needed there. Regards, Darran Lofthouse. On 19/11/15 10:25, Ryan Emerson wrote: > Hello All, > > Currently domain mode is unable to execute when the JVM has FIPS enabled. See [1] for example config files and the resulting stacktrace. > > I am looking into this issue (SET engineer), however my current knowledge of core and FIPS is limited. What are your thoughts on how to implement FIPS compatibility? Is there any fundamental reasons why such a feature shouldn't be supported? > > [1] https://issues.jboss.org/browse/WFCORE-1135 > > Thanks > Ryan > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From anilsaldhana at gmail.com Thu Nov 19 08:07:32 2015 From: anilsaldhana at gmail.com (Anil Saldanha) Date: Thu, 19 Nov 2015 07:07:32 -0600 Subject: [wildfly-dev] Supporting FIPS in domain mode In-Reply-To: <564DC583.1020503@jboss.com> References: <1977413026.7907861.1447442465150.JavaMail.zimbra@redhat.com> <1767350107.13865039.1447494555396.JavaMail.zimbra@redhat.com> <1488409485.9384147.1447699158696.JavaMail.zimbra@redhat.com> <672151587.9650789.1447719510682.JavaMail.zimbra@redhat.com> <690456102.15453402.1447928756296.JavaMail.zimbra@redhat.com> <564DC583.1020503@jboss.com> Message-ID: I agree with Darran that this is a complicated exercise that should be backed by a business demand. The potential for the feature -- if implemented -- to break in the long run is high -- if any custom configuration is involved. > On Nov 19, 2015, at 6:50 AM, Darran Lofthouse wrote: > > The problem with this issue is that it is going to be quite complex to > solve, especially once we start to expand on all the scenarios we need > to support. Add to that it becomes even more complex once we need to > consider backwards compatibility. > > Generally the scenarios we need are: - > - Using a FIPS configured JVM > - Using a non-FIPS configured JVM > Combined with: - > - TLS enabled for the host controller connection. > - TLS not enabled. > > Although the issue raised only talks about an error message for one we > need to ensure we cover them all. > > Firstly the connection that is being talked about here is the connection > from the individual application server process back to it's host > controller all running on the same machine. The reason for the simple > trusting solution is because although a connection is used it is always > local - the reason we need to be able to support TLS for this connection > is because we connect to the same Remoting connector as remote clients > also used so once TLS is enabled it is enabled for all. > > Firstly I think it is worth exploring if there is anything else we can > do to automatically configure the client side of this connection without > requiring any additional configuration from the administrator. > > If we can identify the certificate the server will be using for the > connection there may be something we can do to send this to the > application server process so that it can instantiate a SunJSSE > compatible KeyStore and subsequently a SunJSSE TrustManager that will be > accepted into the SSLContext. > > When it comes to host controller and application server initialisation > those two processes are always guaranteed to be the same version so this > gives us some leeway on how the application server process is initially > configured. > > If that is not possible then an alternative is that to achieve a FIPS > mode compliant connection from the application server to the host > controller is going to require a custom configuration. The problem is > we do not have the management model available on the application server > at this time so we would probably still need a way to define it within > the host controller and convert it to a format that can be used on the > application server. In this case I don't think using the standard > system properties would be a good idea as existing installations could > already be relying on these elsewhere. > > If we needed to go down the custom configuration route then I would > suggest lack of configuration means stick with the current behaviour so > existing installations are unaffected leaving the configuration to be > set by those that do require it. > > If automatically obtaining the certificate is viable then that could be > used for all cases without breaking compatibility but additional > verification is probably needed there. > > Regards, > Darran Lofthouse. > > > >> On 19/11/15 10:25, Ryan Emerson wrote: >> Hello All, >> >> Currently domain mode is unable to execute when the JVM has FIPS enabled. See [1] for example config files and the resulting stacktrace. >> >> I am looking into this issue (SET engineer), however my current knowledge of core and FIPS is limited. What are your thoughts on how to implement FIPS compatibility? Is there any fundamental reasons why such a feature shouldn't be supported? >> >> [1] https://issues.jboss.org/browse/WFCORE-1135 >> >> Thanks >> Ryan >> _______________________________________________ >> 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 remerson at redhat.com Thu Nov 19 08:59:51 2015 From: remerson at redhat.com (Ryan Emerson) Date: Thu, 19 Nov 2015 08:59:51 -0500 (EST) Subject: [wildfly-dev] Supporting FIPS in domain mode In-Reply-To: References: <1977413026.7907861.1447442465150.JavaMail.zimbra@redhat.com> <1767350107.13865039.1447494555396.JavaMail.zimbra@redhat.com> <1488409485.9384147.1447699158696.JavaMail.zimbra@redhat.com> <672151587.9650789.1447719510682.JavaMail.zimbra@redhat.com> <690456102.15453402.1447928756296.JavaMail.zimbra@redhat.com> <564DC583.1020503@jboss.com> Message-ID: <1285838309.15603850.1447941591158.JavaMail.zimbra@redhat.com> This issue originated from a downstream customer issue (BZ now linked in JIRA), so there is some demand. Originally the intention was to try and backport the upstream fix, however as FIPS support now appears to be a complex RFE this may not be possible. ----- Original Message ----- From: "Anil Saldanha" To: "Darran Lofthouse" Cc: wildfly-dev at lists.jboss.org Sent: Thursday, 19 November, 2015 1:07:32 PM Subject: Re: [wildfly-dev] Supporting FIPS in domain mode I agree with Darran that this is a complicated exercise that should be backed by a business demand. The potential for the feature -- if implemented -- to break in the long run is high -- if any custom configuration is involved. > On Nov 19, 2015, at 6:50 AM, Darran Lofthouse wrote: > > The problem with this issue is that it is going to be quite complex to > solve, especially once we start to expand on all the scenarios we need > to support. Add to that it becomes even more complex once we need to > consider backwards compatibility. > > Generally the scenarios we need are: - > - Using a FIPS configured JVM > - Using a non-FIPS configured JVM > Combined with: - > - TLS enabled for the host controller connection. > - TLS not enabled. > > Although the issue raised only talks about an error message for one we > need to ensure we cover them all. > > Firstly the connection that is being talked about here is the connection > from the individual application server process back to it's host > controller all running on the same machine. The reason for the simple > trusting solution is because although a connection is used it is always > local - the reason we need to be able to support TLS for this connection > is because we connect to the same Remoting connector as remote clients > also used so once TLS is enabled it is enabled for all. > > Firstly I think it is worth exploring if there is anything else we can > do to automatically configure the client side of this connection without > requiring any additional configuration from the administrator. > > If we can identify the certificate the server will be using for the > connection there may be something we can do to send this to the > application server process so that it can instantiate a SunJSSE > compatible KeyStore and subsequently a SunJSSE TrustManager that will be > accepted into the SSLContext. > > When it comes to host controller and application server initialisation > those two processes are always guaranteed to be the same version so this > gives us some leeway on how the application server process is initially > configured. > > If that is not possible then an alternative is that to achieve a FIPS > mode compliant connection from the application server to the host > controller is going to require a custom configuration. The problem is > we do not have the management model available on the application server > at this time so we would probably still need a way to define it within > the host controller and convert it to a format that can be used on the > application server. In this case I don't think using the standard > system properties would be a good idea as existing installations could > already be relying on these elsewhere. > > If we needed to go down the custom configuration route then I would > suggest lack of configuration means stick with the current behaviour so > existing installations are unaffected leaving the configuration to be > set by those that do require it. > > If automatically obtaining the certificate is viable then that could be > used for all cases without breaking compatibility but additional > verification is probably needed there. > > Regards, > Darran Lofthouse. > > > >> On 19/11/15 10:25, Ryan Emerson wrote: >> Hello All, >> >> Currently domain mode is unable to execute when the JVM has FIPS enabled. See [1] for example config files and the resulting stacktrace. >> >> I am looking into this issue (SET engineer), however my current knowledge of core and FIPS is limited. What are your thoughts on how to implement FIPS compatibility? Is there any fundamental reasons why such a feature shouldn't be supported? >> >> [1] https://issues.jboss.org/browse/WFCORE-1135 >> >> Thanks >> Ryan >> _______________________________________________ >> 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 _______________________________________________ wildfly-dev mailing list wildfly-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev From brian.stansberry at redhat.com Thu Nov 19 10:50:41 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 19 Nov 2015 09:50:41 -0600 Subject: [wildfly-dev] Supporting FIPS in domain mode In-Reply-To: <690456102.15453402.1447928756296.JavaMail.zimbra@redhat.com> References: <1977413026.7907861.1447442465150.JavaMail.zimbra@redhat.com> <1767350107.13865039.1447494555396.JavaMail.zimbra@redhat.com> <1488409485.9384147.1447699158696.JavaMail.zimbra@redhat.com> <672151587.9650789.1447719510682.JavaMail.zimbra@redhat.com> <690456102.15453402.1447928756296.JavaMail.zimbra@redhat.com> Message-ID: <564DEFD1.9080702@redhat.com> Darran's the expert on this, but my initial naive question is whether this can be split into two logical use cases: 1) Where we know TLS is not going to be used on the HC<->server connection. 2) Where we don't know that. I ask because if case 2 is harder or requires changes that don't belong in a micro release (e.g. management model changes) perhaps we can first deal with case 1. My impression from the initial bug report is that SSL/TLS was not configured on the host's management interfaces. On 11/19/15 4:25 AM, Ryan Emerson wrote: > Hello All, > > Currently domain mode is unable to execute when the JVM has FIPS enabled. See [1] for example config files and the resulting stacktrace. > > I am looking into this issue (SET engineer), however my current knowledge of core and FIPS is limited. What are your thoughts on how to implement FIPS compatibility? Is there any fundamental reasons why such a feature shouldn't be supported? > > [1] https://issues.jboss.org/browse/WFCORE-1135 > > Thanks > Ryan > _______________________________________________ > 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 darran.lofthouse at jboss.com Thu Nov 19 11:07:44 2015 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Thu, 19 Nov 2015 16:07:44 +0000 Subject: [wildfly-dev] Supporting FIPS in domain mode In-Reply-To: <564DEFD1.9080702@redhat.com> References: <1977413026.7907861.1447442465150.JavaMail.zimbra@redhat.com> <1767350107.13865039.1447494555396.JavaMail.zimbra@redhat.com> <1488409485.9384147.1447699158696.JavaMail.zimbra@redhat.com> <672151587.9650789.1447719510682.JavaMail.zimbra@redhat.com> <690456102.15453402.1447928756296.JavaMail.zimbra@redhat.com> <564DEFD1.9080702@redhat.com> Message-ID: <564DF3D0.80400@jboss.com> On 19/11/15 15:50, Brian Stansberry wrote: > Darran's the expert on this, but my initial naive question is whether > this can be split into two logical use cases: > > 1) Where we know TLS is not going to be used on the HC<->server connection. > > 2) Where we don't know that. > > I ask because if case 2 is harder or requires changes that don't belong > in a micro release (e.g. management model changes) perhaps we can first > deal with case 1. My impression from the initial bug report is that > SSL/TLS was not configured on the host's management interfaces. To get to the error in the bug report the underlying user has taken these two steps: - 1 - Configure the JVM to be FIPS Compliant. 2 - Start a default domain configuration. They have experienced the error and reported it to us. I would be very surprised if they were not planning to subsequently enable TLS for the remote communication with the HostController. I suppose at a push master may have no application server instances but have TLS enable for remote communication and the individual slave host controllers only bind management to loopback so don't enable TLS. > > On 11/19/15 4:25 AM, Ryan Emerson wrote: >> Hello All, >> >> Currently domain mode is unable to execute when the JVM has FIPS enabled. See [1] for example config files and the resulting stacktrace. >> >> I am looking into this issue (SET engineer), however my current knowledge of core and FIPS is limited. What are your thoughts on how to implement FIPS compatibility? Is there any fundamental reasons why such a feature shouldn't be supported? >> >> [1] https://issues.jboss.org/browse/WFCORE-1135 >> >> Thanks >> Ryan >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > From brian.stansberry at redhat.com Thu Nov 19 11:38:26 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 19 Nov 2015 10:38:26 -0600 Subject: [wildfly-dev] Supporting FIPS in domain mode In-Reply-To: <564DF3D0.80400@jboss.com> References: <1977413026.7907861.1447442465150.JavaMail.zimbra@redhat.com> <1767350107.13865039.1447494555396.JavaMail.zimbra@redhat.com> <1488409485.9384147.1447699158696.JavaMail.zimbra@redhat.com> <672151587.9650789.1447719510682.JavaMail.zimbra@redhat.com> <690456102.15453402.1447928756296.JavaMail.zimbra@redhat.com> <564DEFD1.9080702@redhat.com> <564DF3D0.80400@jboss.com> Message-ID: <564DFB02.8000008@redhat.com> On 11/19/15 10:07 AM, Darran Lofthouse wrote: > On 19/11/15 15:50, Brian Stansberry wrote: >> Darran's the expert on this, but my initial naive question is whether >> this can be split into two logical use cases: >> >> 1) Where we know TLS is not going to be used on the HC<->server >> connection. >> >> 2) Where we don't know that. >> >> I ask because if case 2 is harder or requires changes that don't belong >> in a micro release (e.g. management model changes) perhaps we can first >> deal with case 1. My impression from the initial bug report is that >> SSL/TLS was not configured on the host's management interfaces. > > To get to the error in the bug report the underlying user has taken > these two steps: - > 1 - Configure the JVM to be FIPS Compliant. > 2 - Start a default domain configuration. > > They have experienced the error and reported it to us. > > I would be very surprised if they were not planning to subsequently > enable TLS for the remote communication with the HostController. > I can't say I disagree. :) > I suppose at a push master may have no application server instances but > have TLS enable for remote communication and the individual slave host > controllers only bind management to loopback so don't enable TLS. > With WildFly 9/10 the intra-domain comms can be running on a completely separate network from non-management stuff, so the possibility that traffic doesn't use TLS is a bit greater. But still not likely. In earlier versions this kind of setup is harder since CLI would talk to the DC over the same interface intra-domain comms use. With WF 9/10 the CLI could use HTTP Upgrade to talk to the DC on one network while intra-domain comms are on another network using the old native interface. >> >> On 11/19/15 4:25 AM, Ryan Emerson wrote: >>> Hello All, >>> >>> Currently domain mode is unable to execute when the JVM has FIPS >>> enabled. See [1] for example config files and the resulting stacktrace. >>> >>> I am looking into this issue (SET engineer), however my current >>> knowledge of core and FIPS is limited. What are your thoughts on how >>> to implement FIPS compatibility? Is there any fundamental reasons why >>> such a feature shouldn't be supported? >>> >>> [1] https://issues.jboss.org/browse/WFCORE-1135 >>> >>> Thanks >>> Ryan >>> _______________________________________________ >>> 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 vtunka at redhat.com Fri Nov 20 05:16:59 2015 From: vtunka at redhat.com (Vaclav Tunka) Date: Fri, 20 Nov 2015 11:16:59 +0100 Subject: [wildfly-dev] Supporting FIPS in domain mode In-Reply-To: <1285838309.15603850.1447941591158.JavaMail.zimbra@redhat.com> References: <1977413026.7907861.1447442465150.JavaMail.zimbra@redhat.com> <1767350107.13865039.1447494555396.JavaMail.zimbra@redhat.com> <1488409485.9384147.1447699158696.JavaMail.zimbra@redhat.com> <672151587.9650789.1447719510682.JavaMail.zimbra@redhat.com> <690456102.15453402.1447928756296.JavaMail.zimbra@redhat.com> <564DC583.1020503@jboss.com> <1285838309.15603850.1447941591158.JavaMail.zimbra@redhat.com> Message-ID: <564EF31B.3010007@redhat.com> Enabling the implementation itself to be "FIPS compliant" is just one part (although quite complicated itself), second part is the audit by a third party agency, lot of paperwork and lot of costs to be able to mark something as truly FIPS compliant. So this is definitely a big RFE. Ryan if you want to find out more, I suggest you get in touch with Jean-Frederic Clere - I tried to organize a call with platform developers about FIPS, not sure if that already happened. Cheers, Vaclav On 11/19/2015 02:59 PM, Ryan Emerson wrote: > This issue originated from a downstream customer issue (BZ now linked in JIRA), so there is some demand. Originally the intention was to try and backport the upstream fix, however as FIPS support now appears to be a complex RFE this may not be possible. > > ----- Original Message ----- > From: "Anil Saldanha" > To: "Darran Lofthouse" > Cc: wildfly-dev at lists.jboss.org > Sent: Thursday, 19 November, 2015 1:07:32 PM > Subject: Re: [wildfly-dev] Supporting FIPS in domain mode > > I agree with Darran that this is a complicated exercise that should be backed by a business demand. > > The potential for the feature -- if implemented -- to break in the long run is high -- if any custom configuration is involved. > >> On Nov 19, 2015, at 6:50 AM, Darran Lofthouse wrote: >> >> The problem with this issue is that it is going to be quite complex to >> solve, especially once we start to expand on all the scenarios we need >> to support. Add to that it becomes even more complex once we need to >> consider backwards compatibility. >> >> Generally the scenarios we need are: - >> - Using a FIPS configured JVM >> - Using a non-FIPS configured JVM >> Combined with: - >> - TLS enabled for the host controller connection. >> - TLS not enabled. >> >> Although the issue raised only talks about an error message for one we >> need to ensure we cover them all. >> >> Firstly the connection that is being talked about here is the connection >> from the individual application server process back to it's host >> controller all running on the same machine. The reason for the simple >> trusting solution is because although a connection is used it is always >> local - the reason we need to be able to support TLS for this connection >> is because we connect to the same Remoting connector as remote clients >> also used so once TLS is enabled it is enabled for all. >> >> Firstly I think it is worth exploring if there is anything else we can >> do to automatically configure the client side of this connection without >> requiring any additional configuration from the administrator. >> >> If we can identify the certificate the server will be using for the >> connection there may be something we can do to send this to the >> application server process so that it can instantiate a SunJSSE >> compatible KeyStore and subsequently a SunJSSE TrustManager that will be >> accepted into the SSLContext. >> >> When it comes to host controller and application server initialisation >> those two processes are always guaranteed to be the same version so this >> gives us some leeway on how the application server process is initially >> configured. >> >> If that is not possible then an alternative is that to achieve a FIPS >> mode compliant connection from the application server to the host >> controller is going to require a custom configuration. The problem is >> we do not have the management model available on the application server >> at this time so we would probably still need a way to define it within >> the host controller and convert it to a format that can be used on the >> application server. In this case I don't think using the standard >> system properties would be a good idea as existing installations could >> already be relying on these elsewhere. >> >> If we needed to go down the custom configuration route then I would >> suggest lack of configuration means stick with the current behaviour so >> existing installations are unaffected leaving the configuration to be >> set by those that do require it. >> >> If automatically obtaining the certificate is viable then that could be >> used for all cases without breaking compatibility but additional >> verification is probably needed there. >> >> Regards, >> Darran Lofthouse. >> >> >> >>> On 19/11/15 10:25, Ryan Emerson wrote: >>> Hello All, >>> >>> Currently domain mode is unable to execute when the JVM has FIPS enabled. See [1] for example config files and the resulting stacktrace. >>> >>> I am looking into this issue (SET engineer), however my current knowledge of core and FIPS is limited. What are your thoughts on how to implement FIPS compatibility? Is there any fundamental reasons why such a feature shouldn't be supported? >>> >>> [1] https://issues.jboss.org/browse/WFCORE-1135 >>> >>> Thanks >>> Ryan >>> _______________________________________________ >>> 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 > > _______________________________________________ > 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 -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4236 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151120/53461a41/attachment.bin From remerson at redhat.com Fri Nov 20 06:22:19 2015 From: remerson at redhat.com (Ryan Emerson) Date: Fri, 20 Nov 2015 06:22:19 -0500 (EST) Subject: [wildfly-dev] Supporting FIPS in domain mode In-Reply-To: <564EF31B.3010007@redhat.com> References: <1977413026.7907861.1447442465150.JavaMail.zimbra@redhat.com> <1488409485.9384147.1447699158696.JavaMail.zimbra@redhat.com> <672151587.9650789.1447719510682.JavaMail.zimbra@redhat.com> <690456102.15453402.1447928756296.JavaMail.zimbra@redhat.com> <564DC583.1020503@jboss.com> <1285838309.15603850.1447941591158.JavaMail.zimbra@redhat.com> <564EF31B.3010007@redhat.com> Message-ID: <771293085.16537609.1448018539894.JavaMail.zimbra@redhat.com> Thank you for all the input. Clearly this is a substantial RFE, which is unrealistic for backporting. I have update the original JIRA to reflect that this is a RFE. Thanks Ryan ----- Original Message ----- From: "Vaclav Tunka" To: "Ryan Emerson" Cc: wildfly-dev at lists.jboss.org, "Jean-Frederic" Sent: Friday, 20 November, 2015 10:16:59 AM Subject: Re: [wildfly-dev] Supporting FIPS in domain mode Enabling the implementation itself to be "FIPS compliant" is just one part (although quite complicated itself), second part is the audit by a third party agency, lot of paperwork and lot of costs to be able to mark something as truly FIPS compliant. So this is definitely a big RFE. Ryan if you want to find out more, I suggest you get in touch with Jean-Frederic Clere - I tried to organize a call with platform developers about FIPS, not sure if that already happened. Cheers, Vaclav On 11/19/2015 02:59 PM, Ryan Emerson wrote: > This issue originated from a downstream customer issue (BZ now linked in JIRA), so there is some demand. Originally the intention was to try and backport the upstream fix, however as FIPS support now appears to be a complex RFE this may not be possible. > > ----- Original Message ----- > From: "Anil Saldanha" > To: "Darran Lofthouse" > Cc: wildfly-dev at lists.jboss.org > Sent: Thursday, 19 November, 2015 1:07:32 PM > Subject: Re: [wildfly-dev] Supporting FIPS in domain mode > > I agree with Darran that this is a complicated exercise that should be backed by a business demand. > > The potential for the feature -- if implemented -- to break in the long run is high -- if any custom configuration is involved. > >> On Nov 19, 2015, at 6:50 AM, Darran Lofthouse wrote: >> >> The problem with this issue is that it is going to be quite complex to >> solve, especially once we start to expand on all the scenarios we need >> to support. Add to that it becomes even more complex once we need to >> consider backwards compatibility. >> >> Generally the scenarios we need are: - >> - Using a FIPS configured JVM >> - Using a non-FIPS configured JVM >> Combined with: - >> - TLS enabled for the host controller connection. >> - TLS not enabled. >> >> Although the issue raised only talks about an error message for one we >> need to ensure we cover them all. >> >> Firstly the connection that is being talked about here is the connection >> from the individual application server process back to it's host >> controller all running on the same machine. The reason for the simple >> trusting solution is because although a connection is used it is always >> local - the reason we need to be able to support TLS for this connection >> is because we connect to the same Remoting connector as remote clients >> also used so once TLS is enabled it is enabled for all. >> >> Firstly I think it is worth exploring if there is anything else we can >> do to automatically configure the client side of this connection without >> requiring any additional configuration from the administrator. >> >> If we can identify the certificate the server will be using for the >> connection there may be something we can do to send this to the >> application server process so that it can instantiate a SunJSSE >> compatible KeyStore and subsequently a SunJSSE TrustManager that will be >> accepted into the SSLContext. >> >> When it comes to host controller and application server initialisation >> those two processes are always guaranteed to be the same version so this >> gives us some leeway on how the application server process is initially >> configured. >> >> If that is not possible then an alternative is that to achieve a FIPS >> mode compliant connection from the application server to the host >> controller is going to require a custom configuration. The problem is >> we do not have the management model available on the application server >> at this time so we would probably still need a way to define it within >> the host controller and convert it to a format that can be used on the >> application server. In this case I don't think using the standard >> system properties would be a good idea as existing installations could >> already be relying on these elsewhere. >> >> If we needed to go down the custom configuration route then I would >> suggest lack of configuration means stick with the current behaviour so >> existing installations are unaffected leaving the configuration to be >> set by those that do require it. >> >> If automatically obtaining the certificate is viable then that could be >> used for all cases without breaking compatibility but additional >> verification is probably needed there. >> >> Regards, >> Darran Lofthouse. >> >> >> >>> On 19/11/15 10:25, Ryan Emerson wrote: >>> Hello All, >>> >>> Currently domain mode is unable to execute when the JVM has FIPS enabled. See [1] for example config files and the resulting stacktrace. >>> >>> I am looking into this issue (SET engineer), however my current knowledge of core and FIPS is limited. What are your thoughts on how to implement FIPS compatibility? Is there any fundamental reasons why such a feature shouldn't be supported? >>> >>> [1] https://issues.jboss.org/browse/WFCORE-1135 >>> >>> Thanks >>> Ryan >>> _______________________________________________ >>> 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 > > _______________________________________________ > 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 darran.lofthouse at jboss.com Fri Nov 20 10:58:38 2015 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Fri, 20 Nov 2015 15:58:38 +0000 Subject: [wildfly-dev] Supporting FIPS in domain mode In-Reply-To: <771293085.16537609.1448018539894.JavaMail.zimbra@redhat.com> References: <1977413026.7907861.1447442465150.JavaMail.zimbra@redhat.com> <1488409485.9384147.1447699158696.JavaMail.zimbra@redhat.com> <672151587.9650789.1447719510682.JavaMail.zimbra@redhat.com> <690456102.15453402.1447928756296.JavaMail.zimbra@redhat.com> <564DC583.1020503@jboss.com> <1285838309.15603850.1447941591158.JavaMail.zimbra@redhat.com> <564EF31B.3010007@redhat.com> <771293085.16537609.1448018539894.JavaMail.zimbra@redhat.com> Message-ID: <564F432E.4060807@jboss.com> Still thinking about the initial report a complete solution is seeming very ambitious at the moment. However an alternative option to overcome this specific error could be a new set of system properties to define how the SSLContext is assembled for the AS->HC connections. If these properties are set then they are used to create the stores, managers and resulting SSLContext - if not set we keep the existing behaviour. The risk however is that as this is FIPS related using system properties to contain anything sensitive is probably not an option. This does still leave the scenario of using a FIPS configured JVM but no TLS to the HostController although I am still inclined to believe that is more the edge case. Also note I am not considering the standard system properties for this as they may already be being used for another purpose within the application server process. Regards, Darran Lofthouse. On 20/11/15 11:22, Ryan Emerson wrote: > Thank you for all the input. Clearly this is a substantial RFE, which is unrealistic for backporting. > > I have update the original JIRA to reflect that this is a RFE. > > Thanks > Ryan > > ----- Original Message ----- > From: "Vaclav Tunka" > To: "Ryan Emerson" > Cc: wildfly-dev at lists.jboss.org, "Jean-Frederic" > Sent: Friday, 20 November, 2015 10:16:59 AM > Subject: Re: [wildfly-dev] Supporting FIPS in domain mode > > Enabling the implementation itself to be "FIPS compliant" is just one > part (although quite complicated itself), second part is the audit by a > third party agency, lot of paperwork and lot of costs to be able to mark > something as truly FIPS compliant. So this is definitely a big RFE. > > Ryan if you want to find out more, I suggest you get in touch with > Jean-Frederic Clere - I tried to organize a call with platform > developers about FIPS, not sure if that already happened. > > Cheers, > Vaclav > > On 11/19/2015 02:59 PM, Ryan Emerson wrote: >> This issue originated from a downstream customer issue (BZ now linked in JIRA), so there is some demand. Originally the intention was to try and backport the upstream fix, however as FIPS support now appears to be a complex RFE this may not be possible. >> >> ----- Original Message ----- >> From: "Anil Saldanha" >> To: "Darran Lofthouse" >> Cc: wildfly-dev at lists.jboss.org >> Sent: Thursday, 19 November, 2015 1:07:32 PM >> Subject: Re: [wildfly-dev] Supporting FIPS in domain mode >> >> I agree with Darran that this is a complicated exercise that should be backed by a business demand. >> >> The potential for the feature -- if implemented -- to break in the long run is high -- if any custom configuration is involved. >> >>> On Nov 19, 2015, at 6:50 AM, Darran Lofthouse wrote: >>> >>> The problem with this issue is that it is going to be quite complex to >>> solve, especially once we start to expand on all the scenarios we need >>> to support. Add to that it becomes even more complex once we need to >>> consider backwards compatibility. >>> >>> Generally the scenarios we need are: - >>> - Using a FIPS configured JVM >>> - Using a non-FIPS configured JVM >>> Combined with: - >>> - TLS enabled for the host controller connection. >>> - TLS not enabled. >>> >>> Although the issue raised only talks about an error message for one we >>> need to ensure we cover them all. >>> >>> Firstly the connection that is being talked about here is the connection >>> from the individual application server process back to it's host >>> controller all running on the same machine. The reason for the simple >>> trusting solution is because although a connection is used it is always >>> local - the reason we need to be able to support TLS for this connection >>> is because we connect to the same Remoting connector as remote clients >>> also used so once TLS is enabled it is enabled for all. >>> >>> Firstly I think it is worth exploring if there is anything else we can >>> do to automatically configure the client side of this connection without >>> requiring any additional configuration from the administrator. >>> >>> If we can identify the certificate the server will be using for the >>> connection there may be something we can do to send this to the >>> application server process so that it can instantiate a SunJSSE >>> compatible KeyStore and subsequently a SunJSSE TrustManager that will be >>> accepted into the SSLContext. >>> >>> When it comes to host controller and application server initialisation >>> those two processes are always guaranteed to be the same version so this >>> gives us some leeway on how the application server process is initially >>> configured. >>> >>> If that is not possible then an alternative is that to achieve a FIPS >>> mode compliant connection from the application server to the host >>> controller is going to require a custom configuration. The problem is >>> we do not have the management model available on the application server >>> at this time so we would probably still need a way to define it within >>> the host controller and convert it to a format that can be used on the >>> application server. In this case I don't think using the standard >>> system properties would be a good idea as existing installations could >>> already be relying on these elsewhere. >>> >>> If we needed to go down the custom configuration route then I would >>> suggest lack of configuration means stick with the current behaviour so >>> existing installations are unaffected leaving the configuration to be >>> set by those that do require it. >>> >>> If automatically obtaining the certificate is viable then that could be >>> used for all cases without breaking compatibility but additional >>> verification is probably needed there. >>> >>> Regards, >>> Darran Lofthouse. >>> >>> >>> >>>> On 19/11/15 10:25, Ryan Emerson wrote: >>>> Hello All, >>>> >>>> Currently domain mode is unable to execute when the JVM has FIPS enabled. See [1] for example config files and the resulting stacktrace. >>>> >>>> I am looking into this issue (SET engineer), however my current knowledge of core and FIPS is limited. What are your thoughts on how to implement FIPS compatibility? Is there any fundamental reasons why such a feature shouldn't be supported? >>>> >>>> [1] https://issues.jboss.org/browse/WFCORE-1135 >>>> >>>> Thanks >>>> Ryan >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> 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 >> > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From lgao at redhat.com Mon Nov 23 05:13:01 2015 From: lgao at redhat.com (Lin Gao) Date: Mon, 23 Nov 2015 05:13:01 -0500 (EST) Subject: [wildfly-dev] Shall we limit size of the deployment in WildFly? In-Reply-To: <563A2267.7010307@jboss.com> References: <24706283.2168206.1446540061297.JavaMail.zimbra@redhat.com> <5638B46A.9050103@redhat.com> <432170035.3201449.1446599629356.JavaMail.zimbra@redhat.com> <556E0C61-5F39-4557-B640-4035474E8563@redhat.com> <563A1847.6010309@redhat.com> <54988A69-18D3-4FAB-A5E6-5F3F47D8D6A6@redhat.com> <563A2267.7010307@jboss.com> Message-ID: <1363464938.20570303.1448273581200.JavaMail.zimbra@redhat.com> >From what I learned of this thread, a service to expose the file system space availability needs to be implemented first, then provides a way to check whether the server locations("data") have enough disk spaces to store the uploaded file. Should we create a Jira for this? :-) Best Regards -- Lin Gao Software Engineer JBoss by Red Hat ----- Original Message ----- > From: "Darran Lofthouse" > To: "Jason T. Greene" , "Tristan Tarrant" > Cc: wildfly-dev at lists.jboss.org > Sent: Wednesday, November 4, 2015 11:21:11 PM > Subject: Re: [wildfly-dev] Shall we limit size of the deployment in WildFly? > > This would also be something ideal to report on in the "administrator > encouragement" service I keep meaning to look into again ;-) > > On 04/11/15 15:02, Jason T. Greene wrote: > > Yes that would be very clear cut and easy to do. > > > >> On Nov 4, 2015, at 8:38 AM, Tristan Tarrant wrote: > >> > >> While we're on filesystem space availability, for monitoring purposes, > >> would it be possible to expose this as a runtime metric for known server > >> locations (data, tmp, logs) ? > >> > >> Tristan > >> > >>> On 04/11/2015 13:37, Jason T. Greene wrote: > >>> On Nov 3, 2015, at 7:14 PM, Lin Gao wrote: > >>> > >>>>>> On 11/03/2015 02:41 AM, Lin Gao wrote: > >>>>>> Hi, > >>>>>> > >>>>>> WildFly does not limit the deployment file size, users with > >>>>>> appropriate > >>>>>> privilege(deployer) can select any file to deploy from both CLI and > >>>>>> web > >>>>>> console. > >>>>>> > >>>>>> For the too big file, it may exhaust all available disk space, and > >>>>>> in > >>>>>> some cases, even small file can exhaust the disk space if the > >>>>>> current > >>>>>> disk space is not big enough. > >>>>>> > >>>>>> So shall we limit file size of the deployment in WildFly? or shall > >>>>>> we > >>>>>> limit the available disk space? or shall we just show a warning > >>>>>> message > >>>>>> to users? > >>>>>> > >>>>>> If we do, where in the management API configuration for this should > >>>>>> be > >>>>>> done, if it is done this way? > >>>>>> > >>>>>> Arbitrary limits will break users, so if we have an arbitrary limit > >>>>>> it > >>>>>> needs to be easily adjusted. > >>>>>> > >>>>>> In case of domain mode, different hosts may have different disk > >>>>>> space, > >>>>>> which means they are likely have different capacity to hold > >>>>>> deployment > >>>>>> files. For example, servers in server-group-A may have 2GB > >>>>>> available > >>>>>> disk space, servers in server-group-B may have 200MB available disk > >>>>>> space. An unified limit for the whole domain seems not fair for the > >>>>>> servers with more available disk space. > >>>>>> > >>>>>> Also, WildFly does not limit type of the deployment file, but it > >>>>>> might > >>>>>> need a separate discussion if necessary? > >>>>>> > >>>>>> Any thoughts? > >>>>> > >>>>> Is this in response to a real observed problem? > >>>> > >>>> Yes it is. > >>> > >>> My understanding was that this was reported by a user but it was reported > >>> as something they were concerned with, and not actually something that > >>> was occurring in their environment. > >>> > >>> I agree with David that disk quotas on the processing running the app > >>> server is the most appropriate solution to prevent interference with > >>> other processes. > >>> > >>> I do not think we should have a hard coded limit as a constant because > >>> that will prevent legit deployments from working, and you can still run > >>> out of disk space (e.g you have 20k left and you upload a 21k > >>> deployment, which is under 1G) > >>> > >>> We could have an extra check that verifies enough disk space in the add > >>> content management op, however Java does not give us access to quota > >>> information so the best we could do is only verify available disk space > >>> (unless we exec a command for every platform we support). > >>> > >>> IMO this one is pretty low priority, but perhaps those that monitor this > >>> list see it as a need. If so can you speak up? > >>> > >>> > >>> > >>>> > >>>>> In general, if the user > >>>>> doesn't have space for a deployment, the deployment will fail with an > >>>>> error and (I am fairly certain) will delete the partial deployment. If > >>>>> there is space, then the deployment will succeed regardless of size. > >>>> > >>>>> It's interesting that the JIRA you reference speaks in terms of > >>>>> security. If an admin wants to lock down storage space, it's probably > >>>>> best to do it at the operating system level using e.g. disk quotas - > >>>>> there are too many ways to get the application server to write > >>>>> arbitrary > >>>>> amounts of data to the file system, regardless of the presence of a > >>>>> security manager or any other application-level control. > >>>>> > >>>>> I'm pretty sure that if an attacker has permission to upload > >>>>> deployments > >>>>> to the server, they already essentially have control over the server. > >>>>> This should be an OS level concern. > >>>> > >>>> The JIRA in question was a 'bug' related to security at first, after > >>>> several > >>>> rounds of discussion, it is agreed that it is not a security > >>>> vulnerability, but > >>>> an 'Enhancement'. > >>>> > >>>> The proposed requirement for the enhancement is: > >>>> > >>>> Provide an option in config to alert user that > >>>> a) File is larger than a configurable limit > >>>> b) File type is/is not valid. > >>>> > >>>> but it may need more discussion in community on both the requirement and > >>>> design > >>>> if it will be done, that is why this thread comes out in first place. > >>>> :-) > >>>> > >>>>>> FYI: https://issues.jboss.org/browse/WFCORE-1057 > >>>> > >>>> Best Regards > >>>> -- > >>>> Lin Gao > >>>> Software Engineer > >>>> JBoss by 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 > >> > >> -- > >> Tristan Tarrant > >> Infinispan Lead > >> 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 > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From brian.stansberry at redhat.com Mon Nov 23 16:02:55 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 23 Nov 2015 15:02:55 -0600 Subject: [wildfly-dev] Best practices for management API text descriptions Message-ID: <56537EFF.9050704@redhat.com> This thread is to flesh out some thinking about best practices for the content of the free form text descriptions of the resources, attributes and operations in the WildFly management model. Red Hat's user experience team has been looking at some of the text in the admin console, much of which comes from the server side management API descriptions. As they start pinging subsystem authors looking for improvements, I think it will be helpful if we use this thread to come to some consensus around best practices. There is a lot of information provided by the server about the management API, going well beyond free form text descriptions. I encourage people to review [1] and particularly sections [2] and [3]. Any management client that tries to read the text description of, say, an attribute will automatically get the other descriptive data as well. Type information, whether a value is required, legal values, affect on the runtime of changing an attribute, etc. Because the full set of descriptive data is available to a tool whenever the text is, IMHO it makes sense *in general* to avoid repeating information in the free form text that is already available elsewhere in the descriptive data[4], for a number of reasons: 1) Whether or not particular bits of info will be added to the free form text will be inconsistent, depending on what an author chose to do. 2) The language quality of the free form text will vary widely. 3) The size of our metadata payloads is already a concern. Duplicating data by putting it in free form text increases this problem. 4) Duplicating data leads to maintenance troubles when details change, since now the information needs to be updated in two places. 5) People doing localization need to translate more text. Instead of duplicating data in the free form text, we're better off looking into how our standard clients (admin console, CLI, JConsole plugin) can best present the information present in the other descriptor fields. For example, put a '*' next to required fields in a graphical UI. (I think there's a HAL JIRA for that one!) In some cases the right answer for a UI is to show a chunk of text, e.g. in a tooltip. But even there I think the best way to show standard info is to append standardized text to the free form text provided by the server. So, if some attribute "max-size" has restart-required=all-services and the free form text for "max-size" reads "The maximum number of threads in the pool", then the console could generate a tool tip that reads: The maximum number of threads in the pool. Servers must be reloaded for changes to take effect. I think this kind of approach can work well for the "nillable", "expressions-allowed", "min", "max", "default", "alternatives", "requires" and "restart-required" descriptors. For the "allowed" descriptor, the only reason to include the allowed values in the free form text is if the meaning of the legal values isn't clear and the free form text includes some explanation. Otherwise, a UI can already use the "allowed" descriptor to show the legal values, e.g. via a pull down in a GUI or tab completion in the CLI. I'm not advocating we go off on a major expedition to change our existing text. I do however want to avoid us adhoc adding a lot of duplicate text, unless we come to a consensus that that's the best approach. [1] https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-DescriptionoftheManagementModel [2] https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-DescriptionofanAttribute [3] https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-ArbitraryDescriptors [4] For example, the "restart-required" descriptor on an attribute indicates what must happen for a change to the attribute to take effect. So including "The server must be reloaded for a change to take effect" in the free form text is duplication. -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From brian.stansberry at redhat.com Mon Nov 23 18:51:28 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 23 Nov 2015 17:51:28 -0600 Subject: [wildfly-dev] Shall we limit size of the deployment in WildFly? In-Reply-To: <1363464938.20570303.1448273581200.JavaMail.zimbra@redhat.com> References: <24706283.2168206.1446540061297.JavaMail.zimbra@redhat.com> <5638B46A.9050103@redhat.com> <432170035.3201449.1446599629356.JavaMail.zimbra@redhat.com> <556E0C61-5F39-4557-B640-4035474E8563@redhat.com> <563A1847.6010309@redhat.com> <54988A69-18D3-4FAB-A5E6-5F3F47D8D6A6@redhat.com> <563A2267.7010307@jboss.com> <1363464938.20570303.1448273581200.JavaMail.zimbra@redhat.com> Message-ID: <5653A680.7080603@redhat.com> A WFCORE JIRA for Tristan's specific request would be good. I don't think the discussion on this thread is close enough to a consensus on how to practically use this data in handling deployment ops for it to be useful to bring that aspect into a JIRA. On 11/23/15 4:13 AM, Lin Gao wrote: >>From what I learned of this thread, a service to expose the file system space availability > needs to be implemented first, then provides a way to check whether the server locations("data") > have enough disk spaces to store the uploaded file. > > Should we create a Jira for this? :-) > > Best Regards > -- > Lin Gao > Software Engineer > JBoss by Red Hat > > ----- Original Message ----- >> From: "Darran Lofthouse" >> To: "Jason T. Greene" , "Tristan Tarrant" >> Cc: wildfly-dev at lists.jboss.org >> Sent: Wednesday, November 4, 2015 11:21:11 PM >> Subject: Re: [wildfly-dev] Shall we limit size of the deployment in WildFly? >> >> This would also be something ideal to report on in the "administrator >> encouragement" service I keep meaning to look into again ;-) >> >> On 04/11/15 15:02, Jason T. Greene wrote: >>> Yes that would be very clear cut and easy to do. >>> >>>> On Nov 4, 2015, at 8:38 AM, Tristan Tarrant wrote: >>>> >>>> While we're on filesystem space availability, for monitoring purposes, >>>> would it be possible to expose this as a runtime metric for known server >>>> locations (data, tmp, logs) ? >>>> >>>> Tristan >>>> >>>>> On 04/11/2015 13:37, Jason T. Greene wrote: >>>>> On Nov 3, 2015, at 7:14 PM, Lin Gao wrote: >>>>> >>>>>>>> On 11/03/2015 02:41 AM, Lin Gao wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> WildFly does not limit the deployment file size, users with >>>>>>>> appropriate >>>>>>>> privilege(deployer) can select any file to deploy from both CLI and >>>>>>>> web >>>>>>>> console. >>>>>>>> >>>>>>>> For the too big file, it may exhaust all available disk space, and >>>>>>>> in >>>>>>>> some cases, even small file can exhaust the disk space if the >>>>>>>> current >>>>>>>> disk space is not big enough. >>>>>>>> >>>>>>>> So shall we limit file size of the deployment in WildFly? or shall >>>>>>>> we >>>>>>>> limit the available disk space? or shall we just show a warning >>>>>>>> message >>>>>>>> to users? >>>>>>>> >>>>>>>> If we do, where in the management API configuration for this should >>>>>>>> be >>>>>>>> done, if it is done this way? >>>>>>>> >>>>>>>> Arbitrary limits will break users, so if we have an arbitrary limit >>>>>>>> it >>>>>>>> needs to be easily adjusted. >>>>>>>> >>>>>>>> In case of domain mode, different hosts may have different disk >>>>>>>> space, >>>>>>>> which means they are likely have different capacity to hold >>>>>>>> deployment >>>>>>>> files. For example, servers in server-group-A may have 2GB >>>>>>>> available >>>>>>>> disk space, servers in server-group-B may have 200MB available disk >>>>>>>> space. An unified limit for the whole domain seems not fair for the >>>>>>>> servers with more available disk space. >>>>>>>> >>>>>>>> Also, WildFly does not limit type of the deployment file, but it >>>>>>>> might >>>>>>>> need a separate discussion if necessary? >>>>>>>> >>>>>>>> Any thoughts? >>>>>>> >>>>>>> Is this in response to a real observed problem? >>>>>> >>>>>> Yes it is. >>>>> >>>>> My understanding was that this was reported by a user but it was reported >>>>> as something they were concerned with, and not actually something that >>>>> was occurring in their environment. >>>>> >>>>> I agree with David that disk quotas on the processing running the app >>>>> server is the most appropriate solution to prevent interference with >>>>> other processes. >>>>> >>>>> I do not think we should have a hard coded limit as a constant because >>>>> that will prevent legit deployments from working, and you can still run >>>>> out of disk space (e.g you have 20k left and you upload a 21k >>>>> deployment, which is under 1G) >>>>> >>>>> We could have an extra check that verifies enough disk space in the add >>>>> content management op, however Java does not give us access to quota >>>>> information so the best we could do is only verify available disk space >>>>> (unless we exec a command for every platform we support). >>>>> >>>>> IMO this one is pretty low priority, but perhaps those that monitor this >>>>> list see it as a need. If so can you speak up? >>>>> >>>>> >>>>> >>>>>> >>>>>>> In general, if the user >>>>>>> doesn't have space for a deployment, the deployment will fail with an >>>>>>> error and (I am fairly certain) will delete the partial deployment. If >>>>>>> there is space, then the deployment will succeed regardless of size. >>>>>> >>>>>>> It's interesting that the JIRA you reference speaks in terms of >>>>>>> security. If an admin wants to lock down storage space, it's probably >>>>>>> best to do it at the operating system level using e.g. disk quotas - >>>>>>> there are too many ways to get the application server to write >>>>>>> arbitrary >>>>>>> amounts of data to the file system, regardless of the presence of a >>>>>>> security manager or any other application-level control. >>>>>>> >>>>>>> I'm pretty sure that if an attacker has permission to upload >>>>>>> deployments >>>>>>> to the server, they already essentially have control over the server. >>>>>>> This should be an OS level concern. >>>>>> >>>>>> The JIRA in question was a 'bug' related to security at first, after >>>>>> several >>>>>> rounds of discussion, it is agreed that it is not a security >>>>>> vulnerability, but >>>>>> an 'Enhancement'. >>>>>> >>>>>> The proposed requirement for the enhancement is: >>>>>> >>>>>> Provide an option in config to alert user that >>>>>> a) File is larger than a configurable limit >>>>>> b) File type is/is not valid. >>>>>> >>>>>> but it may need more discussion in community on both the requirement and >>>>>> design >>>>>> if it will be done, that is why this thread comes out in first place. >>>>>> :-) >>>>>> >>>>>>>> FYI: https://issues.jboss.org/browse/WFCORE-1057 >>>>>> >>>>>> Best Regards >>>>>> -- >>>>>> Lin Gao >>>>>> Software Engineer >>>>>> JBoss by 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 >>>> >>>> -- >>>> Tristan Tarrant >>>> Infinispan Lead >>>> 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 >>> >> _______________________________________________ >> 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 > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From ttarrant at redhat.com Tue Nov 24 02:43:57 2015 From: ttarrant at redhat.com (Tristan Tarrant) Date: Tue, 24 Nov 2015 08:43:57 +0100 Subject: [wildfly-dev] Shall we limit size of the deployment in WildFly? In-Reply-To: <5653A680.7080603@redhat.com> References: <24706283.2168206.1446540061297.JavaMail.zimbra@redhat.com> <5638B46A.9050103@redhat.com> <432170035.3201449.1446599629356.JavaMail.zimbra@redhat.com> <556E0C61-5F39-4557-B640-4035474E8563@redhat.com> <563A1847.6010309@redhat.com> <54988A69-18D3-4FAB-A5E6-5F3F47D8D6A6@redhat.com> <563A2267.7010307@jboss.com> <1363464938.20570303.1448273581200.JavaMail.zimbra@redhat.com> <5653A680.7080603@redhat.com> Message-ID: <5654153D.60205@redhat.com> https://issues.jboss.org/browse/WFCORE-1159 Tristan On 24/11/2015 00:51, Brian Stansberry wrote: > A WFCORE JIRA for Tristan's specific request would be good. > > I don't think the discussion on this thread is close enough to a > consensus on how to practically use this data in handling deployment ops > for it to be useful to bring that aspect into a JIRA. > > > On 11/23/15 4:13 AM, Lin Gao wrote: >> >From what I learned of this thread, a service to expose the file system space availability >> needs to be implemented first, then provides a way to check whether the server locations("data") >> have enough disk spaces to store the uploaded file. >> >> Should we create a Jira for this? :-) >> >> Best Regards >> -- >> Lin Gao >> Software Engineer >> JBoss by Red Hat >> >> ----- Original Message ----- >>> From: "Darran Lofthouse" >>> To: "Jason T. Greene" , "Tristan Tarrant" >>> Cc: wildfly-dev at lists.jboss.org >>> Sent: Wednesday, November 4, 2015 11:21:11 PM >>> Subject: Re: [wildfly-dev] Shall we limit size of the deployment in WildFly? >>> >>> This would also be something ideal to report on in the "administrator >>> encouragement" service I keep meaning to look into again ;-) >>> >>> On 04/11/15 15:02, Jason T. Greene wrote: >>>> Yes that would be very clear cut and easy to do. >>>> >>>>> On Nov 4, 2015, at 8:38 AM, Tristan Tarrant wrote: >>>>> >>>>> While we're on filesystem space availability, for monitoring purposes, >>>>> would it be possible to expose this as a runtime metric for known server >>>>> locations (data, tmp, logs) ? >>>>> >>>>> Tristan >>>>> >>>>>> On 04/11/2015 13:37, Jason T. Greene wrote: >>>>>> On Nov 3, 2015, at 7:14 PM, Lin Gao wrote: >>>>>> >>>>>>>>> On 11/03/2015 02:41 AM, Lin Gao wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> WildFly does not limit the deployment file size, users with >>>>>>>>> appropriate >>>>>>>>> privilege(deployer) can select any file to deploy from both CLI and >>>>>>>>> web >>>>>>>>> console. >>>>>>>>> >>>>>>>>> For the too big file, it may exhaust all available disk space, and >>>>>>>>> in >>>>>>>>> some cases, even small file can exhaust the disk space if the >>>>>>>>> current >>>>>>>>> disk space is not big enough. >>>>>>>>> >>>>>>>>> So shall we limit file size of the deployment in WildFly? or shall >>>>>>>>> we >>>>>>>>> limit the available disk space? or shall we just show a warning >>>>>>>>> message >>>>>>>>> to users? >>>>>>>>> >>>>>>>>> If we do, where in the management API configuration for this should >>>>>>>>> be >>>>>>>>> done, if it is done this way? >>>>>>>>> >>>>>>>>> Arbitrary limits will break users, so if we have an arbitrary limit >>>>>>>>> it >>>>>>>>> needs to be easily adjusted. >>>>>>>>> >>>>>>>>> In case of domain mode, different hosts may have different disk >>>>>>>>> space, >>>>>>>>> which means they are likely have different capacity to hold >>>>>>>>> deployment >>>>>>>>> files. For example, servers in server-group-A may have 2GB >>>>>>>>> available >>>>>>>>> disk space, servers in server-group-B may have 200MB available disk >>>>>>>>> space. An unified limit for the whole domain seems not fair for the >>>>>>>>> servers with more available disk space. >>>>>>>>> >>>>>>>>> Also, WildFly does not limit type of the deployment file, but it >>>>>>>>> might >>>>>>>>> need a separate discussion if necessary? >>>>>>>>> >>>>>>>>> Any thoughts? >>>>>>>> >>>>>>>> Is this in response to a real observed problem? >>>>>>> >>>>>>> Yes it is. >>>>>> >>>>>> My understanding was that this was reported by a user but it was reported >>>>>> as something they were concerned with, and not actually something that >>>>>> was occurring in their environment. >>>>>> >>>>>> I agree with David that disk quotas on the processing running the app >>>>>> server is the most appropriate solution to prevent interference with >>>>>> other processes. >>>>>> >>>>>> I do not think we should have a hard coded limit as a constant because >>>>>> that will prevent legit deployments from working, and you can still run >>>>>> out of disk space (e.g you have 20k left and you upload a 21k >>>>>> deployment, which is under 1G) >>>>>> >>>>>> We could have an extra check that verifies enough disk space in the add >>>>>> content management op, however Java does not give us access to quota >>>>>> information so the best we could do is only verify available disk space >>>>>> (unless we exec a command for every platform we support). >>>>>> >>>>>> IMO this one is pretty low priority, but perhaps those that monitor this >>>>>> list see it as a need. If so can you speak up? >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>>> In general, if the user >>>>>>>> doesn't have space for a deployment, the deployment will fail with an >>>>>>>> error and (I am fairly certain) will delete the partial deployment. If >>>>>>>> there is space, then the deployment will succeed regardless of size. >>>>>>> >>>>>>>> It's interesting that the JIRA you reference speaks in terms of >>>>>>>> security. If an admin wants to lock down storage space, it's probably >>>>>>>> best to do it at the operating system level using e.g. disk quotas - >>>>>>>> there are too many ways to get the application server to write >>>>>>>> arbitrary >>>>>>>> amounts of data to the file system, regardless of the presence of a >>>>>>>> security manager or any other application-level control. >>>>>>>> >>>>>>>> I'm pretty sure that if an attacker has permission to upload >>>>>>>> deployments >>>>>>>> to the server, they already essentially have control over the server. >>>>>>>> This should be an OS level concern. >>>>>>> >>>>>>> The JIRA in question was a 'bug' related to security at first, after >>>>>>> several >>>>>>> rounds of discussion, it is agreed that it is not a security >>>>>>> vulnerability, but >>>>>>> an 'Enhancement'. >>>>>>> >>>>>>> The proposed requirement for the enhancement is: >>>>>>> >>>>>>> Provide an option in config to alert user that >>>>>>> a) File is larger than a configurable limit >>>>>>> b) File type is/is not valid. >>>>>>> >>>>>>> but it may need more discussion in community on both the requirement and >>>>>>> design >>>>>>> if it will be done, that is why this thread comes out in first place. >>>>>>> :-) >>>>>>> >>>>>>>>> FYI: https://issues.jboss.org/browse/WFCORE-1057 >>>>>>> >>>>>>> Best Regards >>>>>>> -- >>>>>>> Lin Gao >>>>>>> Software Engineer >>>>>>> JBoss by 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 >>>>> >>>>> -- >>>>> Tristan Tarrant >>>>> Infinispan Lead >>>>> 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 >>>> >>> _______________________________________________ >>> 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 >> > > -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat From fruehbeck at aon.at Tue Nov 24 17:33:40 2015 From: fruehbeck at aon.at (=?UTF-8?Q?Thomas_Fr=c3=bchbeck?=) Date: Tue, 24 Nov 2015 23:33:40 +0100 Subject: [wildfly-dev] Problem remoting connection with wildfly 10.0.0.CR4 Message-ID: <5654E5C4.3020008@aon.at> Hi, I wanted to experiment with Wildfly 10.0.0.CR4 and Remoting and got the followin error on client side. I know, that my client works perfectly with 9.0.2.Final. Can you guide me to the relevant changes, is this a known problem? WARN: Could not register a EJB receiver for connection to localhost:8080 java.lang.RuntimeException: java.io.IOException: For now upgrade responses must have a content length of zero. at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:92) at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:77) at org.jboss.ejb.client.remoting.RemotingConnectionManager.getConnection(RemotingConnectionManager.java:51) at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.setupEJBReceivers(ConfigBasedEJBClientContextSelector.java:155) at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.getCurrent(ConfigBasedEJBClientContextSelector.java:115) at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.getCurrent(ConfigBasedEJBClientContextSelector.java:47) at org.jboss.ejb.client.EJBClientContext.getCurrent(EJBClientContext.java:271) at org.jboss.ejb.client.EJBClientContext.requireCurrent(EJBClientContext.java:281) at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:200) at org.jboss.ejb.client.naming.ejb.EjbNamingContext.doCreateProxy(EjbNamingContext.java:216) at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:193) at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:176) at javax.naming.InitialContext.lookup(InitialContext.java:417) Thanks, Thomas From eduardo.santanadasilva at gmail.com Tue Nov 24 19:30:37 2015 From: eduardo.santanadasilva at gmail.com (=?UTF-8?Q?Eduardo_Sant=C2=B4Ana_da_Silva?=) Date: Tue, 24 Nov 2015 22:30:37 -0200 Subject: [wildfly-dev] Problem remoting connection with wildfly 10.0.0.CR4 In-Reply-To: <5654E5C4.3020008@aon.at> References: <5654E5C4.3020008@aon.at> Message-ID: Maybe this could help: https://issues.jboss.org/browse/XNIO-222 2015-11-24 20:33 GMT-02:00 Thomas Fr?hbeck : > Hi, > I wanted to experiment with Wildfly 10.0.0.CR4 and Remoting and got the > followin error on client side. I know, that my client works perfectly > with 9.0.2.Final. > Can you guide me to the relevant changes, is this a known problem? > > WARN: Could not register a EJB receiver for connection to localhost:8080 > java.lang.RuntimeException: java.io.IOException: For now upgrade > responses must have a content length of zero. > at > org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:92) > at > > org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:77) > at > > org.jboss.ejb.client.remoting.RemotingConnectionManager.getConnection(RemotingConnectionManager.java:51) > at > > org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.setupEJBReceivers(ConfigBasedEJBClientContextSelector.java:155) > at > > org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.getCurrent(ConfigBasedEJBClientContextSelector.java:115) > at > > org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.getCurrent(ConfigBasedEJBClientContextSelector.java:47) > at > org.jboss.ejb.client.EJBClientContext.getCurrent(EJBClientContext.java:271) > at > > org.jboss.ejb.client.EJBClientContext.requireCurrent(EJBClientContext.java:281) > at > org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:200) > at > > org.jboss.ejb.client.naming.ejb.EjbNamingContext.doCreateProxy(EjbNamingContext.java:216) > at > > org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:193) > at > > org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:176) > at javax.naming.InitialContext.lookup(InitialContext.java:417) > > Thanks, > Thomas > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- __________________________ Eduardo Sant'Ana da Silva - Dr. Pesquisador / Consultor de TI -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151124/171f3c21/attachment.html From fruehbeck at aon.at Tue Nov 24 19:34:35 2015 From: fruehbeck at aon.at (=?UTF-8?Q?Thomas_Fr=c3=bchbeck?=) Date: Wed, 25 Nov 2015 01:34:35 +0100 Subject: [wildfly-dev] Problem remoting connection with wildfly 10.0.0.CR4 In-Reply-To: References: <5654E5C4.3020008@aon.at> Message-ID: <5655021B.1070205@aon.at> you nailed it, thanks! unfortunate though :-/ Am 25.11.2015 um 01:30 schrieb Eduardo Sant?Ana da Silva: > Maybe this could help: > > https://issues.jboss.org/browse/XNIO-222 > > > 2015-11-24 20:33 GMT-02:00 Thomas Fr?hbeck >: > > Hi, > I wanted to experiment with Wildfly 10.0.0.CR4 and Remoting and > got the > followin error on client side. I know, that my client works perfectly > with 9.0.2.Final. > Can you guide me to the relevant changes, is this a known problem? > > WARN: Could not register a EJB receiver for connection to > localhost:8080 > java.lang.RuntimeException: java.io.IOException: For now upgrade > responses must have a content length of zero. > at > org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:92) > at > org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:77) > at > org.jboss.ejb.client.remoting.RemotingConnectionManager.getConnection(RemotingConnectionManager.java:51) > at > org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.setupEJBReceivers(ConfigBasedEJBClientContextSelector.java:155) > at > org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.getCurrent(ConfigBasedEJBClientContextSelector.java:115) > at > org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.getCurrent(ConfigBasedEJBClientContextSelector.java:47) > at > org.jboss.ejb.client.EJBClientContext.getCurrent(EJBClientContext.java:271) > at > org.jboss.ejb.client.EJBClientContext.requireCurrent(EJBClientContext.java:281) > at > org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:200) > at > org.jboss.ejb.client.naming.ejb.EjbNamingContext.doCreateProxy(EjbNamingContext.java:216) > at > org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:193) > at > org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:176) > at > javax.naming.InitialContext.lookup(InitialContext.java:417) > > Thanks, > Thomas > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > -- > __________________________ > Eduardo Sant'Ana da Silva - Dr. > Pesquisador / Consultor de TI > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151125/387f587b/attachment-0001.html From eduardo.santanadasilva at gmail.com Tue Nov 24 19:59:48 2015 From: eduardo.santanadasilva at gmail.com (=?UTF-8?Q?Eduardo_Sant=C2=B4Ana_da_Silva?=) Date: Tue, 24 Nov 2015 22:59:48 -0200 Subject: [wildfly-dev] Problem remoting connection with wildfly 10.0.0.CR4 In-Reply-To: <5655021B.1070205@aon.at> References: <5654E5C4.3020008@aon.at> <5655021B.1070205@aon.at> Message-ID: Could you send your client pom.xml? Thx 2015-11-24 22:34 GMT-02:00 Thomas Fr?hbeck : > you nailed it, thanks! > unfortunate though :-/ > > > Am 25.11.2015 um 01:30 schrieb Eduardo Sant?Ana da Silva: > > Maybe this could help: > > https://issues.jboss.org/browse/XNIO-222 > > > 2015-11-24 20:33 GMT-02:00 Thomas Fr?hbeck : > >> Hi, >> I wanted to experiment with Wildfly 10.0.0.CR4 and Remoting and got the >> followin error on client side. I know, that my client works perfectly >> with 9.0.2.Final. >> Can you guide me to the relevant changes, is this a known problem? >> >> WARN: Could not register a EJB receiver for connection to localhost:8080 >> java.lang.RuntimeException: java.io.IOException: For now upgrade >> responses must have a content length of zero. >> at >> org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:92) >> at >> >> org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:77) >> at >> >> org.jboss.ejb.client.remoting.RemotingConnectionManager.getConnection(RemotingConnectionManager.java:51) >> at >> >> org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.setupEJBReceivers(ConfigBasedEJBClientContextSelector.java:155) >> at >> >> org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.getCurrent(ConfigBasedEJBClientContextSelector.java:115) >> at >> >> org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.getCurrent(ConfigBasedEJBClientContextSelector.java:47) >> at >> >> org.jboss.ejb.client.EJBClientContext.getCurrent(EJBClientContext.java:271) >> at >> >> org.jboss.ejb.client.EJBClientContext.requireCurrent(EJBClientContext.java:281) >> at >> org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:200) >> at >> >> org.jboss.ejb.client.naming.ejb.EjbNamingContext.doCreateProxy(EjbNamingContext.java:216) >> at >> >> org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:193) >> at >> >> org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:176) >> at javax.naming.InitialContext.lookup(InitialContext.java:417) >> >> Thanks, >> Thomas >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > > > -- > __________________________ > Eduardo Sant'Ana da Silva - Dr. > Pesquisador / Consultor de TI > > > -- __________________________ Eduardo Sant'Ana da Silva - Dr. Pesquisador / Consultor de TI -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151124/059e896e/attachment.html From eduardo.santanadasilva at gmail.com Tue Nov 24 20:11:28 2015 From: eduardo.santanadasilva at gmail.com (Eduardo Sant'Ana da Silva) Date: Tue, 24 Nov 2015 23:11:28 -0200 Subject: [wildfly-dev] Problem remoting connection with wildfly 10.0.0.CR4 In-Reply-To: <5655021B.1070205@aon.at> References: <5654E5C4.3020008@aon.at> <5655021B.1070205@aon.at> Message-ID: <4CFB6B4F-6BA4-4718-B0E3-2B16B8510BE4@gmail.com> Jason G. commented out XNIO-222 to see the spec about the content-lenght. I found this: https://tools.ietf.org/html/rfc7118 Each SIP message MUST be carried within a single WebSocket message, and a WebSocket message MUST NOT contain more than one SIP message. Because the WebSocket transport preserves message boundaries, the use of the Content-Length header in SIP messages is not necessary when they are transported using the WebSocket subprotocol. This simplifies the parsing of SIP messages for both clients and servers. There is no need to establish message boundaries using Content-Length headers between messages. Other SIP transports, such as UDP and the Stream Control Transmission Protocol (SCTP) [RFC4168], also provide this benefit. It was fixed, so the previous problem it is not present anymore: This was replaced: 335 private void handleUpgrade(final HttpUpgradeParser parser) { 336 final String contentLength = parser.getHeaders().get("content-length"); 337 if (!"0".equals(contentLength)) { 338 future.setException(new IOException("For now upgrade responses must have a content length of zero.")); 339 return; 340 } by that: private void handleUpgrade(final HttpUpgradeParser parser) { Map simpleHeaders = new HashMap<>(); for(Map.Entry> e : parser.getHeaders().entrySet()) { simpleHeaders.put(e.getKey(), e.getValue().get(0)); } final String contentLength = simpleHeaders.get("content-length"); if (contentLength != null) { if (!"0".equals(contentLength)) { future.setException(new IOException("Upgrade responses must have a content length of zero.")); return; } } Seems to me that the content length should not be informed in your case, or if it is in the header the value should be 0 to the upgrade operation. Thx Eduardo Sant'Ana da Silva On Nov 24, 2015, at 10:34 PM, Thomas Fr?hbeck wrote: > you nailed it, thanks! > unfortunate though :-/ > > Am 25.11.2015 um 01:30 schrieb Eduardo Sant?Ana da Silva: >> Maybe this could help: >> >> https://issues.jboss.org/browse/XNIO-222 >> >> >> 2015-11-24 20:33 GMT-02:00 Thomas Fr?hbeck : >> Hi, >> I wanted to experiment with Wildfly 10.0.0.CR4 and Remoting and got the >> followin error on client side. I know, that my client works perfectly >> with 9.0.2.Final. >> Can you guide me to the relevant changes, is this a known problem? >> >> WARN: Could not register a EJB receiver for connection to localhost:8080 >> java.lang.RuntimeException: java.io.IOException: For now upgrade >> responses must have a content length of zero. >> at >> org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:92) >> at >> org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:77) >> at >> org.jboss.ejb.client.remoting.RemotingConnectionManager.getConnection(RemotingConnectionManager.java:51) >> at >> org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.setupEJBReceivers(ConfigBasedEJBClientContextSelector.java:155) >> at >> org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.getCurrent(ConfigBasedEJBClientContextSelector.java:115) >> at >> org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.getCurrent(ConfigBasedEJBClientContextSelector.java:47) >> at >> org.jboss.ejb.client.EJBClientContext.getCurrent(EJBClientContext.java:271) >> at >> org.jboss.ejb.client.EJBClientContext.requireCurrent(EJBClientContext.java:281) >> at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:200) >> at >> org.jboss.ejb.client.naming.ejb.EjbNamingContext.doCreateProxy(EjbNamingContext.java:216) >> at >> org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:193) >> at >> org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:176) >> at javax.naming.InitialContext.lookup(InitialContext.java:417) >> >> Thanks, >> Thomas >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> >> -- >> __________________________ >> Eduardo Sant'Ana da Silva - Dr. >> Pesquisador / Consultor de TI >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151124/6e09fa2d/attachment-0001.html From eduardo.santanadasilva at gmail.com Tue Nov 24 20:14:43 2015 From: eduardo.santanadasilva at gmail.com (Eduardo Sant'Ana da Silva) Date: Tue, 24 Nov 2015 23:14:43 -0200 Subject: [wildfly-dev] Problem remoting connection with wildfly 10.0.0.CR4 In-Reply-To: <5655021B.1070205@aon.at> References: <5654E5C4.3020008@aon.at> <5655021B.1070205@aon.at> Message-ID: <2894AFBE-440D-4600-83AA-A3BEE7970E52@gmail.com> In my opinion, you should upgrade your client xnio version to one later or equals to 3.2.1.Final. On Nov 24, 2015, at 10:34 PM, Thomas Fr?hbeck wrote: > you nailed it, thanks! > unfortunate though :-/ > > Am 25.11.2015 um 01:30 schrieb Eduardo Sant?Ana da Silva: >> Maybe this could help: >> >> https://issues.jboss.org/browse/XNIO-222 >> >> >> 2015-11-24 20:33 GMT-02:00 Thomas Fr?hbeck : >> Hi, >> I wanted to experiment with Wildfly 10.0.0.CR4 and Remoting and got the >> followin error on client side. I know, that my client works perfectly >> with 9.0.2.Final. >> Can you guide me to the relevant changes, is this a known problem? >> >> WARN: Could not register a EJB receiver for connection to localhost:8080 >> java.lang.RuntimeException: java.io.IOException: For now upgrade >> responses must have a content length of zero. >> at >> org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:92) >> at >> org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:77) >> at >> org.jboss.ejb.client.remoting.RemotingConnectionManager.getConnection(RemotingConnectionManager.java:51) >> at >> org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.setupEJBReceivers(ConfigBasedEJBClientContextSelector.java:155) >> at >> org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.getCurrent(ConfigBasedEJBClientContextSelector.java:115) >> at >> org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.getCurrent(ConfigBasedEJBClientContextSelector.java:47) >> at >> org.jboss.ejb.client.EJBClientContext.getCurrent(EJBClientContext.java:271) >> at >> org.jboss.ejb.client.EJBClientContext.requireCurrent(EJBClientContext.java:281) >> at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:200) >> at >> org.jboss.ejb.client.naming.ejb.EjbNamingContext.doCreateProxy(EjbNamingContext.java:216) >> at >> org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:193) >> at >> org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:176) >> at javax.naming.InitialContext.lookup(InitialContext.java:417) >> >> Thanks, >> Thomas >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> >> -- >> __________________________ >> Eduardo Sant'Ana da Silva - Dr. >> Pesquisador / Consultor de TI >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151124/8dc9e51f/attachment.html From rory.odonnell at oracle.com Wed Nov 25 06:36:01 2015 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Wed, 25 Nov 2015 11:36:01 +0000 Subject: [wildfly-dev] Early Access builds for JDK 8u72 b05 , JDK 9 b88 and JDK 9 with Project Jigsaw build b86 are available on java.net In-Reply-To: <563C8C13.9000503@oracle.com> References: <5633890B.4000003@oracle.com> <563893B6.8020605@oracle.com> <563C8C13.9000503@oracle.com> Message-ID: <56559D21.7070400@oracle.com> Hi Tomaz, b93 is not available on https://jdk9.java.net/download/, it contains a fix for your issue. Can you confirm fix ? Rgds,Rory On 06/11/2015 11:16, Rory O'Donnell wrote: > Bug is now in JBS - https://bugs.openjdk.java.net/browse/JDK-8141613 > > To monitor updates see Dalibor's blog > > > Rgds,Rory > On 03/11/2015 14:48, Toma? Cerar wrote: >> Reported, Incident id is JI-9026215 >> >> >> -- >> tomaz >> >> On Tue, Nov 3, 2015 at 12:00 PM, Rory O'Donnell >> > wrote: >> >> Hi Tomaz, >> >> b90 is the latest build available, I suggest you log a bug with >> as much detail as possible >> and send us the incident id. >> >> Rgds,Rory >> >> >> On 02/11/2015 23:54, Toma? Cerar wrote: >>> Rory hi, >>> >>> With JDK9 build 90 our build is failing with compile error. >>> >>> [ERROR] >>> /C:/development/java/wildfly/clustering/web/infinispan/src/main/java/org/wildfly/clustering/web/infinispan/session/InfinispanSessionManagerFactory.java:[167,44] >>> incompatible types: cannot infer type arguments for >>> org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory<> >>> reason: inference variable V has incompatible equality >>> constraints capture#1 of ?,capture#2 of ? >>> >>> this is the code: >>> https://github.com/wildfly/wildfly/blob/master/clustering/web/infinispan/src/main/java/org/wildfly/clustering/web/infinispan/session/InfinispanSessionManagerFactory.java#L176 >>> >>> I can probably isolate it bit more if required, as it is always >>> reproducible. >>> >>> Is this already known issue and we should just wait for newer >>> build or should submit new bug report. >>> >>> version used: java full version "1.9.0-ea-b90" >>> reproducible both on windows & linux builds. >>> >>> -- >>> tomaz >>> >>> >>> >>> On Fri, Oct 30, 2015 at 4:13 PM, Rory O'Donnell >>> wrote: >>> >>> >>> Hi Jason/Tomaz, >>> >>> Early Access build for JDK 8u72 b05 >>> is available on >>> java.net , summary of changes are listed >>> here. >>> >>> >>> Early Access build for JDK 9 b88 >>> is available on java.net >>> , summary of changes are listed here >>> . >>> >>> Early Access build for JDK 9 with Project Jigsaw b86 >>> is available on java.net >>> . >>> >>> Changes for JDK 9 with Project Jigsaw b86 : - >>> >>> * New options for the jdeps tool: -genmoduleinfo to >>> generate draft module-info.java files, and -ct to do a >>> compile-time analysis of references (i.e., follow all >>> references leaving all classes in each referenced JAR >>> file) rather than the default run-time analysis (which >>> only follows references leaving referenced classes). >>> * jlink no longer does service binding by default. >>> * Class::getPackage fixed to return null for array types, >>> primitives, and void (bug reported by Chris Newland). >>> * Improved messages in IllegalAccessExceptions thrown by >>> core reflection. >>> * java -verbose now works with -Xpatch . >>> * The special token ALL-SYSTEM can be used with the >>> -addmods option to add all system modules. >>> * New methods Module::{addUses,canUse}, which are dynamic >>> equivalents of service-use clauses in module declarations. >>> >>> Rgds, Rory >>> >>> -- >>> Rgds,Rory O'Donnell >>> Quality Engineering Manager >>> Oracle EMEA , Dublin, Ireland >>> >>> >> >> -- >> Rgds,Rory O'Donnell >> Quality Engineering Manager >> Oracle EMEA, Dublin,Ireland >> >> > > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA , Dublin, Ireland -- 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/20151125/bb0f4624/attachment-0001.html From tdiesler at redhat.com Wed Nov 25 09:03:16 2015 From: tdiesler at redhat.com (Thomas Diesler) Date: Wed, 25 Nov 2015 15:03:16 +0100 Subject: [wildfly-dev] Allow Camel LoadBalancer to connect to clustered WildFly HTTP endpoints Message-ID: Hi Stuart/Friends, https://github.com/wildfly-extras/wildfly-camel/issues/878 In fabric a camel load balancer can contact a (zookeeper) registry using a logical name to react to changes in server topology or for initial discovery. I wonder how this can/should be done in the context of undertow http endpoints on wildfly. cheers ? thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151125/c23340e3/attachment.html From tomaz.cerar at gmail.com Wed Nov 25 10:15:28 2015 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Wed, 25 Nov 2015 16:15:28 +0100 Subject: [wildfly-dev] Early Access builds for JDK 8u72 b05 , JDK 9 b88 and JDK 9 with Project Jigsaw build b86 are available on java.net In-Reply-To: <56559D21.7070400@oracle.com> References: <5633890B.4000003@oracle.com> <563893B6.8020605@oracle.com> <563C8C13.9000503@oracle.com> <56559D21.7070400@oracle.com> Message-ID: Hey Rory, I can confirm that with b93, WildFly compiles & builds again. thank you for the help driving this trough. tomaz On Wed, Nov 25, 2015 at 12:36 PM, Rory O'Donnell wrote: > Hi Tomaz, > > b93 is not available on https://jdk9.java.net/download/, it contains a > fix for your issue. > Can you confirm fix ? > > Rgds,Rory > > > On 06/11/2015 11:16, Rory O'Donnell wrote: > > Bug is now in JBS - https://bugs.openjdk.java.net/browse/JDK-8141613 > > To monitor updates see Dalibor's blog > > > Rgds,Rory > On 03/11/2015 14:48, Toma? Cerar wrote: > > Reported, Incident id is JI-9026215 > > > -- > tomaz > > On Tue, Nov 3, 2015 at 12:00 PM, Rory O'Donnell > wrote: > >> Hi Tomaz, >> >> b90 is the latest build available, I suggest you log a bug with as much >> detail as possible >> and send us the incident id. >> >> Rgds,Rory >> >> >> On 02/11/2015 23:54, Toma? Cerar wrote: >> >> Rory hi, >> >> With JDK9 build 90 our build is failing with compile error. >> >> [ERROR] >> /C:/development/java/wildfly/clustering/web/infinispan/src/main/java/org/wildfly/clustering/web/infinispan/session/InfinispanSessionManagerFactory.java:[167,44] >> incompatible types: cannot infer type arguments for >> org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory<> >> reason: inference variable V has incompatible equality constraints >> capture#1 of ?,capture#2 of ? >> >> this is the code: >> >> https://github.com/wildfly/wildfly/blob/master/clustering/web/infinispan/src/main/java/org/wildfly/clustering/web/infinispan/session/InfinispanSessionManagerFactory.java#L176 >> >> I can probably isolate it bit more if required, as it is always >> reproducible. >> >> Is this already known issue and we should just wait for newer build or >> should submit new bug report. >> >> version used: java full version "1.9.0-ea-b90" >> reproducible both on windows & linux builds. >> >> -- >> tomaz >> >> >> >> On Fri, Oct 30, 2015 at 4:13 PM, Rory O'Donnell < >> rory.odonnell at oracle.com> wrote: >> >>> >>> Hi Jason/Tomaz, >>> >>> Early Access build for JDK 8u72 b05 >>> is available on java.net, summary of changes are listed here. >>> >>> >>> Early Access build for JDK 9 b88 is >>> available on java.net, summary of changes are listed here >>> >>> . >>> >>> Early Access build for JDK 9 with Project Jigsaw b86 >>> is available on java.net. >>> >>> Changes for JDK 9 with Project Jigsaw b86 : - >>> >>> - New options for the jdeps tool: -genmoduleinfo to generate draft >>> module-info.java files, and -ct to do a compile-time analysis of references >>> (i.e., follow all references leaving all classes in each referenced JAR >>> file) rather than the default run-time analysis (which only follows >>> references leaving referenced classes). >>> - jlink no longer does service binding by default. >>> - Class::getPackage fixed to return null for array types, >>> primitives, and void (bug reported by Chris Newland). >>> - Improved messages in IllegalAccessExceptions thrown by core >>> reflection. >>> - java -verbose now works with -Xpatch . >>> - The special token ALL-SYSTEM can be used with the -addmods option >>> to add all system modules. >>> - New methods Module::{addUses,canUse}, which are dynamic >>> equivalents of service-use clauses in module declarations. >>> >>> Rgds, Rory >>> >>> -- >>> Rgds,Rory O'Donnell >>> Quality Engineering Manager >>> Oracle EMEA , Dublin, Ireland >>> >>> >> >> -- >> Rgds,Rory O'Donnell >> Quality Engineering Manager >> Oracle EMEA, Dublin,Ireland >> >> > > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA , Dublin, Ireland > > > -- > 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/20151125/27492608/attachment.html From fruehbeck at aon.at Wed Nov 25 17:58:13 2015 From: fruehbeck at aon.at (=?UTF-8?Q?Thomas_Fr=c3=bchbeck?=) Date: Wed, 25 Nov 2015 23:58:13 +0100 Subject: [wildfly-dev] Problem remoting connection with wildfly 10.0.0.CR4 In-Reply-To: <2894AFBE-440D-4600-83AA-A3BEE7970E52@gmail.com> References: <5654E5C4.3020008@aon.at> <5655021B.1070205@aon.at> <2894AFBE-440D-4600-83AA-A3BEE7970E52@gmail.com> Message-ID: <56563D05.7090805@aon.at> thanks for the input, yet I am using following artifacts: org.jboss.xnio xnio-nio 3.3.2.Final The full source is available at: https://github.com/shadogray/securefs/tree/master/securefs-master/securefs-client-test And, just to make sure, the full command line reads: xnio-nio-3.3.2.Final.jar [DEBUG] Executing command line: [java, -classpath, /raid/home/thomas/workspace-sec/securefs/securefs-master/securefs-client-test/target/classes:\ /home/thomas/.m2/repository/at/tfr/securefs/securefs-client/1.1.0-SNAPSHOT/securefs-client-1.1.0-SNAPSHOT.jar:\ /home/thomas/.m2/repository/at/tfr/securefs/securefs-api/1.1.0-SNAPSHOT/securefs-api-1.1.0-SNAPSHOT.jar:\ /home/thomas/.m2/repository/org/jboss/logging/jboss-logging/3.1.4.GA/jboss-logging-3.1.4.GA.jar:\ /home/thomas/.m2/repository/commons-io/commons-io/2.4/commons-io-2.4.jar:\ /home/thomas/.m2/repository/commons-lang/commons-lang/2.6/commons-lang-2.6.jar:\ /home/thomas/.m2/repository/javax/javaee-api/7.0/javaee-api-7.0.jar:\ /home/thomas/.m2/repository/com/sun/mail/javax.mail/1.5.0/javax.mail-1.5.0.jar:\ /home/thomas/.m2/repository/javax/activation/activation/1.1/activation-1.1.jar:\ /home/thomas/.m2/repository/jboss/jboss-client/4.0.2/jboss-client-4.0.2.jar:\ /home/thomas/.m2/repository/org/jboss/jboss-remote-naming/2.0.4.Final/jboss-remote-naming-2.0.4.Final.jar:\ /home/thomas/.m2/repository/org/jboss/jboss-ejb-client/2.0.0.Final/jboss-ejb-client-2.0.0.Final.jar:\ /home/thomas/.m2/repository/org/jboss/marshalling/jboss-marshalling/1.4.3.Final/jboss-marshalling-1.4.3.Final.jar:\ /home/thomas/.m2/repository/org/jboss/marshalling/jboss-marshalling-river/1.4.3.Final/jboss-marshalling-river-1.4.3.Final.jar:\ /home/thomas/.m2/repository/org/jboss/xnio/xnio-api/3.2.0.Final/xnio-api-3.2.0.Final.jar:\ /home/thomas/.m2/repository/org/jboss/remoting/jboss-remoting/4.0.0.Final/jboss-remoting-4.0.0.Final.jar:\ /home/thomas/.m2/repository/org/jboss/sasl/jboss-sasl/1.0.4.Final/jboss-sasl-1.0.4.Final.jar:\ /home/thomas/.m2/repository/commons-cli/commons-cli/1.3.1/commons-cli-1.3.1.jar:\ /home/thomas/.m2/repository/org/jboss/xnio/xnio-nio/3.3.2.Final/xnio-nio-3.3.2.Final.jar:\ /home/thomas/.m2/repository/joda-time/joda-time/2.9/joda-time-2.9.jar, \ at.tfr.securefs.client.SecurefsClient, -b, sec:///raid/home/thomas/workspace-sec/securefs/securefs-master/securefs-client-test/target/, -a, false, -t, 10, -f, data/test/test.txt,data/test/test_main.txt] I am really looking forward to Wilfly 10.0.0 - especially clusterd deployment, and would appreciate to find anything blocking early. Am 25.11.2015 um 02:14 schrieb Eduardo Sant'Ana da Silva: > In my opinion, you should upgrade your client xnio version to one > later or equals to 3.2.1.Final. > > > On Nov 24, 2015, at 10:34 PM, Thomas Fr?hbeck > wrote: > >> you nailed it, thanks! >> unfortunate though :-/ >> >> Am 25.11.2015 um 01:30 schrieb Eduardo Sant?Ana da Silva: >>> Maybe this could help: >>> >>> https://issues.jboss.org/browse/XNIO-222 >>> >>> >>> 2015-11-24 20:33 GMT-02:00 Thomas Fr?hbeck >> >: >>> >>> Hi, >>> I wanted to experiment with Wildfly 10.0.0.CR4 and Remoting and >>> got the >>> followin error on client side. I know, that my client works >>> perfectly >>> with 9.0.2.Final. >>> Can you guide me to the relevant changes, is this a known problem? >>> >>> WARN: Could not register a EJB receiver for connection to >>> localhost:8080 >>> java.lang.RuntimeException: java.io.IOException: For now upgrade >>> responses must have a content length of zero. >>> at >>> org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:92) >>> at >>> org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:77) >>> at >>> org.jboss.ejb.client.remoting.RemotingConnectionManager.getConnection(RemotingConnectionManager.java:51) >>> at >>> org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.setupEJBReceivers(ConfigBasedEJBClientContextSelector.java:155) >>> at >>> org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.getCurrent(ConfigBasedEJBClientContextSelector.java:115) >>> at >>> org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.getCurrent(ConfigBasedEJBClientContextSelector.java:47) >>> at >>> org.jboss.ejb.client.EJBClientContext.getCurrent(EJBClientContext.java:271) >>> at >>> org.jboss.ejb.client.EJBClientContext.requireCurrent(EJBClientContext.java:281) >>> at >>> org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:200) >>> at >>> org.jboss.ejb.client.naming.ejb.EjbNamingContext.doCreateProxy(EjbNamingContext.java:216) >>> at >>> org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:193) >>> at >>> org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:176) >>> at >>> javax.naming.InitialContext.lookup(InitialContext.java:417) >>> >>> Thanks, >>> Thomas >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >>> >>> >>> >>> -- >>> __________________________ >>> Eduardo Sant'Ana da Silva - Dr. >>> Pesquisador / Consultor de TI >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151125/80dec425/attachment-0001.html From eduardo.santanadasilva at gmail.com Wed Nov 25 18:29:26 2015 From: eduardo.santanadasilva at gmail.com (=?UTF-8?Q?Eduardo_Sant=C2=B4Ana_da_Silva?=) Date: Wed, 25 Nov 2015 21:29:26 -0200 Subject: [wildfly-dev] Problem remoting connection with wildfly 10.0.0.CR4 In-Reply-To: <56563D05.7090805@aon.at> References: <5654E5C4.3020008@aon.at> <5655021B.1070205@aon.at> <2894AFBE-440D-4600-83AA-A3BEE7970E52@gmail.com> <56563D05.7090805@aon.at> Message-ID: I've made the deployment of your application and I've got the same error. You can see that the log of your test contains the XNIO version... ------------------------------------------------------- T E S T S ------------------------------------------------------- Running at.tfr.securefs.client.TestFileSystem Nov 25, 2015 9:18:47 PM org.xnio.Xnio INFO: XNIO version 3.2.0.Final Nov 25, 2015 9:18:48 PM org.xnio.nio.NioXnio INFO: XNIO NIO Implementation Version 3.3.2.Final Nov 25, 2015 9:18:48 PM org.jboss.remoting3.EndpointImpl INFO: JBoss Remoting version 4.0.0.Final Nov 25, 2015 9:18:49 PM org.jboss.ejb.client.EJBClient INFO: JBoss EJB Client version 2.0.0.Final Nov 25, 2015 9:18:51 PM org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector setupEJBReceivers WARN: Could not register a EJB receiver for connection to localhost:8080 java.lang.RuntimeException: java.io.IOException: For now upgrade responses must have a content length of zero. .m2/repository/./org/jboss/jboss-ejb-client/2.1.3.Final/jboss-ejb-client-2.1.3.Final.pom Here is the problem, the latest version of the jboss-ejb-client (at least what I have here) is using a xnio version that does not contain the fix: 3.2.0.Final 2015-11-25 20:58 GMT-02:00 Thomas Fr?hbeck : > thanks for the input, yet I am using following artifacts: > > > org.jboss.xnio > xnio-nio > 3.3.2.Final > > > The full source is available at: > https://github.com/shadogray/securefs/tree/master/securefs-master/securefs-client-test > > And, just to make sure, the full command line reads: > xnio-nio-3.3.2.Final.jar > > [DEBUG] Executing command line: [java, -classpath, > > /raid/home/thomas/workspace-sec/securefs/securefs-master/securefs-client-test/target/classes:\ > > /home/thomas/.m2/repository/at/tfr/securefs/securefs-client/1.1.0-SNAPSHOT/securefs-client-1.1.0-SNAPSHOT.jar:\ > > /home/thomas/.m2/repository/at/tfr/securefs/securefs-api/1.1.0-SNAPSHOT/securefs-api-1.1.0-SNAPSHOT.jar:\ > /home/thomas/.m2/repository/org/jboss/logging/jboss-logging/ > 3.1.4.GA/jboss-logging-3.1.4.GA.jar:\ > /home/thomas/.m2/repository/commons-io/commons-io/2.4/commons-io-2.4.jar:\ > > /home/thomas/.m2/repository/commons-lang/commons-lang/2.6/commons-lang-2.6.jar:\ > /home/thomas/.m2/repository/javax/javaee-api/7.0/javaee-api-7.0.jar:\ > > /home/thomas/.m2/repository/com/sun/mail/javax.mail/1.5.0/javax.mail-1.5.0.jar:\ > > /home/thomas/.m2/repository/javax/activation/activation/1.1/activation-1.1.jar:\ > > /home/thomas/.m2/repository/jboss/jboss-client/4.0.2/jboss-client-4.0.2.jar:\ > > /home/thomas/.m2/repository/org/jboss/jboss-remote-naming/2.0.4.Final/jboss-remote-naming-2.0.4.Final.jar:\ > > /home/thomas/.m2/repository/org/jboss/jboss-ejb-client/2.0.0.Final/jboss-ejb-client-2.0.0.Final.jar:\ > > /home/thomas/.m2/repository/org/jboss/marshalling/jboss-marshalling/1.4.3.Final/jboss-marshalling-1.4.3.Final.jar:\ > > /home/thomas/.m2/repository/org/jboss/marshalling/jboss-marshalling-river/1.4.3.Final/jboss-marshalling-river-1.4.3.Final.jar:\ > > /home/thomas/.m2/repository/org/jboss/xnio/xnio-api/3.2.0.Final/xnio-api-3.2.0.Final.jar:\ > > /home/thomas/.m2/repository/org/jboss/remoting/jboss-remoting/4.0.0.Final/jboss-remoting-4.0.0.Final.jar:\ > > /home/thomas/.m2/repository/org/jboss/sasl/jboss-sasl/1.0.4.Final/jboss-sasl-1.0.4.Final.jar:\ > > /home/thomas/.m2/repository/commons-cli/commons-cli/1.3.1/commons-cli-1.3.1.jar:\ > > /home/thomas/.m2/repository/org/jboss/xnio/xnio-nio/3.3.2.Final/xnio-nio-3.3.2.Final.jar:\ > /home/thomas/.m2/repository/joda-time/joda-time/2.9/joda-time-2.9.jar, \ > at.tfr.securefs.client.SecurefsClient, -b, > sec:///raid/home/thomas/workspace-sec/securefs/securefs-master/securefs-client-test/target/, > -a, false, -t, 10, -f, data/test/test.txt,data/test/test_main.txt] > > I am really looking forward to Wilfly 10.0.0 - especially clusterd > deployment, and would appreciate to find anything blocking early. > > > > Am 25.11.2015 um 02:14 schrieb Eduardo Sant'Ana da Silva: > > In my opinion, you should upgrade your client xnio version to one later or > equals to 3.2.1.Final. > > > On Nov 24, 2015, at 10:34 PM, Thomas Fr?hbeck < > fruehbeck at aon.at> wrote: > > you nailed it, thanks! > unfortunate though :-/ > > Am 25.11.2015 um 01:30 schrieb Eduardo Sant?Ana da Silva: > > Maybe this could help: > > https://issues.jboss.org/browse/XNIO-222 > > > 2015-11-24 20:33 GMT-02:00 Thomas Fr?hbeck < > fruehbeck at aon.at>: > >> Hi, >> I wanted to experiment with Wildfly 10.0.0.CR4 and Remoting and got the >> followin error on client side. I know, that my client works perfectly >> with 9.0.2.Final. >> Can you guide me to the relevant changes, is this a known problem? >> >> WARN: Could not register a EJB receiver for connection to localhost:8080 >> java.lang.RuntimeException: java.io.IOException: For now upgrade >> responses must have a content length of zero. >> at >> org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:92) >> at >> >> org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:77) >> at >> >> org.jboss.ejb.client.remoting.RemotingConnectionManager.getConnection(RemotingConnectionManager.java:51) >> at >> >> org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.setupEJBReceivers(ConfigBasedEJBClientContextSelector.java:155) >> at >> >> org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.getCurrent(ConfigBasedEJBClientContextSelector.java:115) >> at >> >> org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.getCurrent(ConfigBasedEJBClientContextSelector.java:47) >> at >> >> org.jboss.ejb.client.EJBClientContext.getCurrent(EJBClientContext.java:271) >> at >> >> org.jboss.ejb.client.EJBClientContext.requireCurrent(EJBClientContext.java:281) >> at >> org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:200) >> at >> >> org.jboss.ejb.client.naming.ejb.EjbNamingContext.doCreateProxy(EjbNamingContext.java:216) >> at >> >> org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:193) >> at >> >> org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:176) >> at javax.naming.InitialContext.lookup(InitialContext.java:417) >> >> Thanks, >> Thomas >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > > > -- > __________________________ > Eduardo Sant'Ana da Silva - Dr. > Pesquisador / Consultor de TI > > > > > -- __________________________ Eduardo Sant'Ana da Silva - Dr. Pesquisador / Consultor de TI -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151125/97315e83/attachment.html From fruehbeck at aon.at Thu Nov 26 01:48:39 2015 From: fruehbeck at aon.at (=?UTF-8?Q?Thomas_Fr=c3=bchbeck?=) Date: Thu, 26 Nov 2015 07:48:39 +0100 Subject: [wildfly-dev] Problem remoting connection with wildfly 10.0.0.CR4 In-Reply-To: References: <5654E5C4.3020008@aon.at> <5655021B.1070205@aon.at> <2894AFBE-440D-4600-83AA-A3BEE7970E52@gmail.com> <56563D05.7090805@aon.at> Message-ID: <5656AB47.9090304@aon.at> Eduardo, thank you very much for your support, evidently I did not look close enough :-) Quickest fix was to move dependency of XNIO _before_ jboss-client. That settles it, best regards, thomas Am 26.11.2015 um 00:29 schrieb Eduardo Sant?Ana da Silva: > I've made the deployment of your application and I've got the same error. > > > You can see that the log of your test contains the XNIO version... > > ------------------------------------------------------- > > T E S T S > > ------------------------------------------------------- > > Running at.tfr.securefs.client.TestFileSystem > > Nov 25, 2015 9:18:47 PM org.xnio.Xnio > > INFO: XNIO version 3.2.0.Final > > Nov 25, 2015 9:18:48 PM org.xnio.nio.NioXnio > > INFO: XNIO NIO Implementation Version 3.3.2.Final > > Nov 25, 2015 9:18:48 PM org.jboss.remoting3.EndpointImpl > > INFO: JBoss Remoting version 4.0.0.Final > > Nov 25, 2015 9:18:49 PM org.jboss.ejb.client.EJBClient > > INFO: JBoss EJB Client version 2.0.0.Final > > Nov 25, 2015 9:18:51 PM > org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector > setupEJBReceivers > > WARN: Could not register a EJB receiver for connection to localhost:8080 > > java.lang.RuntimeException: java.io.IOException: For now upgrade > responses must have a content length of zero. > > > > .m2/repository/./org/jboss/jboss-ejb-client/2.1.3.Final/jboss-ejb-client-2.1.3.Final.pom > > > Here is the problem, the latest version of the jboss-ejb-client (at > least what I have here) is using a xnio version that does not contain > the fix: > > 3.2.0.Final > > > > 2015-11-25 20:58 GMT-02:00 Thomas Fr?hbeck >: > > thanks for the input, yet I am using following artifacts: > > > org.jboss.xnio > xnio-nio > 3.3.2.Final > > > The full source is available at: > https://github.com/shadogray/securefs/tree/master/securefs-master/securefs-client-test > > > And, just to make sure, the full command line reads: > xnio-nio-3.3.2.Final.jar > > [DEBUG] Executing command line: [java, -classpath, > /raid/home/thomas/workspace-sec/securefs/securefs-master/securefs-client-test/target/classes:\ > /home/thomas/.m2/repository/at/tfr/securefs/securefs-client/1.1.0-SNAPSHOT/securefs-client-1.1.0-SNAPSHOT.jar:\ > /home/thomas/.m2/repository/at/tfr/securefs/securefs-api/1.1.0-SNAPSHOT/securefs-api-1.1.0-SNAPSHOT.jar:\ > /home/thomas/.m2/repository/org/jboss/logging/jboss-logging/3.1.4.GA/jboss-logging-3.1.4.GA.jar > :\ > /home/thomas/.m2/repository/commons-io/commons-io/2.4/commons-io-2.4.jar:\ > /home/thomas/.m2/repository/commons-lang/commons-lang/2.6/commons-lang-2.6.jar:\ > /home/thomas/.m2/repository/javax/javaee-api/7.0/javaee-api-7.0.jar:\ > /home/thomas/.m2/repository/com/sun/mail/javax.mail/1.5.0/javax.mail-1.5.0.jar:\ > /home/thomas/.m2/repository/javax/activation/activation/1.1/activation-1.1.jar:\ > /home/thomas/.m2/repository/jboss/jboss-client/4.0.2/jboss-client-4.0.2.jar:\ > /home/thomas/.m2/repository/org/jboss/jboss-remote-naming/2.0.4.Final/jboss-remote-naming-2.0.4.Final.jar:\ > /home/thomas/.m2/repository/org/jboss/jboss-ejb-client/2.0.0.Final/jboss-ejb-client-2.0.0.Final.jar:\ > /home/thomas/.m2/repository/org/jboss/marshalling/jboss-marshalling/1.4.3.Final/jboss-marshalling-1.4.3.Final.jar:\ > /home/thomas/.m2/repository/org/jboss/marshalling/jboss-marshalling-river/1.4.3.Final/jboss-marshalling-river-1.4.3.Final.jar:\ > /home/thomas/.m2/repository/org/jboss/xnio/xnio-api/3.2.0.Final/xnio-api-3.2.0.Final.jar:\ > /home/thomas/.m2/repository/org/jboss/remoting/jboss-remoting/4.0.0.Final/jboss-remoting-4.0.0.Final.jar:\ > /home/thomas/.m2/repository/org/jboss/sasl/jboss-sasl/1.0.4.Final/jboss-sasl-1.0.4.Final.jar:\ > /home/thomas/.m2/repository/commons-cli/commons-cli/1.3.1/commons-cli-1.3.1.jar:\ > /home/thomas/.m2/repository/org/jboss/xnio/xnio-nio/3.3.2.Final/xnio-nio-3.3.2.Final.jar:\ > /home/thomas/.m2/repository/joda-time/joda-time/2.9/joda-time-2.9.jar, > \ > at.tfr.securefs.client.SecurefsClient, -b, > sec:///raid/home/thomas/workspace-sec/securefs/securefs-master/securefs-client-test/target/, > -a, false, -t, 10, -f, data/test/test.txt,data/test/test_main.txt] > > I am really looking forward to Wilfly 10.0.0 - especially clusterd > deployment, and would appreciate to find anything blocking early. > > > > Am 25.11.2015 um 02:14 schrieb Eduardo Sant'Ana da Silva: >> In my opinion, you should upgrade your client xnio version to one >> later or equals to 3.2.1.Final. >> >> >> On Nov 24, 2015, at 10:34 PM, Thomas Fr?hbeck > > wrote: >> >>> you nailed it, thanks! >>> unfortunate though :-/ >>> >>> Am 25.11.2015 um 01:30 schrieb Eduardo Sant?Ana da Silva: >>>> Maybe this could help: >>>> >>>> https://issues.jboss.org/browse/XNIO-222 >>>> >>>> >>>> 2015-11-24 20:33 GMT-02:00 Thomas Fr?hbeck >>> >: >>>> >>>> Hi, >>>> I wanted to experiment with Wildfly 10.0.0.CR4 and Remoting >>>> and got the >>>> followin error on client side. I know, that my client works >>>> perfectly >>>> with 9.0.2.Final. >>>> Can you guide me to the relevant changes, is this a known >>>> problem? >>>> >>>> WARN: Could not register a EJB receiver for connection to >>>> localhost:8080 >>>> java.lang.RuntimeException: java.io.IOException: For now >>>> upgrade >>>> responses must have a content length of zero. >>>> at >>>> org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:92) >>>> at >>>> org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:77) >>>> at >>>> org.jboss.ejb.client.remoting.RemotingConnectionManager.getConnection(RemotingConnectionManager.java:51) >>>> at >>>> org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.setupEJBReceivers(ConfigBasedEJBClientContextSelector.java:155) >>>> at >>>> org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.getCurrent(ConfigBasedEJBClientContextSelector.java:115) >>>> at >>>> org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.getCurrent(ConfigBasedEJBClientContextSelector.java:47) >>>> at >>>> org.jboss.ejb.client.EJBClientContext.getCurrent(EJBClientContext.java:271) >>>> at >>>> org.jboss.ejb.client.EJBClientContext.requireCurrent(EJBClientContext.java:281) >>>> at >>>> org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:200) >>>> at >>>> org.jboss.ejb.client.naming.ejb.EjbNamingContext.doCreateProxy(EjbNamingContext.java:216) >>>> at >>>> org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:193) >>>> at >>>> org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:176) >>>> at >>>> javax.naming.InitialContext.lookup(InitialContext.java:417) >>>> >>>> Thanks, >>>> Thomas >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>>> >>>> >>>> >>>> -- >>>> __________________________ >>>> Eduardo Sant'Ana da Silva - Dr. >>>> Pesquisador / Consultor de TI >>>> >>> >> > > > > > -- > __________________________ > Eduardo Sant'Ana da Silva - Dr. > Pesquisador / Consultor de TI > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151126/857b442d/attachment-0001.html From lthon at redhat.com Thu Nov 26 02:02:25 2015 From: lthon at redhat.com (Ladislav Thon) Date: Thu, 26 Nov 2015 08:02:25 +0100 Subject: [wildfly-dev] Problem remoting connection with wildfly 10.0.0.CR4 In-Reply-To: <5656AB47.9090304@aon.at> References: <5654E5C4.3020008@aon.at> <5655021B.1070205@aon.at> <2894AFBE-440D-4600-83AA-A3BEE7970E52@gmail.com> <56563D05.7090805@aon.at> <5656AB47.9090304@aon.at> Message-ID: <5656AE81.6070608@redhat.com> > Quickest fix was to move dependency of XNIO _before_ jboss-client. Or use a dependency exclusion. I think it's more clear, personally. LT > That settles it, best regards, > thomas > > Am 26.11.2015 um 00:29 schrieb Eduardo Sant?Ana da Silva: >> I've made the deployment of your application and I've got the same error. >> >> >> You can see that the log of your test contains the XNIO version... >> >> ------------------------------------------------------- >> >> T E S T S >> >> ------------------------------------------------------- >> >> Running at.tfr.securefs.client.TestFileSystem >> >> Nov 25, 2015 9:18:47 PM org.xnio.Xnio >> >> INFO: XNIO version 3.2.0.Final >> >> Nov 25, 2015 9:18:48 PM org.xnio.nio.NioXnio >> >> INFO: XNIO NIO Implementation Version 3.3.2.Final >> >> Nov 25, 2015 9:18:48 PM org.jboss.remoting3.EndpointImpl >> >> INFO: JBoss Remoting version 4.0.0.Final >> >> Nov 25, 2015 9:18:49 PM org.jboss.ejb.client.EJBClient >> >> INFO: JBoss EJB Client version 2.0.0.Final >> >> Nov 25, 2015 9:18:51 PM >> org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector >> setupEJBReceivers >> >> WARN: Could not register a EJB receiver for connection to localhost:8080 >> >> java.lang.RuntimeException: java.io.IOException: For now upgrade >> responses must have a content length of zero. >> >> >> >> .m2/repository/./org/jboss/jboss-ejb-client/2.1.3.Final/jboss-ejb-client-2.1.3.Final.pom >> >> >> Here is the problem, the latest version of the jboss-ejb-client (at >> least what I have here) is using a xnio version that does not contain >> the fix: >> >> 3.2.0.Final >> >> >> >> 2015-11-25 20:58 GMT-02:00 Thomas Fr?hbeck > >: >> >> thanks for the input, yet I am using following artifacts: >> >> >> org.jboss.xnio >> xnio-nio >> 3.3.2.Final >> >> >> The full source is available at: >> https://github.com/shadogray/securefs/tree/master/securefs-master/securefs-client-test >> >> >> And, just to make sure, the full command line reads: >> xnio-nio-3.3.2.Final.jar >> >> [DEBUG] Executing command line: [java, -classpath, >> /raid/home/thomas/workspace-sec/securefs/securefs-master/securefs-client-test/target/classes:\ >> /home/thomas/.m2/repository/at/tfr/securefs/securefs-client/1.1.0-SNAPSHOT/securefs-client-1.1.0-SNAPSHOT.jar:\ >> /home/thomas/.m2/repository/at/tfr/securefs/securefs-api/1.1.0-SNAPSHOT/securefs-api-1.1.0-SNAPSHOT.jar:\ >> /home/thomas/.m2/repository/org/jboss/logging/jboss-logging/3.1.4.GA/jboss-logging-3.1.4.GA.jar >> :\ >> /home/thomas/.m2/repository/commons-io/commons-io/2.4/commons-io-2.4.jar:\ >> /home/thomas/.m2/repository/commons-lang/commons-lang/2.6/commons-lang-2.6.jar:\ >> /home/thomas/.m2/repository/javax/javaee-api/7.0/javaee-api-7.0.jar:\ >> /home/thomas/.m2/repository/com/sun/mail/javax.mail/1.5.0/javax.mail-1.5.0.jar:\ >> /home/thomas/.m2/repository/javax/activation/activation/1.1/activation-1.1.jar:\ >> /home/thomas/.m2/repository/jboss/jboss-client/4.0.2/jboss-client-4.0.2.jar:\ >> /home/thomas/.m2/repository/org/jboss/jboss-remote-naming/2.0.4.Final/jboss-remote-naming-2.0.4.Final.jar:\ >> /home/thomas/.m2/repository/org/jboss/jboss-ejb-client/2.0.0.Final/jboss-ejb-client-2.0.0.Final.jar:\ >> /home/thomas/.m2/repository/org/jboss/marshalling/jboss-marshalling/1.4.3.Final/jboss-marshalling-1.4.3.Final.jar:\ >> /home/thomas/.m2/repository/org/jboss/marshalling/jboss-marshalling-river/1.4.3.Final/jboss-marshalling-river-1.4.3.Final.jar:\ >> /home/thomas/.m2/repository/org/jboss/xnio/xnio-api/3.2.0.Final/xnio-api-3.2.0.Final.jar:\ >> /home/thomas/.m2/repository/org/jboss/remoting/jboss-remoting/4.0.0.Final/jboss-remoting-4.0.0.Final.jar:\ >> /home/thomas/.m2/repository/org/jboss/sasl/jboss-sasl/1.0.4.Final/jboss-sasl-1.0.4.Final.jar:\ >> /home/thomas/.m2/repository/commons-cli/commons-cli/1.3.1/commons-cli-1.3.1.jar:\ >> /home/thomas/.m2/repository/org/jboss/xnio/xnio-nio/3.3.2.Final/xnio-nio-3.3.2.Final.jar:\ >> /home/thomas/.m2/repository/joda-time/joda-time/2.9/joda-time-2.9.jar, >> \ >> at.tfr.securefs.client.SecurefsClient, -b, >> sec:///raid/home/thomas/workspace-sec/securefs/securefs-master/securefs-client-test/target/, >> -a, false, -t, 10, -f, data/test/test.txt,data/test/test_main.txt] >> >> I am really looking forward to Wilfly 10.0.0 - especially clusterd >> deployment, and would appreciate to find anything blocking early. >> >> >> >> Am 25.11.2015 um 02:14 schrieb Eduardo Sant'Ana da Silva: >>> In my opinion, you should upgrade your client xnio version to one >>> later or equals to 3.2.1.Final. >>> >>> >>> On Nov 24, 2015, at 10:34 PM, Thomas Fr?hbeck >> > wrote: >>> >>>> you nailed it, thanks! >>>> unfortunate though :-/ >>>> >>>> Am 25.11.2015 um 01:30 schrieb Eduardo Sant?Ana da Silva: >>>>> Maybe this could help: >>>>> >>>>> https://issues.jboss.org/browse/XNIO-222 >>>>> >>>>> >>>>> 2015-11-24 20:33 GMT-02:00 Thomas Fr?hbeck >>>>> <fruehbeck at aon.at>: >>>>> >>>>> Hi, >>>>> I wanted to experiment with Wildfly 10.0.0.CR4 and Remoting >>>>> and got the >>>>> followin error on client side. I know, that my client works >>>>> perfectly >>>>> with 9.0.2.Final. >>>>> Can you guide me to the relevant changes, is this a known >>>>> problem? >>>>> >>>>> WARN: Could not register a EJB receiver for connection to >>>>> localhost:8080 >>>>> java.lang.RuntimeException: java.io.IOException: For now >>>>> upgrade >>>>> responses must have a content length of zero. >>>>> at >>>>> org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:92) >>>>> at >>>>> org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:77) >>>>> at >>>>> org.jboss.ejb.client.remoting.RemotingConnectionManager.getConnection(RemotingConnectionManager.java:51) >>>>> at >>>>> org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.setupEJBReceivers(ConfigBasedEJBClientContextSelector.java:155) >>>>> at >>>>> org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.getCurrent(ConfigBasedEJBClientContextSelector.java:115) >>>>> at >>>>> org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.getCurrent(ConfigBasedEJBClientContextSelector.java:47) >>>>> at >>>>> org.jboss.ejb.client.EJBClientContext.getCurrent(EJBClientContext.java:271) >>>>> at >>>>> org.jboss.ejb.client.EJBClientContext.requireCurrent(EJBClientContext.java:281) >>>>> at >>>>> org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:200) >>>>> at >>>>> org.jboss.ejb.client.naming.ejb.EjbNamingContext.doCreateProxy(EjbNamingContext.java:216) >>>>> at >>>>> org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:193) >>>>> at >>>>> org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:176) >>>>> at >>>>> javax.naming.InitialContext.lookup(InitialContext.java:417) >>>>> >>>>> Thanks, >>>>> Thomas >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev at lists.jboss.org >>>>> >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> __________________________ >>>>> Eduardo Sant'Ana da Silva - Dr. >>>>> Pesquisador / Consultor de TI >>>>> >>>> >>> >> >> >> >> >> -- >> __________________________ >> Eduardo Sant'Ana da Silva - Dr. >> Pesquisador / Consultor de TI >> > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From fruehbeck at aon.at Thu Nov 26 02:51:44 2015 From: fruehbeck at aon.at (=?UTF-8?Q?Thomas_Fr=c3=bchbeck?=) Date: Thu, 26 Nov 2015 08:51:44 +0100 Subject: [wildfly-dev] Problem remoting connection with wildfly 10.0.0.CR4 In-Reply-To: <5656AE81.6070608@redhat.com> References: <5654E5C4.3020008@aon.at> <5655021B.1070205@aon.at> <2894AFBE-440D-4600-83AA-A3BEE7970E52@gmail.com> <56563D05.7090805@aon.at> <5656AB47.9090304@aon.at> <5656AE81.6070608@redhat.com> Message-ID: <5656BA10.6040103@aon.at> absolutely right! I thougt jboss-client is the all-in-one jar like in /bin/client/jboss-client.jar which evidently contains XNIO: jar tfv /work/java/wildfly-10.0.0.CR4/bin/client/jboss-client.jar |grep xnio 0 Fri Oct 23 13:49:00 CEST 2015 org/xnio/ .. but I didnt check first place :-/ Exclusion works perfectly here though, thanks for notice! jboss jboss-client 4.0.2 org.jboss.xnio xnio-nio Regards, thomas Am 26.11.2015 um 08:02 schrieb Ladislav Thon: >> Quickest fix was to move dependency of XNIO _before_ jboss-client. > Or use a dependency exclusion. I think it's more clear, personally. > > LT > >> That settles it, best regards, >> thomas >> >> Am 26.11.2015 um 00:29 schrieb Eduardo Sant?Ana da Silva: >>> I've made the deployment of your application and I've got the same error. >>> >>> >>> You can see that the log of your test contains the XNIO version... >>> >>> ------------------------------------------------------- >>> >>> T E S T S >>> >>> ------------------------------------------------------- >>> >>> Running at.tfr.securefs.client.TestFileSystem >>> >>> Nov 25, 2015 9:18:47 PM org.xnio.Xnio >>> >>> INFO: XNIO version 3.2.0.Final >>> >>> Nov 25, 2015 9:18:48 PM org.xnio.nio.NioXnio >>> >>> INFO: XNIO NIO Implementation Version 3.3.2.Final >>> >>> Nov 25, 2015 9:18:48 PM org.jboss.remoting3.EndpointImpl >>> >>> INFO: JBoss Remoting version 4.0.0.Final >>> >>> Nov 25, 2015 9:18:49 PM org.jboss.ejb.client.EJBClient >>> >>> INFO: JBoss EJB Client version 2.0.0.Final >>> >>> Nov 25, 2015 9:18:51 PM >>> org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector >>> setupEJBReceivers >>> >>> WARN: Could not register a EJB receiver for connection to localhost:8080 >>> >>> java.lang.RuntimeException: java.io.IOException: For now upgrade >>> responses must have a content length of zero. >>> >>> >>> >>> .m2/repository/./org/jboss/jboss-ejb-client/2.1.3.Final/jboss-ejb-client-2.1.3.Final.pom >>> >>> >>> Here is the problem, the latest version of the jboss-ejb-client (at >>> least what I have here) is using a xnio version that does not contain >>> the fix: >>> >>> 3.2.0.Final >>> >>> >>> >>> 2015-11-25 20:58 GMT-02:00 Thomas Fr?hbeck >> >: >>> >>> thanks for the input, yet I am using following artifacts: >>> >>> >>> org.jboss.xnio >>> xnio-nio >>> 3.3.2.Final >>> >>> >>> The full source is available at: >>> https://github.com/shadogray/securefs/tree/master/securefs-master/securefs-client-test >>> >>> >>> And, just to make sure, the full command line reads: >>> xnio-nio-3.3.2.Final.jar >>> >>> [DEBUG] Executing command line: [java, -classpath, >>> /raid/home/thomas/workspace-sec/securefs/securefs-master/securefs-client-test/target/classes:\ >>> /home/thomas/.m2/repository/at/tfr/securefs/securefs-client/1.1.0-SNAPSHOT/securefs-client-1.1.0-SNAPSHOT.jar:\ >>> /home/thomas/.m2/repository/at/tfr/securefs/securefs-api/1.1.0-SNAPSHOT/securefs-api-1.1.0-SNAPSHOT.jar:\ >>> /home/thomas/.m2/repository/org/jboss/logging/jboss-logging/3.1.4.GA/jboss-logging-3.1.4.GA.jar >>> :\ >>> /home/thomas/.m2/repository/commons-io/commons-io/2.4/commons-io-2.4.jar:\ >>> /home/thomas/.m2/repository/commons-lang/commons-lang/2.6/commons-lang-2.6.jar:\ >>> /home/thomas/.m2/repository/javax/javaee-api/7.0/javaee-api-7.0.jar:\ >>> /home/thomas/.m2/repository/com/sun/mail/javax.mail/1.5.0/javax.mail-1.5.0.jar:\ >>> /home/thomas/.m2/repository/javax/activation/activation/1.1/activation-1.1.jar:\ >>> /home/thomas/.m2/repository/jboss/jboss-client/4.0.2/jboss-client-4.0.2.jar:\ >>> /home/thomas/.m2/repository/org/jboss/jboss-remote-naming/2.0.4.Final/jboss-remote-naming-2.0.4.Final.jar:\ >>> /home/thomas/.m2/repository/org/jboss/jboss-ejb-client/2.0.0.Final/jboss-ejb-client-2.0.0.Final.jar:\ >>> /home/thomas/.m2/repository/org/jboss/marshalling/jboss-marshalling/1.4.3.Final/jboss-marshalling-1.4.3.Final.jar:\ >>> /home/thomas/.m2/repository/org/jboss/marshalling/jboss-marshalling-river/1.4.3.Final/jboss-marshalling-river-1.4.3.Final.jar:\ >>> /home/thomas/.m2/repository/org/jboss/xnio/xnio-api/3.2.0.Final/xnio-api-3.2.0.Final.jar:\ >>> /home/thomas/.m2/repository/org/jboss/remoting/jboss-remoting/4.0.0.Final/jboss-remoting-4.0.0.Final.jar:\ >>> /home/thomas/.m2/repository/org/jboss/sasl/jboss-sasl/1.0.4.Final/jboss-sasl-1.0.4.Final.jar:\ >>> /home/thomas/.m2/repository/commons-cli/commons-cli/1.3.1/commons-cli-1.3.1.jar:\ >>> /home/thomas/.m2/repository/org/jboss/xnio/xnio-nio/3.3.2.Final/xnio-nio-3.3.2.Final.jar:\ >>> /home/thomas/.m2/repository/joda-time/joda-time/2.9/joda-time-2.9.jar, >>> \ >>> at.tfr.securefs.client.SecurefsClient, -b, >>> sec:///raid/home/thomas/workspace-sec/securefs/securefs-master/securefs-client-test/target/, >>> -a, false, -t, 10, -f, data/test/test.txt,data/test/test_main.txt] >>> >>> I am really looking forward to Wilfly 10.0.0 - especially clusterd >>> deployment, and would appreciate to find anything blocking early. >>> >>> >>> >>> Am 25.11.2015 um 02:14 schrieb Eduardo Sant'Ana da Silva: >>>> In my opinion, you should upgrade your client xnio version to one >>>> later or equals to 3.2.1.Final. >>>> >>>> >>>> On Nov 24, 2015, at 10:34 PM, Thomas Fr?hbeck >>> > wrote: >>>> >>>>> you nailed it, thanks! >>>>> unfortunate though :-/ >>>>> >>>>> Am 25.11.2015 um 01:30 schrieb Eduardo Sant?Ana da Silva: >>>>>> Maybe this could help: >>>>>> >>>>>> https://issues.jboss.org/browse/XNIO-222 >>>>>> >>>>>> >>>>>> 2015-11-24 20:33 GMT-02:00 Thomas Fr?hbeck >>>>>> <fruehbeck at aon.at>: >>>>>> >>>>>> Hi, >>>>>> I wanted to experiment with Wildfly 10.0.0.CR4 and Remoting >>>>>> and got the >>>>>> followin error on client side. I know, that my client works >>>>>> perfectly >>>>>> with 9.0.2.Final. >>>>>> Can you guide me to the relevant changes, is this a known >>>>>> problem? >>>>>> >>>>>> WARN: Could not register a EJB receiver for connection to >>>>>> localhost:8080 >>>>>> java.lang.RuntimeException: java.io.IOException: For now >>>>>> upgrade >>>>>> responses must have a content length of zero. >>>>>> at >>>>>> org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:92) >>>>>> at >>>>>> org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:77) >>>>>> at >>>>>> org.jboss.ejb.client.remoting.RemotingConnectionManager.getConnection(RemotingConnectionManager.java:51) >>>>>> at >>>>>> org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.setupEJBReceivers(ConfigBasedEJBClientContextSelector.java:155) >>>>>> at >>>>>> org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.getCurrent(ConfigBasedEJBClientContextSelector.java:115) >>>>>> at >>>>>> org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.getCurrent(ConfigBasedEJBClientContextSelector.java:47) >>>>>> at >>>>>> org.jboss.ejb.client.EJBClientContext.getCurrent(EJBClientContext.java:271) >>>>>> at >>>>>> org.jboss.ejb.client.EJBClientContext.requireCurrent(EJBClientContext.java:281) >>>>>> at >>>>>> org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:200) >>>>>> at >>>>>> org.jboss.ejb.client.naming.ejb.EjbNamingContext.doCreateProxy(EjbNamingContext.java:216) >>>>>> at >>>>>> org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:193) >>>>>> at >>>>>> org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:176) >>>>>> at >>>>>> javax.naming.InitialContext.lookup(InitialContext.java:417) >>>>>> >>>>>> Thanks, >>>>>> Thomas >>>>>> _______________________________________________ >>>>>> wildfly-dev mailing list >>>>>> wildfly-dev at lists.jboss.org >>>>>> >>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> __________________________ >>>>>> Eduardo Sant'Ana da Silva - Dr. >>>>>> Pesquisador / Consultor de TI >>>>>> >>> >>> >>> >>> -- >>> __________________________ >>> Eduardo Sant'Ana da Silva - Dr. >>> Pesquisador / Consultor de TI >>> >> >> >> _______________________________________________ >> 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 arjan.tijms at gmail.com Thu Nov 26 11:37:03 2015 From: arjan.tijms at gmail.com (arjan tijms) Date: Thu, 26 Nov 2015 17:37:03 +0100 Subject: [wildfly-dev] SimpleRoleGroup#roles In-Reply-To: References: <55753557.9070409@gmx.net> <55759BB8.9000808@redhat.com> <5575DE62.80207@redhat.com> Message-ID: Hi, On Mon, Jun 8, 2015 at 9:04 PM, arjan tijms wrote: > Having said that, the documentation does really seem to be missing a >> section about custom JACC providers so I went to check the TCK setup. It >> looks like the TCK JACC providers are bundled in a jar and this jar is >> being set as a resource of the org.jboss.as.security module. I'm not sure >> why it was done this way but I believe it should be also possible to define >> your own module containing the classes and then wire it to the security >> module as a dependency instead of a resource. >> > > Hmmm, how would one go about doing that exactly? I think I created a > module for my custom JACC provider, then set that as a dependency for the > security module (since that was the place the default implementation > lives), but it again did not work (class not found exceptions). Could well > be the case that I did something wrong, so an example would be great. > Sorry to ask again, but still wondering how to set a custom JACC provider ;) Incidentally, I found a rather grave bug in the default JACC provider where it checks principals purely based on their name, without taking their type into account. See https://issues.jboss.org/browse/WFLY-5740 Kind regards, Arjan Tijms -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151126/c5c7f5e1/attachment.html From sdouglas at redhat.com Thu Nov 26 18:09:53 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Thu, 26 Nov 2015 18:09:53 -0500 (EST) Subject: [wildfly-dev] Allow Camel LoadBalancer to connect to clustered WildFly HTTP endpoints In-Reply-To: References: Message-ID: <378612862.16145378.1448579393032.JavaMail.zimbra@redhat.com> I'm not really sure exactly what you mean here, do you want the Undertow load balancer to be able to use the data from the zookeper registry? Or are you talking about having the Undertow endpoints register themselves with zookeeper? Stuart ----- Original Message ----- > From: "Thomas Diesler" > To: "Stuart Douglas" > Cc: wildfly-dev at lists.jboss.org > Sent: Thursday, 26 November, 2015 1:03:16 AM > Subject: Allow Camel LoadBalancer to connect to clustered WildFly HTTP endpoints > > Hi Stuart/Friends, > > https://github.com/wildfly-extras/wildfly-camel/issues/878 > > > In fabric a camel load balancer can contact a (zookeeper) registry using a > logical name to react to changes in server topology or for initial > discovery. I wonder how this can/should be done in the context of undertow > http endpoints on wildfly. > > cheers > ? thomas From tdiesler at redhat.com Fri Nov 27 02:43:22 2015 From: tdiesler at redhat.com (Thomas Diesler) Date: Fri, 27 Nov 2015 08:43:22 +0100 Subject: [wildfly-dev] Allow Camel LoadBalancer to connect to clustered WildFly HTTP endpoints In-Reply-To: <378612862.16145378.1448579393032.JavaMail.zimbra@redhat.com> References: <378612862.16145378.1448579393032.JavaMail.zimbra@redhat.com> Message-ID: <80D5D0DA-A21D-4903-A2A9-09FEC413B00A@redhat.com> Zookeeper is part of the Fabric architecture. I may be an option in the context of this conversation, but its not something that we have already readily available. In the most simplistic scenario, we have a remote Camel Http client that wants to connect to cluster of wildfly servers that expose undertow endpoints. The Camel client wants to use a load balancer like this I now wonder if it is possible to implement a camel load balancer variant that is able to discover the initial topology of wildfly http endpoints and later react on changes in that topology. Does that make sense? cheers ? thomas > On 27 Nov 2015, at 00:09, Stuart Douglas wrote: > > I'm not really sure exactly what you mean here, do you want the Undertow load balancer to be able to use the data from the zookeper registry? Or are you talking about having the Undertow endpoints register themselves with zookeeper? > > Stuart > > ----- Original Message ----- >> From: "Thomas Diesler" >> To: "Stuart Douglas" >> Cc: wildfly-dev at lists.jboss.org >> Sent: Thursday, 26 November, 2015 1:03:16 AM >> Subject: Allow Camel LoadBalancer to connect to clustered WildFly HTTP endpoints >> >> Hi Stuart/Friends, >> >> https://github.com/wildfly-extras/wildfly-camel/issues/878 >> >> >> In fabric a camel load balancer can contact a (zookeeper) registry using a >> logical name to react to changes in server topology or for initial >> discovery. I wonder how this can/should be done in the context of undertow >> http endpoints on wildfly. >> >> cheers >> ? thomas > > _______________________________________________ > 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/20151127/c916e50b/attachment.html From sdouglas at redhat.com Fri Nov 27 03:21:08 2015 From: sdouglas at redhat.com (Stuart Douglas) Date: Fri, 27 Nov 2015 03:21:08 -0500 (EST) Subject: [wildfly-dev] Allow Camel LoadBalancer to connect to clustered WildFly HTTP endpoints In-Reply-To: <80D5D0DA-A21D-4903-A2A9-09FEC413B00A@redhat.com> References: <378612862.16145378.1448579393032.JavaMail.zimbra@redhat.com> <80D5D0DA-A21D-4903-A2A9-09FEC413B00A@redhat.com> Message-ID: <1920798889.16251295.1448612468922.JavaMail.zimbra@redhat.com> So the load balancing happens on the client side? Stuart ----- Original Message ----- > From: "Thomas Diesler" > To: "Stuart Douglas" > Cc: wildfly-dev at lists.jboss.org > Sent: Friday, 27 November, 2015 6:43:22 PM > Subject: Re: [wildfly-dev] Allow Camel LoadBalancer to connect to clustered WildFly HTTP endpoints > > Zookeeper is part of the Fabric architecture. I may be an option in the > context of this conversation, but its not something that we have already > readily available. > > In the most simplistic scenario, we have a remote Camel Http client that > wants to connect to cluster of wildfly servers that expose undertow > endpoints. The Camel client wants to use a load balancer > like this > > > > > > > > > > > > > > I now wonder if it is possible to implement a camel load balancer variant > that is able to discover the initial topology of wildfly http endpoints and > later react on changes in that topology. Does that make sense? > > cheers > ? thomas > > > On 27 Nov 2015, at 00:09, Stuart Douglas wrote: > > > > I'm not really sure exactly what you mean here, do you want the Undertow > > load balancer to be able to use the data from the zookeper registry? Or > > are you talking about having the Undertow endpoints register themselves > > with zookeeper? > > > > Stuart > > > > ----- Original Message ----- > >> From: "Thomas Diesler" > >> To: "Stuart Douglas" > >> Cc: wildfly-dev at lists.jboss.org > >> Sent: Thursday, 26 November, 2015 1:03:16 AM > >> Subject: Allow Camel LoadBalancer to connect to clustered WildFly HTTP > >> endpoints > >> > >> Hi Stuart/Friends, > >> > >> https://github.com/wildfly-extras/wildfly-camel/issues/878 > >> > >> > >> In fabric a camel load balancer can contact a (zookeeper) registry using a > >> logical name to react to changes in server topology or for initial > >> discovery. I wonder how this can/should be done in the context of undertow > >> http endpoints on wildfly. > >> > >> cheers > >> ? thomas > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > From tdiesler at redhat.com Fri Nov 27 03:27:37 2015 From: tdiesler at redhat.com (Thomas Diesler) Date: Fri, 27 Nov 2015 09:27:37 +0100 Subject: [wildfly-dev] Allow Camel LoadBalancer to connect to clustered WildFly HTTP endpoints In-Reply-To: <1920798889.16251295.1448612468922.JavaMail.zimbra@redhat.com> References: <378612862.16145378.1448579393032.JavaMail.zimbra@redhat.com> <80D5D0DA-A21D-4903-A2A9-09FEC413B00A@redhat.com> <1920798889.16251295.1448612468922.JavaMail.zimbra@redhat.com> Message-ID: <33FC7545-8E4C-46E5-BC56-729C2E282412@redhat.com> yes > On 27 Nov 2015, at 09:21, Stuart Douglas wrote: > > So the load balancing happens on the client side? > > Stuart > > ----- Original Message ----- >> From: "Thomas Diesler" >> To: "Stuart Douglas" >> Cc: wildfly-dev at lists.jboss.org >> Sent: Friday, 27 November, 2015 6:43:22 PM >> Subject: Re: [wildfly-dev] Allow Camel LoadBalancer to connect to clustered WildFly HTTP endpoints >> >> Zookeeper is part of the Fabric architecture. I may be an option in the >> context of this conversation, but its not something that we have already >> readily available. >> >> In the most simplistic scenario, we have a remote Camel Http client that >> wants to connect to cluster of wildfly servers that expose undertow >> endpoints. The Camel client wants to use a load balancer >> like this >> >> >> >> >> >> >> >> >> >> >> >> >> >> I now wonder if it is possible to implement a camel load balancer variant >> that is able to discover the initial topology of wildfly http endpoints and >> later react on changes in that topology. Does that make sense? >> >> cheers >> ? thomas >> >>> On 27 Nov 2015, at 00:09, Stuart Douglas wrote: >>> >>> I'm not really sure exactly what you mean here, do you want the Undertow >>> load balancer to be able to use the data from the zookeper registry? Or >>> are you talking about having the Undertow endpoints register themselves >>> with zookeeper? >>> >>> Stuart >>> >>> ----- Original Message ----- >>>> From: "Thomas Diesler" >>>> To: "Stuart Douglas" >>>> Cc: wildfly-dev at lists.jboss.org >>>> Sent: Thursday, 26 November, 2015 1:03:16 AM >>>> Subject: Allow Camel LoadBalancer to connect to clustered WildFly HTTP >>>> endpoints >>>> >>>> Hi Stuart/Friends, >>>> >>>> https://github.com/wildfly-extras/wildfly-camel/issues/878 >>>> >>>> >>>> In fabric a camel load balancer can contact a (zookeeper) registry using a >>>> logical name to react to changes in server topology or for initial >>>> discovery. I wonder how this can/should be done in the context of undertow >>>> http endpoints on wildfly. >>>> >>>> cheers >>>> ? thomas >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> From tomaz.cerar at gmail.com Fri Nov 27 06:27:52 2015 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Fri, 27 Nov 2015 12:27:52 +0100 Subject: [wildfly-dev] Allow Camel LoadBalancer to connect to clustered WildFly HTTP endpoints In-Reply-To: <80D5D0DA-A21D-4903-A2A9-09FEC413B00A@redhat.com> References: <378612862.16145378.1448579393032.JavaMail.zimbra@redhat.com> <80D5D0DA-A21D-4903-A2A9-09FEC413B00A@redhat.com> Message-ID: On Fri, Nov 27, 2015 at 8:43 AM, Thomas Diesler wrote: > > I now wonder if it is possible to implement a camel load balancer variant > that is able to discover the initial topology of wildfly http endpoints and > later react on changes in that topology. Does that make sense? > I am thinking that you could register undertow subsystem event listeners in camel subsystem (or any other that is for that purpase) So undertow subsystem would send you events on when deployments are started/stopped, hosts are started/stopped. see https://github.com/wildfly/wildfly/blob/master/undertow/src/main/java/org/wildfly/extension/undertow/UndertowEventListener.java for what is possible This is how we integrate with mod_cluster subsystem that than broadcasts the config to the apache mod_cluster module. You could get this events and than push config to zookeeper based on that. would that work for you? -- tomaz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151127/78540611/attachment.html From rory.odonnell at oracle.com Fri Nov 27 07:35:20 2015 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Fri, 27 Nov 2015 12:35:20 +0000 Subject: [wildfly-dev] Early Access b93 is available for JDK 9 on java.net Message-ID: <56584E08.4020609@oracle.com> Hi Jason/Tomaz, Thanks for confirming the fix , in addition to your fix a number of new JEPs have been integrated into JDK 9 b93 I'd like to point you to a few that are now available for testing in this JDK 9 Early Access build: JEP 254: Compact Strings (http://openjdk.java.net/jeps/254) This JEP adopts a more space-efficient internal representation for strings. We propose to change the internal representation of the String class from a UTF-16 char array to a byte array plus an encoding-flag field. The new String class will store characters encoded either as ISO-8859-1/Latin-1 (one byte per character), or as UTF-16 (two bytes per character), based upon the contents of the string. The encoding flag will indicate which encoding is used. JEP 165: Compiler Control (http://openjdk.java.net/jeps/165) This JEP proposes an improved way to control the JVM compilers. It enables runtime manageable, method dependent compiler flags. (Immutable for the duration of a compilation.) Method-context dependent control of the compilation process is a powerful tool for writing small contained JVM compiler tests that can be run without restarting the entire JVM. It is also very useful for creating workarounds for bugs in the JVM compilers. JEP 243: Java-Level JVM Compiler Interface (http://openjdk.java.net/jeps/243) This JEP instruments the data flows within the JVM which are used by the JIT compiler to allow Java code to observe, query, and affect the JVM's compilation process and its associated metadata. JEP 268: XML Catalog API (http://openjdk.java.net/jeps/268) This JEP develops a standard XML Catalog API that supports the OASIS XML Catalogs standard, v1.1. The API will define catalog and catalog-resolver abstractions which can be used with the JAXP processors that accept resolvers. Existing libraries or applications that use the internal API will need to migrate to the new API in order to take advantage of the new features. Rgds, Rory -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland From lgao at redhat.com Mon Nov 30 02:28:34 2015 From: lgao at redhat.com (Lin Gao) Date: Mon, 30 Nov 2015 02:28:34 -0500 (EST) Subject: [wildfly-dev] Shall we limit size of the deployment in WildFly? In-Reply-To: <563A10F3.5030508@redhat.com> References: <24706283.2168206.1446540061297.JavaMail.zimbra@redhat.com> <5638B46A.9050103@redhat.com> <432170035.3201449.1446599629356.JavaMail.zimbra@redhat.com> <5639CBB1.5050805@jboss.com> <5874D840-F955-41D1-A617-DECD1498CF64@redhat.com> <563A0D96.40905@jboss.com> <563A10F3.5030508@redhat.com> Message-ID: <18243493.27598643.1448868514202.JavaMail.zimbra@redhat.com> > From: "Brian Stansberry" > To: wildfly-dev at lists.jboss.org > Sent: Wednesday, November 4, 2015 10:06:43 PM > Subject: Re: [wildfly-dev] Shall we limit size of the deployment in WildFly? > > It shouldn't as part of the management API, no.[1] Any total size > information that gets exchanged is part of the underlying management > communication protocol used for propagating streams and isn't exposed > outside that layer. I'd like to see even that bit go away too, as it's > unnecessary and wastes resources on the client. > > [1] In some cases the CLI actually sends the deployment bytes base 64 > encoded as a param to the op, in which case the size info is available > to the operation step handler. I consider that CLI behavior to be a bug > though. Do you recall which cases that the CLI will send deployment bytes instead of the input stream? :-) Best Regards -- Lin Gao Software Engineer JBoss by Red Hat > On 11/4/15 7:52 AM, Darran Lofthouse wrote: > > Does the op in the CLI send any length information? That would help the > > two be consistent. > > > > On 04/11/15 12:29, Jason T. Greene wrote: > >> > >> On Nov 4, 2015, at 4:36 AM, Heiko Braun >> > wrote: > >> > >>> GWT boils down to plain web technologies. And no, AFAIKT there is no > >>> way to check the size of an uploaded file across web browsers. Most > >>> browsers do however have an implicit limitation on the file size, > >>> which for majority is about 2 GB. > >> > >> You can now that we have switched to XHR to do the upload. The File > >> object returned from a file list has a size property that you can use. > >> > >> So you could in theory check that there is available space before > >> posting, however, since as Stuart mentions, browsers set a content > >> length, the server knows it anyway so it's less racy checking at the > >> server level, if one was to check. > >> > >> > >>> > >>>> On 04 Nov 2015, at 10:11, Darran Lofthouse > >>>> > wrote: > >>>> > >>>> From within GWT is there any option to detect the file size before > >>>> uploading? > >>> > >>> _______________________________________________ > >>> 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 > > > > > -- > 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 > From tdiesler at redhat.com Mon Nov 30 03:34:53 2015 From: tdiesler at redhat.com (Thomas Diesler) Date: Mon, 30 Nov 2015 09:34:53 +0100 Subject: [wildfly-dev] Allow Camel LoadBalancer to connect to clustered WildFly HTTP endpoints In-Reply-To: References: <378612862.16145378.1448579393032.JavaMail.zimbra@redhat.com> <80D5D0DA-A21D-4903-A2A9-09FEC413B00A@redhat.com> Message-ID: Yes, thank you - that?s an option. ? thomas > On 27 Nov 2015, at 12:27, Toma? Cerar wrote: > > > On Fri, Nov 27, 2015 at 8:43 AM, Thomas Diesler > wrote: > > I now wonder if it is possible to implement a camel load balancer variant that is able to discover the initial topology of wildfly http endpoints and later react on changes in that topology. Does that make sense? > > > I am thinking that you could register undertow subsystem event listeners in camel subsystem (or any other that is for that purpase) > So undertow subsystem would send you events on when deployments are started/stopped, hosts are started/stopped. > see https://github.com/wildfly/wildfly/blob/master/undertow/src/main/java/org/wildfly/extension/undertow/UndertowEventListener.java for what is possible > > This is how we integrate with mod_cluster subsystem that than broadcasts the config to the apache mod_cluster module. > > You could get this events and than push config to zookeeper based on that. > > would that work for you? > > -- > tomaz > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151130/8b1eaf0a/attachment.html From brian.stansberry at redhat.com Mon Nov 30 11:08:54 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 30 Nov 2015 10:08:54 -0600 Subject: [wildfly-dev] Shall we limit size of the deployment in WildFly? In-Reply-To: <18243493.27598643.1448868514202.JavaMail.zimbra@redhat.com> References: <24706283.2168206.1446540061297.JavaMail.zimbra@redhat.com> <5638B46A.9050103@redhat.com> <432170035.3201449.1446599629356.JavaMail.zimbra@redhat.com> <5639CBB1.5050805@jboss.com> <5874D840-F955-41D1-A617-DECD1498CF64@redhat.com> <563A0D96.40905@jboss.com> <563A10F3.5030508@redhat.com> <18243493.27598643.1448868514202.JavaMail.zimbra@redhat.com> Message-ID: <565C7496.8090205@redhat.com> On 11/30/15 1:28 AM, Lin Gao wrote: >> From: "Brian Stansberry" >> >> [1] In some cases the CLI actually sends the deployment bytes base 64 >> encoded as a param to the op, in which case the size info is available >> to the operation step handler. I consider that CLI behavior to be a bug >> though. > > Do you recall which cases that the CLI will send deployment bytes instead of the input stream? :-) > In CLI batches. See comments on https://issues.jboss.org/browse/WFCORE-695 -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From lgao at redhat.com Mon Nov 30 21:56:59 2015 From: lgao at redhat.com (Lin Gao) Date: Mon, 30 Nov 2015 21:56:59 -0500 (EST) Subject: [wildfly-dev] Shall we limit size of the deployment in WildFly? In-Reply-To: References: <24706283.2168206.1446540061297.JavaMail.zimbra@redhat.com> <5638B46A.9050103@redhat.com> <432170035.3201449.1446599629356.JavaMail.zimbra@redhat.com> <556E0C61-5F39-4557-B640-4035474E8563@redhat.com> Message-ID: <1886549037.29460049.1448938619962.JavaMail.zimbra@redhat.com> There are 2 aspects on this issue which we need to concern I think: 1. How to get the size of the file which will be uploaded In most cases, it is possible to know the size of the uploaded file, in web console, GWT file object has a size property, in CLI, Java codes can get the file size by: File.length() method, but in case of CLI: 'deploy --url=http://XXX.zip' while the url points to a resource using chunked encoding(no Content-Length available) transfer, we don't know the size at all when content repository starts to download. 2. How to know that the disk space is enough to hold the file processing In web console, Undertow will store the file to system temporary directory ('/tmp/')first, then content repository will copy it to the it's root directory for processing. In CLI, the content repository will dump the stream to it's root directory('data/content/') for processing. Normally, the deployer will un-zipped the zip file to 'tmp/vfs/temp/', the size of the exploded files will be much bigger than the zip file itself.(consider the zip bomb... ?) Apparently, the disk space to hold the file processing is at least more than double the size of uploaded file. The concrete available disk space is hard to know, and it is changing all over the time(thinking of logs). After reconsideration, I agree with Stuart that adding any kind of limit seems like this has the potential to cause more problems than it will solve. :-) So back to the original question as $subject: Shall we limit size of the deployment in WildFly? or do we want to continue on proceeding this issue ? Best Regards -- Lin Gao Software Engineer JBoss by Red Hat ----- Original Message ----- > From: "Jason T. Greene" > To: "Lin Gao" > Cc: wildfly-dev at lists.jboss.org > Sent: Wednesday, November 4, 2015 9:41:36 PM > Subject: Re: [wildfly-dev] Shall we limit size of the deployment in WildFly? > > > > On Nov 4, 2015, at 6:48 AM, Jason T. Greene > > wrote: > > > > I do not think we should have a hard coded limit as a constant because that > > will prevent legit deployments from working, and you can still run out of > > disk space (e.g you have 20k left and you upload a 21k deployment, which > > is under 1G) > > > > We could have an extra check that verifies enough disk space in the add > > content management op, however Java does not give us access to quota > > information so the best we could do is only verify available disk space > > (unless we exec a command for every platform we support). > > One thing I forgot to get into was domain mode. Runtime verification is > straight forward on standalone, but on domain mode the deployment is pulled > by arbitrary hosts, which each may have varying disk capacity. > > So in the host case we can only error later on and after the fact. Hosts try > to pull down content in the content repository (where deployments are > stored) only when they need them, and this can happen well after a > deployment is added. As an example, 3 weeks later you could add a server to > a host that's in a server group that requires a download of a deployment, > and at that point go over capacity. From brian.stansberry at redhat.com Mon Nov 30 22:17:41 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 30 Nov 2015 21:17:41 -0600 Subject: [wildfly-dev] Shall we limit size of the deployment in WildFly? In-Reply-To: <1886549037.29460049.1448938619962.JavaMail.zimbra@redhat.com> References: <24706283.2168206.1446540061297.JavaMail.zimbra@redhat.com> <5638B46A.9050103@redhat.com> <432170035.3201449.1446599629356.JavaMail.zimbra@redhat.com> <556E0C61-5F39-4557-B640-4035474E8563@redhat.com> <1886549037.29460049.1448938619962.JavaMail.zimbra@redhat.com> Message-ID: <565D1155.7030106@redhat.com> On 11/30/15 8:56 PM, Lin Gao wrote: > There are 2 aspects on this issue which we need to concern I think: > > 1. How to get the size of the file which will be uploaded > > In most cases, it is possible to know the size of the uploaded file, > in web console, GWT file object has a size property, in CLI, Java codes > can get the file size by: File.length() method, but in case of CLI: > 'deploy --url=http://XXX.zip' while the url points to a resource using > chunked encoding(no Content-Length available) transfer, we don't know the > size at all when content repository starts to download. We also may not know it on the client side (CLI process) regardless of chunked encoding, as the URL is meant to be opened from the server and there is no requirement that the client be able to access it. So for this kind of deployment there is no consistent way for the CLI to check in advance that the deployment will succeed. > > 2. How to know that the disk space is enough to hold the file processing > > In web console, Undertow will store the file to system temporary directory > ('/tmp/')first, then content repository will copy it to the it's root directory > for processing. In CLI, the content repository will dump the stream to it's root > directory('data/content/') for processing. Normally, the deployer will > un-zipped the zip file to 'tmp/vfs/temp/', the size of the exploded files > will be much bigger than the zip file itself.(consider the zip bomb... ?) > > Apparently, the disk space to hold the file processing is at least more than > double the size of uploaded file. The concrete available disk space is hard to know, > and it is changing all over the time(thinking of logs). > > After reconsideration, I agree with Stuart that adding any kind of limit seems > like this has the potential to cause more problems than it will solve. :-) > > So back to the original question as $subject: Shall we limit size of the > deployment in WildFly? or do we want to continue on proceeding this issue ? > No to both questions. It's not feasible to create a robust feature. Good analysis; thanks. > > Best Regards > -- > Lin Gao > Software Engineer > JBoss by Red Hat > > ----- Original Message ----- >> From: "Jason T. Greene" >> To: "Lin Gao" >> Cc: wildfly-dev at lists.jboss.org >> Sent: Wednesday, November 4, 2015 9:41:36 PM >> Subject: Re: [wildfly-dev] Shall we limit size of the deployment in WildFly? >> >> >>> On Nov 4, 2015, at 6:48 AM, Jason T. Greene >>> wrote: >>> >>> I do not think we should have a hard coded limit as a constant because that >>> will prevent legit deployments from working, and you can still run out of >>> disk space (e.g you have 20k left and you upload a 21k deployment, which >>> is under 1G) >>> >>> We could have an extra check that verifies enough disk space in the add >>> content management op, however Java does not give us access to quota >>> information so the best we could do is only verify available disk space >>> (unless we exec a command for every platform we support). >> >> One thing I forgot to get into was domain mode. Runtime verification is >> straight forward on standalone, but on domain mode the deployment is pulled >> by arbitrary hosts, which each may have varying disk capacity. >> >> So in the host case we can only error later on and after the fact. Hosts try >> to pull down content in the content repository (where deployments are >> stored) only when they need them, and this can happen well after a >> deployment is added. As an example, 3 weeks later you could add a server to >> a host that's in a server group that requires a download of a deployment, >> and at that point go over capacity. > _______________________________________________ > 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