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