From rory.odonnell at oracle.com Tue Mar 1 05:15:19 2016 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Tue, 1 Mar 2016 10:15:19 +0000 Subject: [wildfly-dev] Early Access builds of JDK 9 b107 & JDK 9 with Project Jigsaw b106 (#4540) are available on java.net Message-ID: <56D56BB7.2090402@oracle.com> Hi Jason/Tomaz, Early Access b107 for JDK 9 is available on java.net, summary of changes are listed here . Among other fixes , the following are also included: * Update class file version to 53 for JDK-9, more info here * Add support for ES6 collections , more info here Early Access b106 (#4540) for JDK 9 with Project Jigsaw is available on java.net. The March 2016 Quality Outreach Report is posted on here, thanks again to those who found & logged bugs against Early Access builds. Rgds,Rory -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160301/1a8a2981/attachment.html From gunnar at hibernate.org Sat Mar 5 14:25:11 2016 From: gunnar at hibernate.org (Gunnar Morling) Date: Sat, 5 Mar 2016 20:25:11 +0100 Subject: [wildfly-dev] Starting/monitoring JSR 352 batch job through admin console Message-ID: Hi, Is it possible to to start and monitor progress of JSR 352 batch jobs in the admin console? I came across https://issues.jboss.org/browse/WFLY-3174 which states that it's possible through the CLI and other management interfaces but not the UI. Is this still the case? Thanks, --Gunnar From eduardo.santanadasilva at gmail.com Sun Mar 6 07:51:08 2016 From: eduardo.santanadasilva at gmail.com (=?UTF-8?Q?Eduardo_Sant=C2=B4Ana_da_Silva?=) Date: Sun, 6 Mar 2016 09:51:08 -0300 Subject: [wildfly-dev] Issues in tests with Security Manager Message-ID: Hi all, I'm looking at the opened issues on JIRA related to tests with the security manager. Probably the cause is only one, but we have a plethora of issues regarding this subject that it will be a nightmare to track later. Shouldn't we have only one on WFLY and another on JBEAP with the description like JBEAP-971: Fix issues in tests with Security Manager The last opened issue has two days of age, and I think that will continue have more of them sooner or later. https://issues.jboss.org/browse/WFLY-6189 https://issues.jboss.org/browse/JBEAP-3376 https://issues.jboss.org/browse/WFLY-6191 https://issues.jboss.org/browse/JBEAP-3377 https://issues.jboss.org/browse/WFLY-6190 https://issues.jboss.org/browse/WFLY-6192 https://issues.jboss.org/browse/JBEAP-3378 https://issues.jboss.org/browse/WFLY-6193 https://issues.jboss.org/browse/JBEAP-3380 https://issues.jboss.org/browse/WFLY-6194 https://issues.jboss.org/browse/JBEAP-3381 https://issues.jboss.org/browse/WFLY-6195 https://issues.jboss.org/browse/JBEAP-3382 https://issues.jboss.org/browse/WFLY-6196 https://issues.jboss.org/browse/JBEAP-3390 https://issues.jboss.org/browse/WFLY-6189 https://issues.jboss.org/browse/JBEAP-3375 https://issues.jboss.org/browse/JBEAP-971 https://issues.jboss.org/browse/JBEAP-3382 Regards, -- ___________________________ 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/20160306/1429a975/attachment.html From david.lloyd at redhat.com Sun Mar 6 10:52:28 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Sun, 6 Mar 2016 09:52:28 -0600 Subject: [wildfly-dev] Issues in tests with Security Manager In-Reply-To: References: Message-ID: <56DC523C.60605@redhat.com> Maybe have one JBEAP issue, and one parent WFLY issue with all the specific problems being sub-tasks? On 03/06/2016 06:51 AM, Eduardo Sant?Ana da Silva wrote: > Hi all, > > I'm looking at the opened issues on JIRA related to tests with the > security manager. > Probably the cause is only one, but we have a plethora of issues > regarding this subject that it will be a nightmare to track later. > > Shouldn't we have only one on WFLY and another on JBEAP with the > description like JBEAP-971: Fix issues in tests with Security Manager > > The last opened issue has two days of age, and I think that will > continue have more of them sooner or later. > > https://issues.jboss.org/browse/WFLY-6189 > https://issues.jboss.org/browse/JBEAP-3376 > https://issues.jboss.org/browse/WFLY-6191 > https://issues.jboss.org/browse/JBEAP-3377 > https://issues.jboss.org/browse/WFLY-6190 > https://issues.jboss.org/browse/WFLY-6192 > https://issues.jboss.org/browse/JBEAP-3378 > https://issues.jboss.org/browse/WFLY-6193 > https://issues.jboss.org/browse/JBEAP-3380 > https://issues.jboss.org/browse/WFLY-6194 > https://issues.jboss.org/browse/JBEAP-3381 > https://issues.jboss.org/browse/WFLY-6195 > https://issues.jboss.org/browse/JBEAP-3382 > https://issues.jboss.org/browse/WFLY-6196 > https://issues.jboss.org/browse/JBEAP-3390 > https://issues.jboss.org/browse/WFLY-6189 > https://issues.jboss.org/browse/JBEAP-3375 > https://issues.jboss.org/browse/JBEAP-971 > https://issues.jboss.org/browse/JBEAP-3382 > > > Regards, > -- > ___________________________ > 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 > -- - DML From hpehl at redhat.com Mon Mar 7 02:54:59 2016 From: hpehl at redhat.com (Harald Pehl) Date: Mon, 7 Mar 2016 08:54:59 +0100 Subject: [wildfly-dev] Starting/monitoring JSR 352 batch job through admin console In-Reply-To: References: Message-ID: <364315C6-E65B-4F72-AF9E-50666E4ED38E@redhat.com> Currently there?s no dedicated support for that in the admin console. However you can view any kind of resource which is part of a deployment in a generic model browser. Just select the active deployment and click ?View? to see all details about the deployment and its subsystems. We might add a more sophisticated support for that in one of the next releases. > On 05 Mar 2016, at 20:25, Gunnar Morling wrote: > > Hi, > > Is it possible to to start and monitor progress of JSR 352 batch jobs > in the admin console? > > I came across https://issues.jboss.org/browse/WFLY-3174 which states > that it's possible through the CLI and other management interfaces but > not the UI. Is this still the case? > > Thanks, > > --Gunnar > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From rory.odonnell at oracle.com Sat Mar 19 03:41:48 2016 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Sat, 19 Mar 2016 13:11:48 +0530 Subject: [wildfly-dev] Early Access builds of JDK 9 b110 & JDK 9 with Project Jigsaw b110 (#4664) are available on java.net Message-ID: <56ED02BC.6030203@oracle.com> Hi Jason/Tomaz, Early Access b110 for JDK 9 is available on java.net, summary of changes are listed here . Among other fixes , the following changes are also included from builds 108 to 110 o removal of the OS X-specific com.apple.concurrent package o update to the JAX-WS RI integration to latest version (2.3.0-SNAPSHOT) o disabling of Diffie-Hellman keys smaller than 1024 bits Early Access b110 (#4664) for JDK 9 with Project Jigsaw is available on java.net. We expect this will be the last EA build before we integrate into JDK 9. This means that this EA build is essentially what will be jdk-9+111 next week. As always, please help out by trying out existing code and libraries to see what works and doesn't work. We have a detailed list of compatibility issues listed in JEP 261 [2]. Also feedback and questions from those that trying the EA build to modularize existing code would be appreciated. We also want to know what works and doesn't work here [3] Rgds,Rory [1] https://jdk9.java.net/jigsaw/ [2] http://openjdk.java.net/jeps/261 [3] http://mail.openjdk.java.net/pipermail/jigsaw-dev/ -- 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/20160319/b5a3fa84/attachment-0001.html From lgao at redhat.com Mon Mar 21 03:49:26 2016 From: lgao at redhat.com (Lin Gao) Date: Mon, 21 Mar 2016 03:49:26 -0400 (EDT) Subject: [wildfly-dev] Copy artifact jar with some files filtered out during wildfly feature build? In-Reply-To: <1099310968.38690928.1458543837582.JavaMail.zimbra@redhat.com> Message-ID: <1943070313.38703087.1458546566985.JavaMail.zimbra@redhat.com> Hi, There is an issue on composing native bits of Artemis during wildfly full-feature-pack build, that the 'libartemis-native.so' is duplicated. One is at: 'modules/system/layers/base/org/apache/activemq/artemis/main/lib/linux-/libartemis-native-.so', and another is at: 'lib/linux-i686/libartemis-native-.so' in the artemis-native.jar file. The duplication of the native bits will confuse the user which one is actually used, and which one to patch in case of one-off. IMHO, we can add support in wildfly-build-tool to copy a jar file with some files excluded, so that we can filter out the 'libartemis-native-.so' in the artemis-native.jar during the wildfly-full-featch-pack build, like: Do you guys think it makes sense? Best Regards -- Lin Gao Software Engineer JBoss by Red Hat From stuart.w.douglas at gmail.com Mon Mar 21 04:02:19 2016 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Mon, 21 Mar 2016 08:02:19 +0000 Subject: [wildfly-dev] Copy artifact jar with some files filtered out during wildfly feature build? In-Reply-To: <1943070313.38703087.1458546566985.JavaMail.zimbra@redhat.com> References: <1099310968.38690928.1458543837582.JavaMail.zimbra@redhat.com> <1943070313.38703087.1458546566985.JavaMail.zimbra@redhat.com> Message-ID: On Mon, 21 Mar 2016 at 18:49 Lin Gao wrote: > Hi, > > There is an issue on composing native bits of Artemis during wildfly > full-feature-pack build, that the 'libartemis-native.so' is duplicated. > One is at: > 'modules/system/layers/base/org/apache/activemq/artemis/main/lib/linux-/libartemis-native-.so', > and another is at: 'lib/linux-i686/libartemis-native-.so' in the > artemis-native.jar file. > > The duplication of the native bits will confuse the user which one is > actually used, and which one to patch in case of one-off. > Will it thought? The only way they will know the other one is there is if they unzip the jar file, which seems unlikely. In terms of patches the patch tool should just update the bits that need to be replaced, I don't see how there would be the potential for confusion. > > IMHO, we can add support in wildfly-build-tool to copy a jar file with > some files excluded, so that we can filter out the 'libartemis-native-.so' > in the artemis-native.jar during the wildfly-full-featch-pack build, like: > > to-location="modules/system/layers/base/org/apache/activemq/artemis/main/" > extract="FALSE"> > > > > > Do you guys think it makes sense? > No the following reasons: - The feature pack is the definition of the server, not the resulting build from a server. We are telling downstream projects (such as swarm) to build from these feature packs, so this change would not be propagated to downstream projects. Also if a user provisioned directly from feature packs this change would not be present. - This cannot be done for servers that use maven artifact references, so you will get a better result depending on how it is provisioned. - In general I don't think editing 3rd party jar files as part of our build process is a good idea. Stuart > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160321/b9472bf7/attachment.html From hamedhatami2012 at gmail.com Mon Mar 21 04:07:44 2016 From: hamedhatami2012 at gmail.com (Hamed Hatami) Date: Mon, 21 Mar 2016 12:37:44 +0430 Subject: [wildfly-dev] Infinispan search Message-ID: Hi guys, I wanna use infinispan search dsl on wildfly 10 but there are not related library on infinispan module , what to I do? Regards, Hamed Hatami -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160321/a554dcbd/attachment.html From ttarrant at redhat.com Mon Mar 21 05:02:36 2016 From: ttarrant at redhat.com (Tristan Tarrant) Date: Mon, 21 Mar 2016 10:02:36 +0100 Subject: [wildfly-dev] Infinispan search In-Reply-To: References: Message-ID: <56EFB8AC.70604@redhat.com> You need to use the Infinispan WildFly modules which you get from here: http://infinispan.org/download/ Tristan On 21/03/2016 09:07, Hamed Hatami wrote: > Hi guys, > > I wanna use infinispan search dsl on wildfly 10 but there are not > related library on infinispan module , what to I do? > > Regards, > Hamed Hatami > > > > _______________________________________________ > 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 tomaz.cerar at gmail.com Mon Mar 21 10:51:51 2016 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Mon, 21 Mar 2016 15:51:51 +0100 Subject: [wildfly-dev] Early Access builds of JDK 9 b110 & JDK 9 with Project Jigsaw b110 (#4664) are available on java.net In-Reply-To: <56ED02BC.6030203@oracle.com> References: <56ED02BC.6030203@oracle.com> Message-ID: Hi Rory, We already test WildFly and all "our" projects WildFly depends on, on both JDK9 builds. We did find handful of issues with Jigsaw builds which mostly relate back to either issues in jigsaw itself or problems in JDK itself once it runs on jigsaw. Which is the biggest thing giving us problems at the moment. see for details: http://mail.openjdk.java.net/pipermail/jpms-spec-observers/2016-March/000305.html you can track our progress at our CI at (currently tested from my branches) https://ci.wildfly.org/viewType.html?buildTypeId=WildFlyCore_MasterLinuxJdk9 https://ci.wildfly.org/viewType.html?buildTypeId=WildFlyCore_MasterLinuxJdk9jigsaw and related projects https://ci.wildfly.org/project.html?projectId=WildFlyProject&tab=projectOverview we also track known issues we found with WildFly at https://issues.jboss.org/browse/WFLY-3854 https://issues.jboss.org/browse/WFCORE-1374 BTW, what is the reason that jigsaw JDK builds are 5 times size of the non jigsaw builds? 685.27 MB vs 122.12 MB for 32bit linux jdk for example. -- tomaz On Sat, Mar 19, 2016 at 8:41 AM, Rory O'Donnell wrote: > > Hi Jason/Tomaz, > > Early Access b110 for JDK 9 is > available on java.net, summary of changes are listed here > . > Among other fixes , the following changes are also included from builds > 108 to 110 > > - removal of the OS X-specific com.apple.concurrent package > - update to the JAX-WS RI integration to latest version > (2.3.0-SNAPSHOT) > - disabling of Diffie-Hellman keys smaller than 1024 bits > > Early Access b110 (#4664) for JDK 9 with > Project Jigsaw is available on java.net. > We expect this will be the last EA build before we integrate into JDK 9. > This means that this > EA build is essentially what will be jdk-9+111 next week. > > As always, please help out by trying out existing code and libraries to > see what works and > doesn't work. We have a detailed list of compatibility issues listed in > JEP 261 [2]. > > Also feedback and questions from those that trying the EA build to > modularize existing > code would be appreciated. We also want to know what works and doesn't > work here [3] > > Rgds,Rory > > > [1] https://jdk9.java.net/jigsaw/ > [2] http://openjdk.java.net/jeps/261 > [3] http://mail.openjdk.java.net/pipermail/jigsaw-dev/ > > > -- > 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/20160321/57866874/attachment.html From mmusgrov at redhat.com Mon Mar 21 12:42:13 2016 From: mmusgrov at redhat.com (Michael Musgrove) Date: Mon, 21 Mar 2016 16:42:13 +0000 Subject: [wildfly-dev] What is the best practice for back porting subsystem model changes Message-ID: What is the recommended approach to back porting model changes. The context for the question is that we have added a bit of configuration to narayana and exposed it in the subsystem model as an attribute on an existing element. The latest subsystem version has more parser versions than the target version we need to back port to. Since we do not want to back port each intermediate parser, how do we get the new attribute into the earlier version? -- Michael Musgrove Transactions Team e: mmusgrov at redhat.com t: +44 191 243 0870 Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson (US), Charles Peters (US) Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160321/e795460f/attachment-0001.html From brian.stansberry at redhat.com Mon Mar 21 12:52:40 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 21 Mar 2016 11:52:40 -0500 Subject: [wildfly-dev] What is the best practice for back porting subsystem model changes In-Reply-To: References: Message-ID: <56F026D8.8010709@redhat.com> Did this bit of configuration exist in the previous xsd and the parser for that version was just wrong? If not, then you create a new xsd version and a parser for that and any intermediate parsers don't need to be updated. I'm not sure why backporting like this would need to happen though. I'll ping you offline for details. On 3/21/16 11:42 AM, Michael Musgrove wrote: > What is the recommended approach to back porting model changes. The > context for the question is that we have added a bit of configuration to > narayana and exposed it in the subsystem model as an attribute on an > existing element. The latest subsystem version has more parser versions > than the target version we need to back port to. Since we do not want to > back port each intermediate parser, how do we get the new attribute into > the earlier version? > > -- > Michael Musgrove > Transactions Team > e: mmusgrov at redhat.com > t: +44 191 243 0870 > > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson > (US), Charles Peters (US) > > Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael > O'Neill(Ireland) > > > _______________________________________________ > 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 rory.odonnell at oracle.com Tue Mar 22 03:40:22 2016 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Tue, 22 Mar 2016 13:10:22 +0530 Subject: [wildfly-dev] Early Access builds of JDK 9 b110 & JDK 9 with Project Jigsaw b110 (#4664) are available on java.net In-Reply-To: References: <56ED02BC.6030203@oracle.com> Message-ID: <56F0F6E6.1030606@oracle.com> On 21/03/2016 20:21, Toma? Cerar wrote: > Hi Rory, > > We already test WildFly and all "our" projects WildFly depends on, on > both JDK9 builds. > We did find handful of issues with Jigsaw builds which mostly relate > back to either issues in jigsaw itself > or problems in JDK itself once it runs on jigsaw. Which is the > biggest thing giving us problems at the moment. > see for details: > http://mail.openjdk.java.net/pipermail/jpms-spec-observers/2016-March/000305.html Cool! > > > you can track our progress at our CI at (currently tested from my > branches) > https://ci.wildfly.org/viewType.html?buildTypeId=WildFlyCore_MasterLinuxJdk9 > https://ci.wildfly.org/viewType.html?buildTypeId=WildFlyCore_MasterLinuxJdk9jigsaw > > and related projects > https://ci.wildfly.org/project.html?projectId=WildFlyProject&tab=projectOverview > Thanks for that . > we also track known issues we found with WildFly at > https://issues.jboss.org/browse/WFLY-3854 > https://issues.jboss.org/browse/WFCORE-1374 > > BTW, what is the reason that jigsaw JDK builds are 5 times size of the > non jigsaw builds? > 685.27 MB vs 122.12 MB for 32bit linux jdk for example. The additional size is expected during this testing/feedback period, builds include the JMOD files so that people can trying out the linker. They include the debug info files and finally bundles may not be compressed with the right options. Rgds, Rory > > -- > tomaz > > > > On Sat, Mar 19, 2016 at 8:41 AM, Rory O'Donnell > > wrote: > > > Hi Jason/Tomaz, > > Early Access b110 for JDK 9 is > available on java.net , summary of changes are > listed here > . > Among other fixes , the following changes are also included from > builds 108 to 110 > > o removal of the OS X-specific com.apple.concurrent package > o update to the JAX-WS RI integration to latest version > (2.3.0-SNAPSHOT) > o disabling of Diffie-Hellman keys smaller than 1024 bits > > Early Access b110 (#4664) for JDK > 9 with Project Jigsaw is available on java.net . > We expect this will be the last EA build before we integrate into > JDK 9. This means that this > EA build is essentially what will be jdk-9+111 next week. > > As always, please help out by trying out existing code and > libraries to see what works and > doesn't work. We have a detailed list of compatibility issues > listed in JEP 261 [2]. > > Also feedback and questions from those that trying the EA build to > modularize existing > code would be appreciated. We also want to know what works and > doesn't work here [3] > > Rgds,Rory > > > [1] https://jdk9.java.net/jigsaw/ > [2] http://openjdk.java.net/jeps/261 > [3] http://mail.openjdk.java.net/pipermail/jigsaw-dev/ > > -- > 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/20160322/60d48d2b/attachment.html From ingo at redhat.com Tue Mar 22 09:17:45 2016 From: ingo at redhat.com (Ingo Weiss) Date: Tue, 22 Mar 2016 13:17:45 +0000 Subject: [wildfly-dev] Injecting ManagedExecutorService results in NPE Message-ID: <56F145F9.4060804@redhat.com> Hi, I was testing injecting the default ManagedExecutorService on WF10 and it returns a NullPointerException if I don't do a lookup. These result in a NPE: @Resource private ManagedExecutorService executorService; @Resource(lookup = "java:jboss/ee/concurrency/executor/default") private ManagedExecutorService executorService; But this works: private ManagedExecutorService executorService = InitialContext.doLookup("java:jboss/ee/concurrency/executor/default"); I didn't change any configurations on WF so far. Ideas? Cheers -- Ingo Weiss -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160322/68c831e5/attachment.bin From stuart.w.douglas at gmail.com Tue Mar 22 09:28:01 2016 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Tue, 22 Mar 2016 13:28:01 +0000 Subject: [wildfly-dev] Injecting ManagedExecutorService results in NPE In-Reply-To: <56F145F9.4060804@redhat.com> References: <56F145F9.4060804@redhat.com> Message-ID: Where are you trying to use these? Stuart On Wed, 23 Mar 2016, 00:18 Ingo Weiss wrote: > Hi, > > I was testing injecting the default ManagedExecutorService on WF10 and > it returns a NullPointerException if I don't do a lookup. > > These result in a NPE: > > @Resource > private ManagedExecutorService executorService; > > @Resource(lookup = "java:jboss/ee/concurrency/executor/default") > private ManagedExecutorService executorService; > > But this works: > > private ManagedExecutorService executorService = > InitialContext.doLookup("java:jboss/ee/concurrency/executor/default"); > > I didn't change any configurations on WF so far. Ideas? > > Cheers > -- > Ingo Weiss > > _______________________________________________ > 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/20160322/ecb95690/attachment.html From ingo at redhat.com Tue Mar 22 09:57:53 2016 From: ingo at redhat.com (Ingo Weiss) Date: Tue, 22 Mar 2016 13:57:53 +0000 Subject: [wildfly-dev] Injecting ManagedExecutorService results in NPE In-Reply-To: References: <56F145F9.4060804@redhat.com> Message-ID: <56F14F61.5090001@redhat.com> On 22/03/2016 13:28, Stuart Douglas wrote: > Where are you trying to use these? > > Stuart > > On Wed, 23 Mar 2016, 00:18 Ingo Weiss > wrote: > > Hi, > > I was testing injecting the default ManagedExecutorService on WF10 and > it returns a NullPointerException if I don't do a lookup. > > These result in a NPE: > > @Resource > private ManagedExecutorService executorService; > > @Resource(lookup = "java:jboss/ee/concurrency/executor/default") > private ManagedExecutorService executorService; > > But this works: > > private ManagedExecutorService executorService = > InitialContext.doLookup("java:jboss/ee/concurrency/executor/default"); > > I didn't change any configurations on WF so far. Ideas? > > Cheers > -- > Ingo Weiss > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > Hi Stuart, On a simple JAX-RS class. Something along these lines: @Path("resource") public class Resource { @Resource private ManagedExecutorService executorService; ... blah blah... public String fetchMessage() { CompletableFuture.supplyAsync(this::message, executorService). thenApply(this::process). exceptionally(this::handle). thenAccept(this::consume); return "* fetchMessage() *"; } String message() { return "Super message @ " + System.currentTimeMillis(); } ... blah blah ... } -- Ingo Weiss -- Ingo Weiss -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160322/fc055078/attachment-0001.bin From ingo at redhat.com Wed Mar 23 03:24:32 2016 From: ingo at redhat.com (Ingo Weiss) Date: Wed, 23 Mar 2016 07:24:32 +0000 Subject: [wildfly-dev] Injecting ManagedExecutorService results in NPE In-Reply-To: References: <56F145F9.4060804@redhat.com> Message-ID: <56F244B0.9030305@redhat.com> On 22/03/2016 13:28, Stuart Douglas wrote: > Where are you trying to use these? > > Stuart > > On Wed, 23 Mar 2016, 00:18 Ingo Weiss > wrote: > > Hi, > > I was testing injecting the default ManagedExecutorService on WF10 and > it returns a NullPointerException if I don't do a lookup. > > These result in a NPE: > > @Resource > private ManagedExecutorService executorService; > > @Resource(lookup = "java:jboss/ee/concurrency/executor/default") > private ManagedExecutorService executorService; > > But this works: > > private ManagedExecutorService executorService = > InitialContext.doLookup("java:jboss/ee/concurrency/executor/default"); > > I didn't change any configurations on WF so far. Ideas? > > Cheers > -- > Ingo Weiss > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > Hi, Disregard this. The issue is that I forgot to add beans.xml to activate CDI. Cheers -- Ingo Weiss -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160323/aa1ac868/attachment.bin From eduardo.santanadasilva at gmail.com Wed Mar 23 07:52:12 2016 From: eduardo.santanadasilva at gmail.com (=?UTF-8?Q?Eduardo_Sant=C2=B4Ana_da_Silva?=) Date: Wed, 23 Mar 2016 08:52:12 -0300 Subject: [wildfly-dev] Injecting ManagedExecutorService results in NPE In-Reply-To: <56F244B0.9030305@redhat.com> References: <56F145F9.4060804@redhat.com> <56F244B0.9030305@redhat.com> Message-ID: Did you saw this message when deploying? :# Message: Deployment %s contains CDI annotations but no bean archive was not found. (No beans.xml nor class with bean defining annotations) 2016-03-23 4:24 GMT-03:00 Ingo Weiss : > On 22/03/2016 13:28, Stuart Douglas wrote: > > Where are you trying to use these? > > > > Stuart > > > > On Wed, 23 Mar 2016, 00:18 Ingo Weiss > > wrote: > > > > Hi, > > > > I was testing injecting the default ManagedExecutorService on WF10 > and > > it returns a NullPointerException if I don't do a lookup. > > > > These result in a NPE: > > > > @Resource > > private ManagedExecutorService executorService; > > > > @Resource(lookup = "java:jboss/ee/concurrency/executor/default") > > private ManagedExecutorService executorService; > > > > But this works: > > > > private ManagedExecutorService executorService = > > > InitialContext.doLookup("java:jboss/ee/concurrency/executor/default"); > > > > I didn't change any configurations on WF so far. Ideas? > > > > Cheers > > -- > > Ingo Weiss > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > Hi, > > Disregard this. The issue is that I forgot to add beans.xml to activate > CDI. > > Cheers > -- > Ingo Weiss > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- ___________________________ 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/20160323/86e5be4e/attachment.html From ingo at redhat.com Wed Mar 23 08:06:57 2016 From: ingo at redhat.com (Ingo Weiss) Date: Wed, 23 Mar 2016 12:06:57 +0000 Subject: [wildfly-dev] Injecting ManagedExecutorService results in NPE In-Reply-To: References: <56F145F9.4060804@redhat.com> <56F244B0.9030305@redhat.com> Message-ID: <56F286E1.6040105@redhat.com> On 23/03/2016 11:52, Eduardo Sant?Ana da Silva wrote: > Did you saw this message when deploying? > > :# Message: Deployment %s contains CDI annotations but no bean archive > was not found. (No beans.xml nor class with bean defining annotations) > > 2016-03-23 4:24 GMT-03:00 Ingo Weiss >: > > On 22/03/2016 13:28, Stuart Douglas wrote: > > Where are you trying to use these? > > > > Stuart > > > > On Wed, 23 Mar 2016, 00:18 Ingo Weiss > > >> wrote: > > > > Hi, > > > > I was testing injecting the default ManagedExecutorService on > WF10 and > > it returns a NullPointerException if I don't do a lookup. > > > > These result in a NPE: > > > > @Resource > > private ManagedExecutorService executorService; > > > > @Resource(lookup = "java:jboss/ee/concurrency/executor/default") > > private ManagedExecutorService executorService; > > > > But this works: > > > > private ManagedExecutorService executorService = > > > InitialContext.doLookup("java:jboss/ee/concurrency/executor/default"); > > > > I didn't change any configurations on WF so far. Ideas? > > > > Cheers > > -- > > Ingo Weiss > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > Hi, > > Disregard this. The issue is that I forgot to add beans.xml to > activate CDI. > > Cheers > -- > Ingo Weiss > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > -- > ___________________________ > Eduardo Sant'Ana da Silva - Ph.D. > Researcher / IT Consultant > Oi Eduardo, No. 12:05:51,405 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) WFLYSRV0027: Starting deployment of "async-jaxrs.war" (runtime-name: "async-jaxrs.war") 12:05:51,473 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 78) Initializing Mojarra 2.2.12-jbossorg-2 20150729-1131 for context '/async-jaxrs' 12:05:51,580 INFO [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService Thread Pool -- 78) RESTEASY002225: Deploying javax.ws.rs.core.Application: class cx.hoffmann.msa.async.JaxRSConfiguration 12:05:51,586 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 78) WFLYUT0021: Registered web context: /async-jaxrs 12:05:51,593 INFO [org.jboss.as.server] (management-handler-thread - 7) WFLYSRV0010: Deployed "async-jaxrs.war" (runtime-name : "async-jaxrs.war") That's probably why I was confused since I've seen the message you refer to on EAP 6. -- Ingo Weiss -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160323/729f2937/attachment.bin From eduardo.santanadasilva at gmail.com Wed Mar 23 08:15:46 2016 From: eduardo.santanadasilva at gmail.com (=?UTF-8?Q?Eduardo_Sant=C2=B4Ana_da_Silva?=) Date: Wed, 23 Mar 2016 09:15:46 -0300 Subject: [wildfly-dev] Injecting ManagedExecutorService results in NPE In-Reply-To: <56F286E1.6040105@redhat.com> References: <56F145F9.4060804@redhat.com> <56F244B0.9030305@redhat.com> <56F286E1.6040105@redhat.com> Message-ID: Weird, this was done on AS-2164 Warn if CDI annotations present but no beans.xml https://issues.jboss.org/browse/AS7-2164 2016-03-23 9:06 GMT-03:00 Ingo Weiss : > On 23/03/2016 11:52, Eduardo Sant?Ana da Silva wrote: > > Did you saw this message when deploying? > > > > :# Message: Deployment %s contains CDI annotations but no bean archive > > was not found. (No beans.xml nor class with bean defining annotations) > > > > 2016-03-23 4:24 GMT-03:00 Ingo Weiss > >: > > > > On 22/03/2016 13:28, Stuart Douglas wrote: > > > Where are you trying to use these? > > > > > > Stuart > > > > > > On Wed, 23 Mar 2016, 00:18 Ingo Weiss ingo at redhat.com> > > > >> wrote: > > > > > > Hi, > > > > > > I was testing injecting the default ManagedExecutorService on > > WF10 and > > > it returns a NullPointerException if I don't do a lookup. > > > > > > These result in a NPE: > > > > > > @Resource > > > private ManagedExecutorService executorService; > > > > > > @Resource(lookup = > "java:jboss/ee/concurrency/executor/default") > > > private ManagedExecutorService executorService; > > > > > > But this works: > > > > > > private ManagedExecutorService executorService = > > > > > > InitialContext.doLookup("java:jboss/ee/concurrency/executor/default"); > > > > > > I didn't change any configurations on WF so far. Ideas? > > > > > > Cheers > > > -- > > > Ingo Weiss > > > > > > _______________________________________________ > > > wildfly-dev mailing list > > > wildfly-dev at lists.jboss.org wildfly-dev at lists.jboss.org> > > > > > > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > > > Hi, > > > > Disregard this. The issue is that I forgot to add beans.xml to > > activate CDI. > > > > Cheers > > -- > > Ingo Weiss > > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > > > > > > -- > > ___________________________ > > Eduardo Sant'Ana da Silva - Ph.D. > > Researcher / IT Consultant > > > > Oi Eduardo, > > No. > > 12:05:51,405 INFO [org.jboss.as.server.deployment] (MSC service thread > 1-4) WFLYSRV0027: Starting deployment of "async-jaxrs.war" > (runtime-name: "async-jaxrs.war") > > 12:05:51,473 INFO [javax.enterprise.resource.webcontainer.jsf.config] > (ServerService Thread Pool -- 78) Initializing Mojarra 2.2.12-jbossorg-2 > 20150729-1131 for context '/async-jaxrs' > > 12:05:51,580 INFO [org.jboss.resteasy.resteasy_jaxrs.i18n] > (ServerService Thread Pool -- 78) RESTEASY002225: Deploying > javax.ws.rs.core.Application: class > cx.hoffmann.msa.async.JaxRSConfiguration > > 12:05:51,586 INFO [org.wildfly.extension.undertow] (ServerService > Thread Pool -- 78) WFLYUT0021: Registered web context: /async-jaxrs > > 12:05:51,593 INFO [org.jboss.as.server] (management-handler-thread - 7) > WFLYSRV0010: Deployed "async-jaxrs.war" (runtime-name : "async-jaxrs.war") > > That's probably why I was confused since I've seen the message you refer > to on EAP 6. > -- > Ingo Weiss > > -- ___________________________ 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/20160323/1a5ecde4/attachment-0001.html From stuart.w.douglas at gmail.com Wed Mar 23 08:36:59 2016 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Wed, 23 Mar 2016 12:36:59 +0000 Subject: [wildfly-dev] Injecting ManagedExecutorService results in NPE In-Reply-To: References: <56F145F9.4060804@redhat.com> <56F244B0.9030305@redhat.com> <56F286E1.6040105@redhat.com> Message-ID: @Resource is not a CDI annotation, but it does take effect on CDI beans. Stuart On Wed, 23 Mar 2016 at 23:15 Eduardo Sant?Ana da Silva < eduardo.santanadasilva at gmail.com> wrote: > Weird, this was done on AS-2164 > > Warn if CDI annotations present but no beans.xml > https://issues.jboss.org/browse/AS7-2164 > > > 2016-03-23 9:06 GMT-03:00 Ingo Weiss : > >> On 23/03/2016 11:52, Eduardo Sant?Ana da Silva wrote: >> > Did you saw this message when deploying? >> > >> > :# Message: Deployment %s contains CDI annotations but no bean archive >> > was not found. (No beans.xml nor class with bean defining annotations) >> > >> > 2016-03-23 4:24 GMT-03:00 Ingo Weiss > > >: >> > >> > On 22/03/2016 13:28, Stuart Douglas wrote: >> > > Where are you trying to use these? >> > > >> > > Stuart >> > > >> > > On Wed, 23 Mar 2016, 00:18 Ingo Weiss > ingo at redhat.com> >> > > >> wrote: >> > > >> > > Hi, >> > > >> > > I was testing injecting the default ManagedExecutorService on >> > WF10 and >> > > it returns a NullPointerException if I don't do a lookup. >> > > >> > > These result in a NPE: >> > > >> > > @Resource >> > > private ManagedExecutorService executorService; >> > > >> > > @Resource(lookup = >> "java:jboss/ee/concurrency/executor/default") >> > > private ManagedExecutorService executorService; >> > > >> > > But this works: >> > > >> > > private ManagedExecutorService executorService = >> > > >> > >> InitialContext.doLookup("java:jboss/ee/concurrency/executor/default"); >> > > >> > > I didn't change any configurations on WF so far. Ideas? >> > > >> > > Cheers >> > > -- >> > > Ingo Weiss >> > > >> > > _______________________________________________ >> > > wildfly-dev mailing list >> > > wildfly-dev at lists.jboss.org > wildfly-dev at lists.jboss.org> >> > > > > >> > > https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > >> > >> > Hi, >> > >> > Disregard this. The issue is that I forgot to add beans.xml to >> > activate CDI. >> > >> > Cheers >> > -- >> > Ingo Weiss >> > >> > >> > _______________________________________________ >> > wildfly-dev mailing list >> > wildfly-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > >> > >> > >> > >> > -- >> > ___________________________ >> > Eduardo Sant'Ana da Silva - Ph.D. >> > Researcher / IT Consultant >> > >> >> Oi Eduardo, >> >> No. >> >> 12:05:51,405 INFO [org.jboss.as.server.deployment] (MSC service thread >> 1-4) WFLYSRV0027: Starting deployment of "async-jaxrs.war" >> (runtime-name: "async-jaxrs.war") >> >> 12:05:51,473 INFO [javax.enterprise.resource.webcontainer.jsf.config] >> (ServerService Thread Pool -- 78) Initializing Mojarra 2.2.12-jbossorg-2 >> 20150729-1131 for context '/async-jaxrs' >> >> 12:05:51,580 INFO [org.jboss.resteasy.resteasy_jaxrs.i18n] >> (ServerService Thread Pool -- 78) RESTEASY002225: Deploying >> javax.ws.rs.core.Application: class >> cx.hoffmann.msa.async.JaxRSConfiguration >> >> 12:05:51,586 INFO [org.wildfly.extension.undertow] (ServerService >> Thread Pool -- 78) WFLYUT0021: Registered web context: /async-jaxrs >> >> 12:05:51,593 INFO [org.jboss.as.server] (management-handler-thread - 7) >> WFLYSRV0010: Deployed "async-jaxrs.war" (runtime-name : "async-jaxrs.war") >> >> That's probably why I was confused since I've seen the message you refer >> to on EAP 6. >> -- >> Ingo Weiss >> >> > > > -- > ___________________________ > 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/20160323/c7b45329/attachment.html From ingo at redhat.com Wed Mar 23 11:48:33 2016 From: ingo at redhat.com (Ingo Weiss) Date: Wed, 23 Mar 2016 15:48:33 +0000 Subject: [wildfly-dev] Injecting ManagedExecutorService results in NPE In-Reply-To: References: <56F145F9.4060804@redhat.com> <56F244B0.9030305@redhat.com> <56F286E1.6040105@redhat.com> Message-ID: <56F2BAD1.3020406@redhat.com> On 23/03/2016 12:36, Stuart Douglas wrote: > @Resource is not a CDI annotation, but it does take effect on CDI beans. > > Stuart > > On Wed, 23 Mar 2016 at 23:15 Eduardo Sant?Ana da Silva > > wrote: > > Weird, this was done on AS-2164 > > Warn if CDI annotations present but no beans.xml > https://issues.jboss.org/browse/AS7-2164 > > > > 2016-03-23 9:06 GMT-03:00 Ingo Weiss >: > > On 23/03/2016 11:52, Eduardo Sant?Ana da Silva wrote: > > Did you saw this message when deploying? > > > > :# Message: Deployment %s contains CDI annotations but no bean archive > > was not found. (No beans.xml nor class with bean defining annotations) > > > > 2016-03-23 4:24 GMT-03:00 Ingo Weiss > > >>: > > > > On 22/03/2016 13:28, Stuart Douglas wrote: > > > Where are you trying to use these? > > > > > > Stuart > > > > > > On Wed, 23 Mar 2016, 00:18 Ingo Weiss > > > > >>> wrote: > > > > > > Hi, > > > > > > I was testing injecting the default ManagedExecutorService on > > WF10 and > > > it returns a NullPointerException if I don't do a lookup. > > > > > > These result in a NPE: > > > > > > @Resource > > > private ManagedExecutorService executorService; > > > > > > @Resource(lookup = "java:jboss/ee/concurrency/executor/default") > > > private ManagedExecutorService executorService; > > > > > > But this works: > > > > > > private ManagedExecutorService executorService = > > > > > InitialContext.doLookup("java:jboss/ee/concurrency/executor/default"); > > > > > > I didn't change any configurations on WF so far. Ideas? > > > > > > Cheers > > > -- > > > Ingo Weiss > > > > > > _______________________________________________ > > > wildfly-dev mailing list > > > wildfly-dev at lists.jboss.org > > > > > > >> > > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > > > Hi, > > > > Disregard this. The issue is that I forgot to add beans.xml to > > activate CDI. > > > > Cheers > > -- > > Ingo Weiss > > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > > > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > > > > > > -- > > ___________________________ > > Eduardo Sant'Ana da Silva - Ph.D. > > Researcher / IT Consultant > > > > Oi Eduardo, > > No. > > 12:05:51,405 INFO [org.jboss.as.server.deployment] (MSC service > thread > 1-4) WFLYSRV0027: Starting deployment of "async-jaxrs.war" > (runtime-name: "async-jaxrs.war") > > 12:05:51,473 INFO > [javax.enterprise.resource.webcontainer.jsf.config] > (ServerService Thread Pool -- 78) Initializing Mojarra > 2.2.12-jbossorg-2 > 20150729-1131 for context '/async-jaxrs' > > 12:05:51,580 INFO [org.jboss.resteasy.resteasy_jaxrs.i18n] > (ServerService Thread Pool -- 78) RESTEASY002225: Deploying > javax.ws.rs.core.Application: class > cx.hoffmann.msa.async.JaxRSConfiguration > > 12:05:51,586 INFO [org.wildfly.extension.undertow] (ServerService > Thread Pool -- 78) WFLYUT0021: Registered web context: /async-jaxrs > > 12:05:51,593 INFO [org.jboss.as.server] > (management-handler-thread - 7) > WFLYSRV0010: Deployed "async-jaxrs.war" (runtime-name : > "async-jaxrs.war") > > That's probably why I was confused since I've seen the message > you refer > to on EAP 6. > -- > Ingo Weiss > > > > > -- > ___________________________ > Eduardo Sant'Ana da Silva - Ph.D. > Researcher / IT Consultant > Ah, interesting. Should I file a bug report on that? -- Ingo Weiss -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160323/6fc92444/attachment.bin From ken at zaptillion.net Mon Mar 28 15:06:39 2016 From: ken at zaptillion.net (Ken Wills) Date: Mon, 28 Mar 2016 14:06:39 -0500 Subject: [wildfly-dev] server-state / host-state attributes Message-ID: This is an older issue that I looked at last week. The fix is mostly trivial, but the associated naming wasn't obvious. https://issues.jboss.org/browse/WFCORE-43 As a result of the discussion, we're leaning towards: runtime-configuration-state: {STARTING, OK, STOPPING, RELOAD_REQUIRED, RESTART_REQUIRED} host-state and server-state will be preserved for compatability, with the new OK state mapped back to RUNNING. Thoughts / comments? Ken -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160328/5164b3ed/attachment.html From jperkins at redhat.com Mon Mar 28 17:49:10 2016 From: jperkins at redhat.com (James Perkins) Date: Mon, 28 Mar 2016 14:49:10 -0700 Subject: [wildfly-dev] server-state / host-state attributes In-Reply-To: References: Message-ID: Shouldn't there be a STOPPED state too for domain servers? Also should it include SUSPENDING, SUSPENDED and RESUMING as well? On Mon, Mar 28, 2016 at 12:06 PM, Ken Wills wrote: > This is an older issue that I looked at last week. The fix is mostly > trivial, but the associated naming wasn't obvious. > > https://issues.jboss.org/browse/WFCORE-43 > > As a result of the discussion, we're leaning towards: > > runtime-configuration-state: {STARTING, OK, STOPPING, RELOAD_REQUIRED, > RESTART_REQUIRED} > > host-state and server-state will be preserved for compatability, with the > new OK state mapped back to RUNNING. > > Thoughts / comments? > > Ken > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- James R. Perkins JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160328/8b4c7e3a/attachment-0001.html From brian.stansberry at redhat.com Mon Mar 28 21:39:47 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 28 Mar 2016 20:39:47 -0500 Subject: [wildfly-dev] server-state / host-state attributes In-Reply-To: References: Message-ID: <56F9DCE3.7050802@redhat.com> On 3/28/16 4:49 PM, James Perkins wrote: > Shouldn't there be a STOPPED state too for domain servers? Yes, good point. The org.jboss.as.host.controller.resources.StoppedServerResource will need to handle this runtime-configuration-state attribute the same way it handles server-state. Also should > it include SUSPENDING, SUSPENDED and RESUMING as well? No, that's a separate attribute because it's reporting on a different thing. See discussion leading up to http://lists.jboss.org/pipermail/wildfly-dev/2014-June/002360.html > > On Mon, Mar 28, 2016 at 12:06 PM, Ken Wills > wrote: > > This is an older issue that I looked at last week. The fix is mostly > trivial, but the associated naming wasn't obvious. > > https://issues.jboss.org/browse/WFCORE-43 > > As a result of the discussion, we're leaning towards: > > runtime-configuration-state: {STARTING, OK, STOPPING, > RELOAD_REQUIRED, RESTART_REQUIRED} > > host-state and server-state will be preserved for compatability, > with the new OK state mapped back to RUNNING. > > Thoughts / comments? > > Ken > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > -- > James R. Perkins > JBoss by Red Hat > > > _______________________________________________ > 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 hbraun at redhat.com Tue Mar 29 03:14:42 2016 From: hbraun at redhat.com (Heiko Braun) Date: Tue, 29 Mar 2016 09:14:42 +0200 Subject: [wildfly-dev] server-state / host-state attributes In-Reply-To: References: Message-ID: <11DC2178-96A1-4015-B2F6-10761478C0E3@redhat.com> Looks good. > On 28 Mar 2016, at 21:06, Ken Wills wrote: > > This is an older issue that I looked at last week. The fix is mostly trivial, but the associated naming wasn't obvious. > > https://issues.jboss.org/browse/WFCORE-43 > > As a result of the discussion, we're leaning towards: > > runtime-configuration-state: {STARTING, OK, STOPPING, RELOAD_REQUIRED, RESTART_REQUIRED} > > host-state and server-state will be preserved for compatability, with the new OK state mapped back to RUNNING. > > Thoughts / comments? > > Ken > _______________________________________________ > 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/20160329/2aa97492/attachment.html From spica.gao at morpho.com Tue Mar 29 15:26:05 2016 From: spica.gao at morpho.com (sgao) Date: Tue, 29 Mar 2016 12:26:05 -0700 (MST) Subject: [wildfly-dev] How to do remote SLSB via http:remoting through mod_cluster? Message-ID: <1459279565289-5716788.post@n5.nabble.com> We have multiple wildfly 10 instances running SLSB and web application. We put a mod_cluster httpd (1.3.1) as a front end load balancer. We use http protocol instead of AJP. Web load balancing works well and we can use env.put(Context.PROVIDER_URL, "http-remoting://node1:8080,http-remoting://node2:8080,http-remoting://node3:8080") for SLSB remote access. However, we want to expose only one http port (mod_cluster port) externally which mean both web access and EJB remote access have to go through the httpd port. I want to know is it possible to do EJB remote access through mod_cluster? If yes, how to configure mod_cluster to map http-remoting request to wildfly? Or mod_cluster only allows web access and we have to use env.put(Context.PROVIDER_URL, "http-remoting://node1:8080,http-remoting://node2:8080,http-remoting://node3:8080") for SLSB remote access? thanks -- View this message in context: http://wildfly-development.1055759.n5.nabble.com/How-to-do-remote-SLSB-via-http-remoting-through-mod-cluster-tp5716788.html Sent from the WildFly Development mailing list archive at Nabble.com. From eduardo.santanadasilva at gmail.com Tue Mar 29 16:50:40 2016 From: eduardo.santanadasilva at gmail.com (=?UTF-8?Q?Eduardo_Sant=C2=B4Ana_da_Silva?=) Date: Tue, 29 Mar 2016 17:50:40 -0300 Subject: [wildfly-dev] How to do remote SLSB via http:remoting through mod_cluster? In-Reply-To: <1459279565289-5716788.post@n5.nabble.com> References: <1459279565289-5716788.post@n5.nabble.com> Message-ID: Maybe this can help: https://docs.jboss.org/author/display/WFLY10/High+Availability+Guide#HighAvailabilityGuide-MarkinganEJBasclustered Did you try to mark your ejb as @Clustered? 2016-03-29 16:26 GMT-03:00 sgao : > We have multiple wildfly 10 instances running SLSB and web application. > We > put a mod_cluster httpd (1.3.1) as a front end load balancer. We use http > protocol instead of AJP. > Web load balancing works well and we can use env.put(Context.PROVIDER_URL, > > "http-remoting://node1:8080,http-remoting://node2:8080,http-remoting://node3:8080") > for SLSB remote access. > > However, we want to expose only one http port (mod_cluster port) externally > which mean both web access and EJB remote access have to go through the > httpd port. I want to know is it possible to do EJB remote access through > mod_cluster? If yes, how to configure mod_cluster to map http-remoting > request to wildfly? Or mod_cluster only allows web access and we have to > use env.put(Context.PROVIDER_URL, > > "http-remoting://node1:8080,http-remoting://node2:8080,http-remoting://node3:8080") > for SLSB remote access? > > thanks > > > > > -- > View this message in context: > http://wildfly-development.1055759.n5.nabble.com/How-to-do-remote-SLSB-via-http-remoting-through-mod-cluster-tp5716788.html > Sent from the WildFly Development mailing list archive at Nabble.com. > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- ___________________________ 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/20160329/87f23462/attachment.html From spica.gao at morpho.com Wed Mar 30 08:15:55 2016 From: spica.gao at morpho.com (sgao) Date: Wed, 30 Mar 2016 05:15:55 -0700 (MST) Subject: [wildfly-dev] How to do remote SLSB via http:remoting through mod_cluster? In-Reply-To: References: <1459279565289-5716788.post@n5.nabble.com> Message-ID: <1459340155524-5716790.post@n5.nabble.com> Yes, I do put @Clustered. However, i vaguely remembered @Clustered is not required in wildfly 10 anymore. Anyway, cluster works to me. My question is how to use http-remoting:// through mod_cluster/httpd/any sort of loadbalancer? I saw a feature request for modcluster (https://issues.jboss.org/browse/MODCLUSTER-438) regarding to adding websocket support. I will then assume* mod_cluster doesn't support http:remoting* yet? Can anyone confirm that *mod_cluster doesn't support http:remoting yet*. Thanks -- View this message in context: http://wildfly-development.1055759.n5.nabble.com/How-to-do-remote-SLSB-via-http-remoting-through-mod-cluster-tp5716788p5716790.html Sent from the WildFly Development mailing list archive at Nabble.com. From rory.odonnell at oracle.com Thu Mar 31 12:14:28 2016 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Thu, 31 Mar 2016 17:14:28 +0100 Subject: [wildfly-dev] Project Jigsaw: The module system was integrated into JDK 9 and is now available for testing in early-access, build 111. Message-ID: <56FD4CE4.8000009@oracle.com> Hi Jason/Tomaz, Project Jigsaw is an enormous effort, encompassing six JEPs implemented by dozens of engineers over many years. So far we?ve defined a modular structure for the JDK (JEP 200 ), reorganized the source code according to that structure (JEP 201 ), and restructured the JDK and JRE run-time images to support modules (JEP 220 ). The last major component, the module system itself (JSR 376 and JEP 261 ), was integrated into JDK 9 earlier this week and is now available for testing in early-access build 111 - here. More information on Mark Reinhold's blog [1] Rgds, Rory Project Jigsaw is an enormous effort, encompassing six JEPs implemented by dozens of engineers over many years. So far we?ve defined a modular structure for the JDK (JEP 200 ), reorganized the source code according to that structure (JEP 201 ), and restructured the JDK and JRE run-time images to support modules (JEP 220 ). The last major component, the module system itself (JSR 376 and JEP 261 ), was integrated into JDK 9 earlier this week and is now available for testing in early-access build 111 . [1] http://mreinhold.org/blog/jigsaw-module-system Project Jigsaw is an enormous effort, encompassing six JEPs implemented by dozens of engineers over many years. So far we?ve defined a modular structure for the JDK (JEP 200 ), reorganized the source code according to that structure (JEP 201 ), and restructured the JDK and JRE run-time images to support modules (JEP 220 ). The last major component, the module system itself (JSR 376 and JEP 261 ), was integrated into JDK 9 earlier this week and is now available for testing in early-access build 111 . Project Jigsaw is an enormous effort, encompassing six JEPs implemented by dozens of engineers over many years. So far we?ve defined a modular structure for the JDK (JEP 200 ), reorganized the source code according to that structure (JEP 201 ), and restructured the JDK and JRE run-time images to support modules (JEP 220 ). The last major component, the module system itself (JSR 376 and JEP 261 ), was integrated into JDK 9 earlier this week and is now available for testing in early-access build 111 . -- 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/20160331/a4548a14/attachment-0001.html