September 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-2092) MERGE3: merge never happens

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2092?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-2092. ---------------------------- Resolution: Done Also backported to 3.6 branch > MERGE3: merge never happens > --------------------------- > > Key: JGRP-2092 > URL: https://issues.jboss.org/browse/JGRP-2092 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.11, 4.0 > > Attachments: jgroups.txt > > > (Reported by Neal Dillman) > In the case below, a merge doesn't seem to happen. Write a unit test to reprodue this. > {noformat} > Host A view: B, X, Y, Z, A (where B should be coordinator) > Host B view: C, Q, R, S, B (where C should be coordinator) > Host C view: A, M, N, O, C (where A should be coordinator) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1289) Incremental compilation doesn't take count of added/removed packages in KieBaseModel

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-1289: ----------------------------------- Summary: Incremental compilation doesn't take count of added/removed packages in KieBaseModel Key: DROOLS-1289 URL: https://issues.jboss.org/browse/DROOLS-1289 Project: Drools Issue Type: Bug Components: core engine Reporter: Mario Fusco Assignee: Mario Fusco Fix For: 6.5.0.Final, 7.0.0.Beta2 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7103) In elytron security domain add operation the realms attribute is not marked as required even though it is not nillable and has no default value with no default value

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7103?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-7103: ---------------------------------------- If you could please also check the other list types within the subsystem, I don't think any should be accepting 'null' in the middle of a list. > In elytron security domain add operation the realms attribute is not marked as required even though it is not nillable and has no default value with no default value > --------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7103 > URL: https://issues.jboss.org/browse/WFLY-7103 > Project: WildFly > Issue Type: Bug > Components: Domain Management, Security > Reporter: Radim Hatlapatka > Assignee: Jan Kalina > > When reading description of the {{add}} operation for elytron security domain => {{/subsystem=elytron/security-domain=test-domain:read-operation-description(name=add)}}, the realms attribute has set required to false. Still it needs to be defined as part of {{add}} operation as it is not nillable. > If it is really mandatory, it should be marked as required. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1268) When using the RuleServicesClient for a remote rest interface, get the following error java.io.EOFException: No content to map to Object due to end of input

by Nicolas Heron (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1268?page=com.atlassian.jira.plugi... ] Nicolas Heron updated DROOLS-1268: ---------------------------------- Labels: OnBoarding (was: ) > When using the RuleServicesClient for a remote rest interface, get the following error java.io.EOFException: No content to map to Object due to end of input > ------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-1268 > URL: https://issues.jboss.org/browse/DROOLS-1268 > Project: Drools > Issue Type: Bug > Components: kie server > Affects Versions: 6.4.0.Final > Reporter: Nicolas Heron > Assignee: Maciej Swiderski > Labels: OnBoarding > Attachments: logerror.txt, picture1.png > > > here is the JSON http://pastebin.com/t1CdHg9F > The logs are in the file attached logerror.txt > Going further > the error comes from class org.kie.remote.common.rest.KieRemoteHttpRequest line 1329 > and the error behind is "not enough data" > I put in attachement and it seems true -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7103) In elytron security domain add operation the realms attribute is not marked as required even though it is not nillable and has no default value with no default value

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7103?page=com.atlassian.jira.plugin.... ] Jan Kalina commented on WFLY-7103: ---------------------------------- Note: To set REALMS as required, REALM (!) has to be set to not allow null. (list checks nullability of the type inside of the list) > In elytron security domain add operation the realms attribute is not marked as required even though it is not nillable and has no default value with no default value > --------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7103 > URL: https://issues.jboss.org/browse/WFLY-7103 > Project: WildFly > Issue Type: Bug > Components: Domain Management, Security > Reporter: Radim Hatlapatka > Assignee: Jan Kalina > > When reading description of the {{add}} operation for elytron security domain => {{/subsystem=elytron/security-domain=test-domain:read-operation-description(name=add)}}, the realms attribute has set required to false. Still it needs to be defined as part of {{add}} operation as it is not nillable. > If it is really mandatory, it should be marked as required. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-629) Release WildFly Elytron 1.1.0.Beta9

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-629: ------------------------------------ Summary: Release WildFly Elytron 1.1.0.Beta9 Key: ELY-629 URL: https://issues.jboss.org/browse/ELY-629 Project: WildFly Elytron Issue Type: Release Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Beta9 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2092) MERGE3: merge never happens

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2092?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2092: -------------------------------- OK, the issue has been resolved. The main changes are: * MERGE3 now has all members (not just the coords) check for view inconsistencies if {{only_coords_run_consistency_checker}} is false (default) ** (This is done every {{check_interval}} ms) * To determine a merge leader, all actual coordiantors are used. If this returns null (because there are no coords), _all_ members will be used * Participants (not just coordinators) are now also allowed to handle merges and install merge views > MERGE3: merge never happens > --------------------------- > > Key: JGRP-2092 > URL: https://issues.jboss.org/browse/JGRP-2092 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.11, 4.0 > > Attachments: jgroups.txt > > > (Reported by Neal Dillman) > In the case below, a merge doesn't seem to happen. Write a unit test to reprodue this. > {noformat} > Host A view: B, X, Y, Z, A (where B should be coordinator) > Host B view: C, Q, R, S, B (where C should be coordinator) > Host C view: A, M, N, O, C (where A should be coordinator) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2953) Add support to specify security provider for key and trust stores used by HornetQ

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-2953?page=com.atlassian.jira.plugin.... ] Darran Lofthouse resolved WFLY-2953. ------------------------------------ Resolution: Out of Date Migration to Elytron will mean using SSLContext instances that have already been configured with custom security providers. > Add support to specify security provider for key and trust stores used by HornetQ > --------------------------------------------------------------------------------- > > Key: WFLY-2953 > URL: https://issues.jboss.org/browse/WFLY-2953 > Project: WildFly > Issue Type: Sub-task > Components: JMS > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 11.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1797) LaunchType.SELF_CONTAINED doesn't cleanup the temporary "wildfly-self-contained" directory

by Heiko Braun (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1797?page=com.atlassian.jira.plugi... ] Heiko Braun reassigned WFCORE-1797: ----------------------------------- Assignee: Heiko Braun (was: Jason Greene) > LaunchType.SELF_CONTAINED doesn't cleanup the temporary "wildfly-self-contained" directory > ------------------------------------------------------------------------------------------ > > Key: WFCORE-1797 > URL: https://issues.jboss.org/browse/WFCORE-1797 > Project: WildFly Core > Issue Type: Bug > Components: Server > Reporter: Heiko Braun > Assignee: Heiko Braun > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-811) Add module for org.wildfly.security.elytron-web:undertow-server

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-811?page=com.atlassian.jira.plugin... ] Darran Lofthouse resolved WFCORE-811. ------------------------------------- Fix Version/s: 3.0.0.Alpha7 (was: 3.0.0.Alpha8) Resolution: Done > Add module for org.wildfly.security.elytron-web:undertow-server > --------------------------------------------------------------- > > Key: WFCORE-811 > URL: https://issues.jboss.org/browse/WFCORE-811 > Project: WildFly Core > Issue Type: Sub-task > Components: Modules > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha7 > > > This is the module that provides the integration between Elytron and Undertow without each needing to be aware of the other. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1288) KieModuleMetaData: Enhance to return a collection of "function" definitons

by Michael Anstis (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1288?page=com.atlassian.jira.plugi... ] Michael Anstis updated DROOLS-1288: ----------------------------------- Summary: KieModuleMetaData: Enhance to return a collection of "function" definitons (was: KieModuleMetaData: Enhance to return a collection of "functions" definitons) > KieModuleMetaData: Enhance to return a collection of "function" definitons > -------------------------------------------------------------------------- > > Key: DROOLS-1288 > URL: https://issues.jboss.org/browse/DROOLS-1288 > Project: Drools > Issue Type: Feature Request > Affects Versions: 7.0.0.Beta1 > Reporter: Michael Anstis > Assignee: Edson Tirelli > Priority: Minor > > Functions used in DRL need to be in the same file as the DRL using them; otherwise they need to be imported. Guvnor 5.x built a single {{String}} containing the definition of *all* assets in a project to {{PackageBuilder}} (IIRC) so all functions were always in the same file as any consuming DRL. > In 6.x we add individual files to {{KieBuilder}} and hence functions are (more than likely) in different files to the DRL using them. Classes used by a specific file need to be imported (if they are not in the same package). Functions will now also need to be imported. > This request is to enhance {{KieModuleMetaData}} to return a collection of functions so that we can populate these in the {{DataModelOracle}} passed to the client and used to drive the "Import Data Object" screen on editors. We'd need to enhance the DMO and related "import" screens to handle functions. [~nheron] is to raise a GUVNOR JIRA for such enhancement. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1288) KieModuleMetaData: Enhance to return a collection of "functions" definitons

by Michael Anstis (JIRA)

Michael Anstis created DROOLS-1288: -------------------------------------- Summary: KieModuleMetaData: Enhance to return a collection of "functions" definitons Key: DROOLS-1288 URL: https://issues.jboss.org/browse/DROOLS-1288 Project: Drools Issue Type: Feature Request Affects Versions: 7.0.0.Beta1 Reporter: Michael Anstis Assignee: Edson Tirelli Priority: Minor Functions used in DRL need to be in the same file as the DRL using them; otherwise they need to be imported. Guvnor 5.x built a single {{String}} containing the definition of *all* assets in a project to {{PackageBuilder}} (IIRC) so all functions were always in the same file as any consuming DRL. In 6.x we add individual files to {{KieBuilder}} and hence functions are (more than likely) in different files to the DRL using them. Classes used by a specific file need to be imported (if they are not in the same package). Functions will now also need to be imported. This request is to enhance {{KieModuleMetaData}} to return a collection of functions so that we can populate these in the {{DataModelOracle}} passed to the client and used to drive the "Import Data Object" screen on editors. We'd need to enhance the DMO and related "import" screens to handle functions. [~nheron] is to raise a GUVNOR JIRA for such enhancement. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1797) LaunchType.SELF_CONTAINED doesn't cleanup the temporary "wildfly-self-contained" directory

by Heiko Braun (JIRA)

Heiko Braun created WFCORE-1797: ----------------------------------- Summary: LaunchType.SELF_CONTAINED doesn't cleanup the temporary "wildfly-self-contained" directory Key: WFCORE-1797 URL: https://issues.jboss.org/browse/WFCORE-1797 Project: WildFly Core Issue Type: Bug Components: Server Reporter: Heiko Braun Assignee: Jason Greene -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7112) Allow optional tag virtual-host (and others) inside jboss-app.xml

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-7112?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-7112: ------------------------------ Component/s: EE > Allow optional tag virtual-host (and others) inside jboss-app.xml > ----------------------------------------------------------------- > > Key: WFLY-7112 > URL: https://issues.jboss.org/browse/WFLY-7112 > Project: WildFly > Issue Type: Feature Request > Components: EE > Affects Versions: 10.1.0.Final > Reporter: Guido Jäkel > Assignee: Jason Greene > > With undertow, the assignment of a web-application to a virtual host must be set in {{$WAR/META-INF/jboss-web.xml}}. A very adjacent parameter, the context-root, might be defined or overridden here, too. > In practice, for a concrete deployment generally one have to adapt both parts of the URL, the (virtual) host and the context-root part and may use this file and e.g. apply it with the overlay feature. > In case of an EAR, its components are declared inside {{$EAR/META-INF/application.xml}}. For an web application, the {{context-root}} is defined here. I found, that this have precedence to a {{$WAR/WEB-INF/jboss-web.xml}}. I don't expect this, but it might be defined by JEE specifications in that way. If not, this feature request should be converted to a bug report concerning a wrong preference order. > To my knowledge, at the moment this file seems the only way to set the {{virtual-host}} to use. And this looks very inconsistent to me, because you have to use two different "far-out" files to controll this very associated informations. > The informations in application.xml may be overridden and enriched by {{jboss-appl.xml}} in a similar manner as with {{web.xml}} and {{jboss-web.xml}}. I would expect (and suggest it as a feature) to define the virtual host here in an analogous way as the context root in {{application.xml}} may be overriden here. > {code} > <module> > <web> > <web-uri>a.war</web-uri> > <context-root>/foo</context-root> > <virtual-host>a.domain.tld</virtual-host> > ... > </web> > </module> > {code} > This concept should be probably expanded to the complete feature set controlled by the {{jboss-web.xml}}, like undertow-related like {{server-instance}} or others like {{security-domain}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7112) Allow optional tag virtual-host (and others) inside jboss-app.xml

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-7112?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-7112: ------------------------------ Affects Version/s: 10.1.0.Final > Allow optional tag virtual-host (and others) inside jboss-app.xml > ----------------------------------------------------------------- > > Key: WFLY-7112 > URL: https://issues.jboss.org/browse/WFLY-7112 > Project: WildFly > Issue Type: Feature Request > Affects Versions: 10.1.0.Final > Reporter: Guido Jäkel > Assignee: Jason Greene > > With undertow, the assignment of a web-application to a virtual host must be set in {{$WAR/META-INF/jboss-web.xml}}. A very adjacent parameter, the context-root, might be defined or overridden here, too. > In practice, for a concrete deployment generally one have to adapt both parts of the URL, the (virtual) host and the context-root part and may use this file and e.g. apply it with the overlay feature. > In case of an EAR, its components are declared inside {{$EAR/META-INF/application.xml}}. For an web application, the {{context-root}} is defined here. I found, that this have precedence to a {{$WAR/WEB-INF/jboss-web.xml}}. I don't expect this, but it might be defined by JEE specifications in that way. If not, this feature request should be converted to a bug report concerning a wrong preference order. > To my knowledge, at the moment this file seems the only way to set the {{virtual-host}} to use. And this looks very inconsistent to me, because you have to use two different "far-out" files to controll this very associated informations. > The informations in application.xml may be overridden and enriched by {{jboss-appl.xml}} in a similar manner as with {{web.xml}} and {{jboss-web.xml}}. I would expect (and suggest it as a feature) to define the virtual host here in an analogous way as the context root in {{application.xml}} may be overriden here. > {code} > <module> > <web> > <web-uri>a.war</web-uri> > <context-root>/foo</context-root> > <virtual-host>a.domain.tld</virtual-host> > ... > </web> > </module> > {code} > This concept should be probably expanded to the complete feature set controlled by the {{jboss-web.xml}}, like undertow-related like {{server-instance}} or others like {{security-domain}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7112) Allow optional tag virtual-host (and others) inside jboss-app.xml

by Guido Jäkel (JIRA)

Guido Jäkel created WFLY-7112: --------------------------------- Summary: Allow optional tag virtual-host (and others) inside jboss-app.xml Key: WFLY-7112 URL: https://issues.jboss.org/browse/WFLY-7112 Project: WildFly Issue Type: Feature Request Reporter: Guido Jäkel Assignee: Jason Greene With undertow, the assignment of a web-application to a virtual host must be set in {{$WAR/META-INF/jboss-web.xml}}. A very adjacent parameter, the context-root, might be defined or overridden here, too. In practice, for a concrete deployment generally one have to adapt both parts of the URL, the (virtual) host and the context-root part and may use this file and e.g. apply it with the overlay feature. In case of an EAR, its components are declared inside {{$EAR/META-INF/application.xml}}. For an web application, the {{context-root}} is defined here. I found, that this have precedence to a {{$WAR/WEB-INF/jboss-web.xml}}. I don't expect this, but it might be defined by JEE specifications in that way. If not, this feature request should be converted to a bug report concerning a wrong preference order. To my knowledge, at the moment this file seems the only way to set the {{virtual-host}} to use. And this looks very inconsistent to me, because you have to use two different "far-out" files to controll this very associated informations. The informations in application.xml may be overridden and enriched by {{jboss-appl.xml}} in a similar manner as with {{web.xml}} and {{jboss-web.xml}}. I would expect (and suggest it as a feature) to define the virtual host here in an analogous way as the context root in {{application.xml}} may be overriden here. {code} <module> <web> <web-uri>a.war</web-uri> <context-root>/foo</context-root> <virtual-host>a.domain.tld</virtual-host> ... </web> </module> {code} This concept should be probably expanded to the complete feature set controlled by the {{jboss-web.xml}}, like undertow-related like {{server-instance}} or others like {{security-domain}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1287) Incremental compilation doesn't take count of added/removed packages in KieBaseModel

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-1287: ----------------------------------- Summary: Incremental compilation doesn't take count of added/removed packages in KieBaseModel Key: DROOLS-1287 URL: https://issues.jboss.org/browse/DROOLS-1287 Project: Drools Issue Type: Bug Components: core engine Reporter: Mario Fusco Assignee: Mario Fusco -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1742) Allow registering a custom handler for management interface

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1742?page=com.atlassian.jira.plugi... ] Tristan Tarrant commented on WFCORE-1742: ----------------------------------------- To clarify Infinispan's requirements: - the ability to register an additional admin console in parallel with WildFly's when overlaying the Infinispan Datagrid subsystem on top. This is just serving static content (HTML, JS, CSS, etc) which talks to the /management context. A possible extension would allow WildFly's HAL to link to any additional admin consoles which may be overlayed. - The ability to register a custom handler to implement a health-check context. (Generically, mapping a specific resource or operation to a shor URL as [~sebastian.laskawiec] mentioned) > Allow registering a custom handler for management interface > ----------------------------------------------------------- > > Key: WFCORE-1742 > URL: https://issues.jboss.org/browse/WFCORE-1742 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Sebastian Łaskawiec > > When building [HealthCheck API for Infisnispan|https://github.com/infinispan/infinispan/pull/4499] we noticed there is no way to register a custom endpoint on Management REST interface. Without it, calling the API requires using HTTP POST method (since it includes runtime parameters) and the URL is very long (and not intuitive for our users): > {noformat} > curl --digest -L -D - "http://localhost:9990/management/subsystem/datagrid-infinispan/cache-cont..." --header "Content-Type: application/json" -u ispnadmin:ispnadmin > HTTP/1.1 401 Unauthorized > Connection: keep-alive > WWW-Authenticate: Digest realm="ManagementRealm",domain="/management",nonce="AuZzFxz7uC4NMTQ3MDgyNTU1NTQ3OCfIJBHXVpPHPBdzGUy7Qts=",opaque="00000000000000000000000000000000",algorithm=MD5,qop="auth" > Content-Length: 77 > Content-Type: text/html > Date: Wed, 10 Aug 2016 10:39:15 GMT > HTTP/1.1 200 OK > Connection: keep-alive > Authentication-Info: nextnonce="AuZzFxz7uC4NMTQ3MDgyNTU1NTQ3OCfIJBHXVpPHPBdzGUy7Qts=",qop="auth",rspauth="b518c3170e627bd732055c382ce5d970",cnonce="NGViOWM0NDY5OGJmNjY0MjcyOWE4NDkyZDU3YzNhYjY=",nc=00000001 > Content-Type: application/json; charset=utf-8 > Content-Length: 1927 > Date: Wed, 10 Aug 2016 10:39:15 GMT > { > "cache-health" : "GREEN", > "cluster-health" : ["test"], > "cluster-name" : "clustered", > "free-memory" : 96778, > "log-tail" : [ > "2016-08-10 11:54:14,706 INFO [org.infinispan.server.endpoint] (MSC service thread 1-5) DGENDPT10001: HotRodServer listening on 127.0.0.1:11222", > "2016-08-10 11:54:14,706 INFO [org.infinispan.server.endpoint] (MSC service thread 1-1) DGENDPT10001: MemcachedServer listening on 127.0.0.1:11211", > "2016-08-10 11:54:14,785 INFO [org.jboss.as.clustering.infinispan] (MSC service thread 1-6) DGISPN0001: Started ___protobuf_metadata cache from clustered container", > "2016-08-10 11:54:14,800 INFO [org.jboss.as.clustering.infinispan] (MSC service thread 1-6) DGISPN0001: Started ___script_cache cache from clustered container", > "2016-08-10 11:54:15,159 INFO [org.jboss.as.clustering.infinispan] (MSC service thread 1-5) DGISPN0001: Started ___hotRodTopologyCache cache from clustered container", > "2016-08-10 11:54:15,210 INFO [org.infinispan.rest.NettyRestServer] (MSC service thread 1-6) ISPN012003: REST server starting, listening on 127.0.0.1:8080", > "2016-08-10 11:54:15,210 INFO [org.infinispan.server.endpoint] (MSC service thread 1-6) DGENDPT10002: REST mapped to /rest", > "2016-08-10 11:54:15,306 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management", > "2016-08-10 11:54:15,307 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990", > "2016-08-10 11:54:15,307 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: Infinispan Server 9.0.0-SNAPSHOT (WildFly Core 2.2.0.CR9) started in 8681ms - Started 196 of 237 services (121 services are lazy, passive or on-demand)" > ], > "number-of-cpus" : 8, > "number-of-nodes" : 1, > "total-memory" : 235520 > }% > {noformat} > It would be very convenient to allow exposing such endpoints with optional authorization and using custom URLs (e.g. something like http://localhost:9990/health). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7111) Distributable web applications cause Infinispan exceptions when Elytron is used

by Josef Cacek (JIRA)

Josef Cacek created WFLY-7111: --------------------------------- Summary: Distributable web applications cause Infinispan exceptions when Elytron is used Key: WFLY-7111 URL: https://issues.jboss.org/browse/WFLY-7111 Project: WildFly Issue Type: Bug Components: Security Reporter: Josef Cacek Assignee: Darran Lofthouse Priority: Blocker When a distributable secured web application mapped to Elytron domain is deployed to EAP and accessed. It throws intermittently {{org.infinispan.util.concurrent.TimeoutException}} *Expected behavior:* Distributable applications should be accessible without exceptions when Elytron is used. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1286) GDT editor: unable to specify Literal value or Template key for domain objects as Condition BRL fragment

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1286?page=com.atlassian.jira.plugi... ] Mario Fusco reassigned DROOLS-1286: ----------------------------------- Assignee: Michael Anstis (was: Mario Fusco) > GDT editor: unable to specify Literal value or Template key for domain objects as Condition BRL fragment > --------------------------------------------------------------------------------------------------------- > > Key: DROOLS-1286 > URL: https://issues.jboss.org/browse/DROOLS-1286 > Project: Drools > Issue Type: Bug > Components: decision tables > Affects Versions: 6.4.0.Final > Reporter: Hiroko Miura > Assignee: Michael Anstis > Labels: support > Attachments: Screen_Shot.png > > > Guided Decision Table: When adding a Condition BRL fragment it is not possible to enter a template key or value for an attribute on a domain object. > In the attached screen shot, when clicking pencil icon, nothing appear. > This is confirmed by both FireFox anc Chrome. > At that time, the following error is shown in browser's console. > [Chrome] > 12:44:40 SEVERE [LogConfiguration] Exception caught: (TypeError) : Cannot read property 'indexOf' of null > > [FireFox] > 00:10:46 SEVERE [LogConfiguration] Exception caught: (TypeError) : b.indexOf is null -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1286) GDT editor: unable to specify Literal value or Template key for domain objects as Condition BRL fragment

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1286?page=com.atlassian.jira.plugi... ] Mario Fusco updated DROOLS-1286: -------------------------------- Reporter: Michael Anstis (was: Hiroko Miura) > GDT editor: unable to specify Literal value or Template key for domain objects as Condition BRL fragment > --------------------------------------------------------------------------------------------------------- > > Key: DROOLS-1286 > URL: https://issues.jboss.org/browse/DROOLS-1286 > Project: Drools > Issue Type: Bug > Components: decision tables > Affects Versions: 6.4.0.Final > Reporter: Michael Anstis > Assignee: Mario Fusco > Labels: support > Attachments: Screen_Shot.png > > > Guided Decision Table: When adding a Condition BRL fragment it is not possible to enter a template key or value for an attribute on a domain object. > In the attached screen shot, when clicking pencil icon, nothing appear. > This is confirmed by both FireFox anc Chrome. > At that time, the following error is shown in browser's console. > [Chrome] > 12:44:40 SEVERE [LogConfiguration] Exception caught: (TypeError) : Cannot read property 'indexOf' of null > > [FireFox] > 00:10:46 SEVERE [LogConfiguration] Exception caught: (TypeError) : b.indexOf is null -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1286) GDT editor: unable to specify Literal value or Template key for domain objects as Condition BRL fragment

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1286?page=com.atlassian.jira.plugi... ] Mario Fusco updated DROOLS-1286: -------------------------------- Reporter: Hiroko Miura (was: Michael Anstis) > GDT editor: unable to specify Literal value or Template key for domain objects as Condition BRL fragment > --------------------------------------------------------------------------------------------------------- > > Key: DROOLS-1286 > URL: https://issues.jboss.org/browse/DROOLS-1286 > Project: Drools > Issue Type: Bug > Components: decision tables > Affects Versions: 6.4.0.Final > Reporter: Hiroko Miura > Assignee: Mario Fusco > Labels: support > Attachments: Screen_Shot.png > > > Guided Decision Table: When adding a Condition BRL fragment it is not possible to enter a template key or value for an attribute on a domain object. > In the attached screen shot, when clicking pencil icon, nothing appear. > This is confirmed by both FireFox anc Chrome. > At that time, the following error is shown in browser's console. > [Chrome] > 12:44:40 SEVERE [LogConfiguration] Exception caught: (TypeError) : Cannot read property 'indexOf' of null > > [FireFox] > 00:10:46 SEVERE [LogConfiguration] Exception caught: (TypeError) : b.indexOf is null -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2092) MERGE3: merge never happens

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2092?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2092: -------------------------------- A simple way to fix this would be to take the first members (coords) of all subviews and have them run the merge. In the Sept 12 example, this would be the set \{A,B,C\}. However, this would mean that _participants_ (not _coordinators_) would be able to run the show, ie. install new views, which is something that JGroups hasn't liked so far. I need to think about whether anyone being able to install new views is a security risk... Also, MERGE3 would have everyone run the ConsistencyChecker task, and not just the coordinators. Perhaps this additional behavior can be enabled via an attribute (in GMS and MERGE3). By default, it would be true, so participants are allowed to run merges and install views. If this turns out to cause no problems over a couple of releases, we can remove the flag again... > MERGE3: merge never happens > --------------------------- > > Key: JGRP-2092 > URL: https://issues.jboss.org/browse/JGRP-2092 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.11, 4.0 > > Attachments: jgroups.txt > > > (Reported by Neal Dillman) > In the case below, a merge doesn't seem to happen. Write a unit test to reprodue this. > {noformat} > Host A view: B, X, Y, Z, A (where B should be coordinator) > Host B view: C, Q, R, S, B (where C should be coordinator) > Host C view: A, M, N, O, C (where A should be coordinator) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7110) CDI request scope should be activated in the view interceptor chain

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-7110: ------------------------------------ Summary: CDI request scope should be activated in the view interceptor chain Key: WFLY-7110 URL: https://issues.jboss.org/browse/WFLY-7110 Project: WildFly Issue Type: Bug Components: CDI / Weld Reporter: Stuart Douglas Assignee: Stuart Douglas This allows it to run outside the transaction interceptor, so the scope will still be active when the transaction completes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7109) CDI request scope should be activated in the view interceptor chain

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-7109: ------------------------------------ Summary: CDI request scope should be activated in the view interceptor chain Key: WFLY-7109 URL: https://issues.jboss.org/browse/WFLY-7109 Project: WildFly Issue Type: Bug Components: CDI / Weld Reporter: Stuart Douglas Assignee: Stuart Douglas This allows it to run outside the transaction interceptor, so the scope will still be active when the transaction completes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1286) GDT editor: unable to specify Literal value or Template key for domain objects as Condition BRL fragment

by Hiroko Miura (JIRA)

Hiroko Miura created DROOLS-1286: ------------------------------------ Summary: GDT editor: unable to specify Literal value or Template key for domain objects as Condition BRL fragment Key: DROOLS-1286 URL: https://issues.jboss.org/browse/DROOLS-1286 Project: Drools Issue Type: Bug Components: decision tables Affects Versions: 6.4.0.Final Reporter: Hiroko Miura Assignee: Mario Fusco Attachments: Screen_Shot.png Guided Decision Table: When adding a Condition BRL fragment it is not possible to enter a template key or value for an attribute on a domain object. In the attached screen shot, when clicking pencil icon, nothing appear. This is confirmed by both FireFox anc Chrome. At that time, the following error is shown in browser's console. [Chrome] 12:44:40 SEVERE [LogConfiguration] Exception caught: (TypeError) : Cannot read property 'indexOf' of null [FireFox] 00:10:46 SEVERE [LogConfiguration] Exception caught: (TypeError) : b.indexOf is null -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7075) proposal (Extension): Adding ability of check testForMixedSynchronizationTypes by isJoinToTransaction (as current state of synchronization)

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-7075?page=com.atlassian.jira.plugin.... ] Scott Marlow updated WFLY-7075: ------------------------------- Description: As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution. *The obtained defect:* A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final. The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar) *FIX:* We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127 Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e... _Changes_: The method getSynchronizationType returns declared synchronization type. [WFLY-7108] is now the tracking jira for the fix. *Consequences:* We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction. Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call. It requires a declaration of synchronize persistence context. We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans. However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check. *Our actions:* We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization). This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false. _Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d... *Example for reproduction:* I modified quickstart example: [^kitchensink-ear.rar] MemberRepository begin Extended UNSYNCHRONIZED Persistence Context. MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED. MemberRepository also perform join Transaction. Questions from [~smarlow]: - whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it. We decided to use Container-managed EntityManager, because - Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components - The container makes our job We want to use the existing mechanism *In Addition:* Formally, this is out of JPA SPEC, but we have the following reasons: - In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?". But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given. ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... ) - We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach" was: As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution. *The obtained defect:* A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final. The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar) *FIX:* We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127 Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e... _Changes_: The method getSynchronizationType returns declared synchronization type. *Consequences:* We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction. Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call. It requires a declaration of synchronize persistence context. We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans. However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check. *Our actions:* We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization). This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false. _Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d... *Example for reproduction:* I modified quickstart example: [^kitchensink-ear.rar] MemberRepository begin Extended UNSYNCHRONIZED Persistence Context. MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED. MemberRepository also perform join Transaction. Questions from [~smarlow]: - whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it. We decided to use Container-managed EntityManager, because - Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components - The container makes our job We want to use the existing mechanism *In Addition:* Formally, this is out of JPA SPEC, but we have the following reasons: - In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?". But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given. ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... ) - We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach" > proposal (Extension): Adding ability of check testForMixedSynchronizationTypes by isJoinToTransaction (as current state of synchronization) > ------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7075 > URL: https://issues.jboss.org/browse/WFLY-7075 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Affects Versions: 10.1.0.Final > Environment: *AppServer:* WildFly 10.1.0.Final > *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar > Reporter: Viacheslav Astapkovich > Assignee: Scott Marlow > Attachments: kitchensink-ear.rar > > > As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution. > > *The obtained defect:* > A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final. > The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar) > *FIX:* > We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127 > Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e... > _Changes_: The method getSynchronizationType returns declared synchronization type. > [WFLY-7108] is now the tracking jira for the fix. > *Consequences:* > We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction. > Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call. > It requires a declaration of synchronize persistence context. > We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans. > However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check. > *Our actions:* > We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization). > This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false. > _Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d... > *Example for reproduction:* > I modified quickstart example: [^kitchensink-ear.rar] > MemberRepository begin Extended UNSYNCHRONIZED Persistence Context. > MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED. > MemberRepository also perform join Transaction. > Questions from [~smarlow]: > - whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it. > We decided to use Container-managed EntityManager, because > - Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components > - The container makes our job > We want to use the existing mechanism > *In Addition:* > Formally, this is out of JPA SPEC, but we have the following reasons: > - In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?". > But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given. > ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... ) > - We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7108) UNSYNCHRONIZED extended persistence context associated but not joined with JTA transaction and target component is persistence context of SYNCHRONIZED, IllegalStateException should be thrown

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-7108?page=com.atlassian.jira.plugin.... ] Scott Marlow updated WFLY-7108: ------------------------------- Description: As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution. *The obtained defect:* A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final. The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar) *FIX:* We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127 Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e... _Changes_: The method getSynchronizationType returns declared synchronization type. was: As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution. *The obtained defect:* A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final. The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar) *FIX:* We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127 Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e... _Changes_: The method getSynchronizationType returns declared synchronization type. *Consequences:* We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction. Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call. It requires a declaration of synchronize persistence context. We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans. However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check. *Our actions:* We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization). This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false. _Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d... *Example for reproduction:* I modified quickstart example: [^kitchensink-ear.rar] MemberRepository begin Extended UNSYNCHRONIZED Persistence Context. MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED. MemberRepository also perform join Transaction. Questions from [~smarlow]: - whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it. We decided to use Container-managed EntityManager, because - Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components - The container makes our job We want to use the existing mechanism *In Addition:* Formally, this is out of JPA SPEC, but we have the following reasons: - In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?". But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given. ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... ) - We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach" > UNSYNCHRONIZED extended persistence context associated but not joined with JTA transaction and target component is persistence context of SYNCHRONIZED, IllegalStateException should be thrown > ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7108 > URL: https://issues.jboss.org/browse/WFLY-7108 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Affects Versions: 10.1.0.Final > Environment: *AppServer:* WildFly 10.1.0.Final > *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar > Reporter: Scott Marlow > Assignee: Scott Marlow > > As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution. > > *The obtained defect:* > A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final. > The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar) > *FIX:* > We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127 > Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e... > _Changes_: The method getSynchronizationType returns declared synchronization type. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7108) UNSYNCHRONIZED extended persistence context associated but not joined with JTA transaction and target component is persistence context of SYNCHRONIZED, IllegalStateException should be thrown

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-7108?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-7108: ------------------------------------ [~veselroger] is the reporter of this jira, I cloned it from WFLY-7075. > UNSYNCHRONIZED extended persistence context associated but not joined with JTA transaction and target component is persistence context of SYNCHRONIZED, IllegalStateException should be thrown > ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7108 > URL: https://issues.jboss.org/browse/WFLY-7108 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Affects Versions: 10.1.0.Final > Environment: *AppServer:* WildFly 10.1.0.Final > *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar > Reporter: Scott Marlow > Assignee: Scott Marlow > > As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution. > > *The obtained defect:* > A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final. > The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar) > *FIX:* > We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127 > Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e... > _Changes_: The method getSynchronizationType returns declared synchronization type. > *Consequences:* > We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction. > Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call. > It requires a declaration of synchronize persistence context. > We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans. > However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check. > *Our actions:* > We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization). > This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false. > _Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d... > *Example for reproduction:* > I modified quickstart example: [^kitchensink-ear.rar] > MemberRepository begin Extended UNSYNCHRONIZED Persistence Context. > MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED. > MemberRepository also perform join Transaction. > Questions from [~smarlow]: > - whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it. > We decided to use Container-managed EntityManager, because > - Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components > - The container makes our job > We want to use the existing mechanism > *In Addition:* > Formally, this is out of JPA SPEC, but we have the following reasons: > - In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?". > But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given. > ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... ) > - We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7108) UNSYNCHRONIZED extended persistence context associated but not joined with JTA transaction and target component is persistence context of SYNCHRONIZED, IllegalStateException should be thrown

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-7108?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-7108: ------------------------------------ WFLY-7075 adds an extension for disabling the test for whether the unsynchronized persistence context is available when a synchronized (or JTA joined) persistence context is needed. WFLY-7108 addresses the identified bug mentioned in WFLY-7075. We will fix the identified bug via a separate jira in case we decide to back port the bug fix but not the extension. At this point, I think they are both useful but still prefer the separation. > UNSYNCHRONIZED extended persistence context associated but not joined with JTA transaction and target component is persistence context of SYNCHRONIZED, IllegalStateException should be thrown > ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7108 > URL: https://issues.jboss.org/browse/WFLY-7108 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Affects Versions: 10.1.0.Final > Environment: *AppServer:* WildFly 10.1.0.Final > *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar > Reporter: Scott Marlow > Assignee: Scott Marlow > > As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution. > > *The obtained defect:* > A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final. > The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar) > *FIX:* > We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127 > Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e... > _Changes_: The method getSynchronizationType returns declared synchronization type. > *Consequences:* > We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction. > Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call. > It requires a declaration of synchronize persistence context. > We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans. > However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check. > *Our actions:* > We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization). > This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false. > _Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d... > *Example for reproduction:* > I modified quickstart example: [^kitchensink-ear.rar] > MemberRepository begin Extended UNSYNCHRONIZED Persistence Context. > MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED. > MemberRepository also perform join Transaction. > Questions from [~smarlow]: > - whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it. > We decided to use Container-managed EntityManager, because > - Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components > - The container makes our job > We want to use the existing mechanism > *In Addition:* > Formally, this is out of JPA SPEC, but we have the following reasons: > - In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?". > But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given. > ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... ) > - We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7108) UNSYNCHRONIZED extended persistence context associated but not joined with JTA transaction and target component is persistence context of SYNCHRONIZED, IllegalStateException should be thrown

by Scott Marlow (JIRA)

Scott Marlow created WFLY-7108: ---------------------------------- Summary: UNSYNCHRONIZED extended persistence context associated but not joined with JTA transaction and target component is persistence context of SYNCHRONIZED, IllegalStateException should be thrown Key: WFLY-7108 URL: https://issues.jboss.org/browse/WFLY-7108 Project: WildFly Issue Type: Feature Request Components: JPA / Hibernate Affects Versions: 10.1.0.Final Environment: *AppServer:* WildFly 10.1.0.Final *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar Reporter: Scott Marlow Assignee: Scott Marlow As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution. *The obtained defect:* A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final. The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar) *FIX:* We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127 Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e... _Changes_: The method getSynchronizationType returns declared synchronization type. *Consequences:* We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction. Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call. It requires a declaration of synchronize persistence context. We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans. However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check. *Our actions:* We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization). This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false. _Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d... *Example for reproduction:* I modified quickstart example: [^kitchensink-ear.rar] MemberRepository begin Extended UNSYNCHRONIZED Persistence Context. MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED. MemberRepository also perform join Transaction. Questions from [~smarlow]: - whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it. We decided to use Container-managed EntityManager, because - Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components - The container makes our job We want to use the existing mechanism *In Addition:* Formally, this is out of JPA SPEC, but we have the following reasons: - In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?". But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given. ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... ) - We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1199) Memory leak in KieScanner

by Mrunali Patil (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1199?page=com.atlassian.jira.plugi... ] Mrunali Patil commented on DROOLS-1199: --------------------------------------- How we can apply this patch to 6.4.Final version. Please can you suggest? As we are getting the OOM errors. > Memory leak in KieScanner > ------------------------- > > Key: DROOLS-1199 > URL: https://issues.jboss.org/browse/DROOLS-1199 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.4.0.Final > Reporter: Viacheslav Krot > Assignee: Mario Fusco > Fix For: 7.0.0.Beta1 > > > I'm not sure, but it seems there is a memory leak in KieScanner, not in scanner directly, but somewhere in plexus used internally. > If you start KieScanner with version = LATEST, start it with interval say 1 second and sample memory with visualvm (or any other), you can watch number of instances org.eclipse.sisu.plexus.* growing over time. And they cannot be garbage collected - memory root is timer thread. This happens in drools 6.4.0, in 6.3.0 this issue was absent. > Eventually application fails with OOM. > As a workaround we call KieScanner#scan manually in a separate thread pool that is recreated from time to time. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1796) read-attribute on non existing logger under /deployment throws NPE

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1796?page=com.atlassian.jira.plugi... ] James Perkins moved JBEAP-6010 to WFCORE-1796: ---------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-1796 (was: JBEAP-6010) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Logging (was: Logging) Affects Version/s: (was: 7.1.0.DR4) > read-attribute on non existing logger under /deployment throws NPE > ------------------------------------------------------------------ > > Key: WFCORE-1796 > URL: https://issues.jboss.org/browse/WFCORE-1796 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Minor > > {noformat} > [standalone@localhost:9990 /] /deployment=testwebapplication.war/subsystem=logging/configuration=default/logger=unknown:read-attribute(name=level > { > "outcome" => "failed", > "result" => undefined, > "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.NullPointerException", > "rolled-back" => true > } > {noformat} > Output: > {noformat} > 17:11:30,742 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("read-attribute") failed - address: ([ > ("deployment" => "testwebapplication.war"), > ("subsystem" => "logging"), > ("configuration" => "default"), > ("logger" => "unknown") > ]): java.lang.NullPointerException > at org.jboss.as.logging.deployments.resources.LoggerResourceDefinition$1.updateModel(LoggerResourceDefinition.java:77) > at org.jboss.as.logging.deployments.resources.LoggerResourceDefinition$LoggerConfigurationReadStepHandler.updateModel(LoggerResourceDefinition.java:105) > at org.jboss.as.logging.deployments.resources.LoggingConfigurationReadStepHandler.execute(LoggingConfigurationReadStepHandler.java:51) > at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecuteInternal(ReadAttributeHandler.java:174) > at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecute(ReadAttributeHandler.java:133) > at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:230) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:951) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:694) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:389) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAs(Subject.java:422) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {noformat} > it should print some better error messsage, like: > {noformat} > [standalone@localhost:9990 /] /subsystem=logging/logger=unknown:read-attribute(name=level > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0216: Management resource '[ > (\"subsystem\" => \"logging\"), > (\"logger\" => \"unknown\") > ]' not found", > "rolled-back" => true > } > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-254) logging-profiles doesn't work with Apache Common Logging

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-254?page=com.atlassian.jira.plugin... ] James Perkins updated WFCORE-254: --------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1799, https://github.com/wildfly/wildfly/pull/9188 (was: https://github.com/wildfly/wildfly-core/pull/1799) > logging-profiles doesn't work with Apache Common Logging > -------------------------------------------------------- > > Key: WFCORE-254 > URL: https://issues.jboss.org/browse/WFCORE-254 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: Anders Welen > Assignee: James Perkins > Priority: Minor > Attachments: 87905.tar > > > The logging for one logging-profile ends up in another logging-profile from time to time. It's not sporadic as all logging will end up in the wrong place when things go wrong. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2092) MERGE3: merge never happens

by Neal Dillman (JIRA)

[ https://issues.jboss.org/browse/JGRP-2092?page=com.atlassian.jira.plugin.... ] Neal Dillman commented on JGRP-2092: ------------------------------------ That is correct -- the issue was only seen during merges. It is exacerbated with a significant quantity of hosts across bandwidth limited routed network. More specifically, if there are hosts on a 1G network that are connected by lower bandwidth lines -- like 256k. > MERGE3: merge never happens > --------------------------- > > Key: JGRP-2092 > URL: https://issues.jboss.org/browse/JGRP-2092 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.11, 4.0 > > Attachments: jgroups.txt > > > (Reported by Neal Dillman) > In the case below, a merge doesn't seem to happen. Write a unit test to reprodue this. > {noformat} > Host A view: B, X, Y, Z, A (where B should be coordinator) > Host B view: C, Q, R, S, B (where C should be coordinator) > Host C view: A, M, N, O, C (where A should be coordinator) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1791) Strange operation-id handling in domain server reload execution

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1791?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1791: ------------------------------------- Issue Type: Task (was: Bug) Priority: Minor (was: Major) I've changed this from a Bug to a Task because a debugging sessions shows that this operation-id passing works correctly. The task is to understand how. :) And perhaps add some more comments so it's less mysterious. > Strange operation-id handling in domain server reload execution > --------------------------------------------------------------- > > Key: WFCORE-1791 > URL: https://issues.jboss.org/browse/WFCORE-1791 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Priority: Minor > > When the HC sends a reload op to a managed server it includes an undocumented "operation-id" parameter. But, I don’t see how it is used with a reload. When it was added to the code the intent clearly was that it would be used, but now at least is not. ServerDomainProcessReloadHandler reads it from the op and sets DomainServerCommunicationServices.initialOperationId, but that field is only read when HostControllerConnectionService is instantiated. HostControllerConnectionService then caches the value in a final field. A reload does not result in a new instantiation of HostControllerConnectionService; that object is only instantiated during initial process boot when ServerStartTask is unmarshaled from stdin and run. So changing the DomainServerCommunicationServices.initialOperationId in a reload should do nothing. > https://github.com/wildfly/wildfly-core/commit/302949cf60823d8aa3989d74df... is the initial commit when this update of the id in reload was added in. The intent was that by providing this id, when the reloading server connects to the HC to get the boot ops, that read of boot ops would be able to "join" any active operation that triggered the reload, and thus would not have to block waiting for that operation to complete. > Afaict, if the "blocking" param on an op like /host=x/server[-config]=y:reload is set to 'true' the op should deadlock. On the HC, ServerReloadHandler will acquire the exclusive lock by calling context.getServiceRegistry(true). Then ServerInventoryImpl.reloadServer will block waiting for the server to reach STARTED state. But the server won't reach that because it's registration request will not be able to acquire the HC lock. > Task here is to > 1) Confirm the above and then > 2) Either > a) get the operation-id propagated > b) or rip the operation-id bit out of reload because investigation showed it was not needed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7106) Reject distributed web sessions with missing attribute cache entries

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-7106: ---------------------------------- Summary: Reject distributed web sessions with missing attribute cache entries Key: WFLY-7106 URL: https://issues.jboss.org/browse/WFLY-7106 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 10.1.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 11.0.0.Alpha1 If we detect cache entry integrity constraint violations, then the session is invalid, and we should report it as not found and purge the orphaned entries. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7107) Reject distributed web sessions with missing attribute cache entries

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-7107: ---------------------------------- Summary: Reject distributed web sessions with missing attribute cache entries Key: WFLY-7107 URL: https://issues.jboss.org/browse/WFLY-7107 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 10.1.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 11.0.0.Alpha1 If we detect cache entry integrity constraint violations, then the session is invalid, and we should report it as not found and purge the orphaned entries. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1786) SelfContainedContainer: Allow the ConfigurationPersisterFactory to be customised

by Heiko Braun (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1786?page=com.atlassian.jira.plugi... ] Heiko Braun updated WFCORE-1786: -------------------------------- Issue Type: Bug (was: Feature Request) > SelfContainedContainer: Allow the ConfigurationPersisterFactory to be customised > -------------------------------------------------------------------------------- > > Key: WFCORE-1786 > URL: https://issues.jboss.org/browse/WFCORE-1786 > Project: WildFly Core > Issue Type: Bug > Components: Server > Reporter: Heiko Braun > Assignee: Heiko Braun > Fix For: 3.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1742) Allow registering a custom handler for management interface

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1742?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1742: ------------------------------------------ "showing runtime resources requires sending HTTP PUT (not GET)" That's interesting. That may just be a result of the basic management API continuing to evolve after the HTTP code was written so parameters to read-resource/read-attribute are not picked up. [~dlofthouse] can you think of any security reason for that behavior? > Allow registering a custom handler for management interface > ----------------------------------------------------------- > > Key: WFCORE-1742 > URL: https://issues.jboss.org/browse/WFCORE-1742 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Sebastian Łaskawiec > > When building [HealthCheck API for Infisnispan|https://github.com/infinispan/infinispan/pull/4499] we noticed there is no way to register a custom endpoint on Management REST interface. Without it, calling the API requires using HTTP POST method (since it includes runtime parameters) and the URL is very long (and not intuitive for our users): > {noformat} > curl --digest -L -D - "http://localhost:9990/management/subsystem/datagrid-infinispan/cache-cont..." --header "Content-Type: application/json" -u ispnadmin:ispnadmin > HTTP/1.1 401 Unauthorized > Connection: keep-alive > WWW-Authenticate: Digest realm="ManagementRealm",domain="/management",nonce="AuZzFxz7uC4NMTQ3MDgyNTU1NTQ3OCfIJBHXVpPHPBdzGUy7Qts=",opaque="00000000000000000000000000000000",algorithm=MD5,qop="auth" > Content-Length: 77 > Content-Type: text/html > Date: Wed, 10 Aug 2016 10:39:15 GMT > HTTP/1.1 200 OK > Connection: keep-alive > Authentication-Info: nextnonce="AuZzFxz7uC4NMTQ3MDgyNTU1NTQ3OCfIJBHXVpPHPBdzGUy7Qts=",qop="auth",rspauth="b518c3170e627bd732055c382ce5d970",cnonce="NGViOWM0NDY5OGJmNjY0MjcyOWE4NDkyZDU3YzNhYjY=",nc=00000001 > Content-Type: application/json; charset=utf-8 > Content-Length: 1927 > Date: Wed, 10 Aug 2016 10:39:15 GMT > { > "cache-health" : "GREEN", > "cluster-health" : ["test"], > "cluster-name" : "clustered", > "free-memory" : 96778, > "log-tail" : [ > "2016-08-10 11:54:14,706 INFO [org.infinispan.server.endpoint] (MSC service thread 1-5) DGENDPT10001: HotRodServer listening on 127.0.0.1:11222", > "2016-08-10 11:54:14,706 INFO [org.infinispan.server.endpoint] (MSC service thread 1-1) DGENDPT10001: MemcachedServer listening on 127.0.0.1:11211", > "2016-08-10 11:54:14,785 INFO [org.jboss.as.clustering.infinispan] (MSC service thread 1-6) DGISPN0001: Started ___protobuf_metadata cache from clustered container", > "2016-08-10 11:54:14,800 INFO [org.jboss.as.clustering.infinispan] (MSC service thread 1-6) DGISPN0001: Started ___script_cache cache from clustered container", > "2016-08-10 11:54:15,159 INFO [org.jboss.as.clustering.infinispan] (MSC service thread 1-5) DGISPN0001: Started ___hotRodTopologyCache cache from clustered container", > "2016-08-10 11:54:15,210 INFO [org.infinispan.rest.NettyRestServer] (MSC service thread 1-6) ISPN012003: REST server starting, listening on 127.0.0.1:8080", > "2016-08-10 11:54:15,210 INFO [org.infinispan.server.endpoint] (MSC service thread 1-6) DGENDPT10002: REST mapped to /rest", > "2016-08-10 11:54:15,306 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management", > "2016-08-10 11:54:15,307 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990", > "2016-08-10 11:54:15,307 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: Infinispan Server 9.0.0-SNAPSHOT (WildFly Core 2.2.0.CR9) started in 8681ms - Started 196 of 237 services (121 services are lazy, passive or on-demand)" > ], > "number-of-cpus" : 8, > "number-of-nodes" : 1, > "total-memory" : 235520 > }% > {noformat} > It would be very convenient to allow exposing such endpoints with optional authorization and using custom URLs (e.g. something like http://localhost:9990/health). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7105) Incorrect redirection after authentization when using elytron

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7105?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-7105: ---------------------------------------- This issue is being triggered by how Undertow is setting the requestPath within the HttpServerExchange. In my own testing my application is deployed at http://loclahost:8080/HelloWorld, from here I click on a link to /HelloWorld/secured-page as I have a welcome page so within ServletInitialHandler this block of code is executed: - {code:java} } else if (info.getType() == ServletPathMatch.Type.REWRITE) { //this can only happen if the path ends with a / //otherwise there would be a redirect instead exchange.setRelativePath(info.getRewriteLocation()); exchange.setRequestPath(exchange.getRequestPath() + info.getRewriteLocation()); } {code} The original request path was '/HelloWorld/secured-page/' so by concatenating it with the output from info.getRewriteLocation() we end up with '/HelloWorld/secured-page//secured-page/index.html' - maybe this should be using the resolved path instead of the request path? > Incorrect redirection after authentization when using elytron > ------------------------------------------------------------- > > Key: WFLY-7105 > URL: https://issues.jboss.org/browse/WFLY-7105 > Project: WildFly > Issue Type: Bug > Components: Security, Web (Undertow) > Reporter: Radim Hatlapatka > Assignee: Stuart Douglas > Priority: Critical > Attachments: defined-security-domain.war, roles.properties, standalone-elytron-web-tests.xml, users.properties > > > Having web application which uses defined security domain, which is set up using elytron results in incorrect redirection. It is redirecting after authentication done at {{http://localhost:8080/defined-security-domain/user/}} to {{http://localhost:8080/defined-security-domain/user//user/index.jsp}} instead of to {{http://localhost:8080/defined-security-domain/user/index.jsp}}. > Note, when using only old security domain setup without elytron, it works just fine. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7105) Incorrect redirection after authentization when using elytron

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7105?page=com.atlassian.jira.plugin.... ] Darran Lofthouse reassigned WFLY-7105: -------------------------------------- Assignee: Stuart Douglas (was: Darran Lofthouse) > Incorrect redirection after authentization when using elytron > ------------------------------------------------------------- > > Key: WFLY-7105 > URL: https://issues.jboss.org/browse/WFLY-7105 > Project: WildFly > Issue Type: Bug > Components: Security, Web (Undertow) > Reporter: Radim Hatlapatka > Assignee: Stuart Douglas > Priority: Critical > Attachments: defined-security-domain.war, roles.properties, standalone-elytron-web-tests.xml, users.properties > > > Having web application which uses defined security domain, which is set up using elytron results in incorrect redirection. It is redirecting after authentication done at {{http://localhost:8080/defined-security-domain/user/}} to {{http://localhost:8080/defined-security-domain/user//user/index.jsp}} instead of to {{http://localhost:8080/defined-security-domain/user/index.jsp}}. > Note, when using only old security domain setup without elytron, it works just fine. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7105) Incorrect redirection after authentization when using elytron

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7105?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-7105: ---------------------------------------- A quick look at the test war suggests this bug is triggered as a welcome-page is used. > Incorrect redirection after authentization when using elytron > ------------------------------------------------------------- > > Key: WFLY-7105 > URL: https://issues.jboss.org/browse/WFLY-7105 > Project: WildFly > Issue Type: Bug > Components: Security, Web (Undertow) > Reporter: Radim Hatlapatka > Assignee: Darran Lofthouse > Priority: Critical > Attachments: defined-security-domain.war, roles.properties, standalone-elytron-web-tests.xml, users.properties > > > Having web application which uses defined security domain, which is set up using elytron results in incorrect redirection. It is redirecting after authentication done at {{http://localhost:8080/defined-security-domain/user/}} to {{http://localhost:8080/defined-security-domain/user//user/index.jsp}} instead of to {{http://localhost:8080/defined-security-domain/user/index.jsp}}. > Note, when using only old security domain setup without elytron, it works just fine. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7105) Incorrect redirection after authentization when using elytron

by Radim Hatlapatka (JIRA)

[ https://issues.jboss.org/browse/WFLY-7105?page=com.atlassian.jira.plugin.... ] Radim Hatlapatka updated WFLY-7105: ----------------------------------- Description: Having web application which uses defined security domain, which is set up using elytron results in incorrect redirection. It is redirecting after authentication done at {{http://localhost:8080/defined-security-domain/user/}} to {{http://localhost:8080/defined-security-domain/user//user/index.jsp}} instead of to {{http://localhost:8080/defined-security-domain/user/index.jsp}}. Note, when using only old security domain setup without elytron, it works just fine. was: Having web application which uses defined security domain, which is set up using elytron results in incorrect redirection. It is redirecting after authentization done at {{http://localhost:8080/defined-security-domain/user/}} to {{http://localhost:8080/defined-security-domain/user//user/index.jsp}} instead of to {{http://localhost:8080/defined-security-domain/user/index.jsp}}. Note, when using only old security domain setup without elytron, it works just fine. > Incorrect redirection after authentization when using elytron > ------------------------------------------------------------- > > Key: WFLY-7105 > URL: https://issues.jboss.org/browse/WFLY-7105 > Project: WildFly > Issue Type: Bug > Components: Security, Web (Undertow) > Reporter: Radim Hatlapatka > Assignee: Darran Lofthouse > Priority: Critical > Attachments: defined-security-domain.war, roles.properties, standalone-elytron-web-tests.xml, users.properties > > > Having web application which uses defined security domain, which is set up using elytron results in incorrect redirection. It is redirecting after authentication done at {{http://localhost:8080/defined-security-domain/user/}} to {{http://localhost:8080/defined-security-domain/user//user/index.jsp}} instead of to {{http://localhost:8080/defined-security-domain/user/index.jsp}}. > Note, when using only old security domain setup without elytron, it works just fine. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7105) Incorrect redirection after authentization when using elytron

by Radim Hatlapatka (JIRA)

[ https://issues.jboss.org/browse/WFLY-7105?page=com.atlassian.jira.plugin.... ] Radim Hatlapatka reassigned WFLY-7105: -------------------------------------- Assignee: Darran Lofthouse (was: Stuart Douglas) > Incorrect redirection after authentization when using elytron > ------------------------------------------------------------- > > Key: WFLY-7105 > URL: https://issues.jboss.org/browse/WFLY-7105 > Project: WildFly > Issue Type: Bug > Components: Security, Web (Undertow) > Reporter: Radim Hatlapatka > Assignee: Darran Lofthouse > Priority: Critical > Attachments: defined-security-domain.war, roles.properties, standalone-elytron-web-tests.xml, users.properties > > > Having web application which uses defined security domain, which is set up using elytron results in incorrect redirection. It is redirecting after authentization done at {{http://localhost:8080/defined-security-domain/user/}} to {{http://localhost:8080/defined-security-domain/user//user/index.jsp}} instead of to {{http://localhost:8080/defined-security-domain/user/index.jsp}}. > Note, when using only old security domain setup without elytron, it works just fine. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7105) Incorrect redirection after authentization when using elytron

by Radim Hatlapatka (JIRA)

[ https://issues.jboss.org/browse/WFLY-7105?page=com.atlassian.jira.plugin.... ] Radim Hatlapatka updated WFLY-7105: ----------------------------------- Attachment: defined-security-domain.war users.properties standalone-elytron-web-tests.xml roles.properties > Incorrect redirection after authentization when using elytron > ------------------------------------------------------------- > > Key: WFLY-7105 > URL: https://issues.jboss.org/browse/WFLY-7105 > Project: WildFly > Issue Type: Bug > Components: Security, Web (Undertow) > Reporter: Radim Hatlapatka > Assignee: Stuart Douglas > Priority: Critical > Attachments: defined-security-domain.war, roles.properties, standalone-elytron-web-tests.xml, users.properties > > > Having web application which uses defined security domain, which is set up using elytron results in incorrect redirection. It is redirecting after authentization done at {{http://localhost:8080/defined-security-domain/user/}} to {{http://localhost:8080/defined-security-domain/user//user/index.jsp}} instead of to {{http://localhost:8080/defined-security-domain/user/index.jsp}}. > Note, when using only old security domain setup without elytron, it works just fine. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7105) Incorrect redirection after authentization when using elytron

by Radim Hatlapatka (JIRA)

Radim Hatlapatka created WFLY-7105: -------------------------------------- Summary: Incorrect redirection after authentization when using elytron Key: WFLY-7105 URL: https://issues.jboss.org/browse/WFLY-7105 Project: WildFly Issue Type: Bug Components: Web (Undertow), Security Reporter: Radim Hatlapatka Assignee: Stuart Douglas Priority: Critical Having web application which uses defined security domain, which is set up using elytron results in incorrect redirection. It is redirecting after authentization done at {{http://localhost:8080/defined-security-domain/user/}} to {{http://localhost:8080/defined-security-domain/user//user/index.jsp}} instead of to {{http://localhost:8080/defined-security-domain/user/index.jsp}}. Note, when using only old security domain setup without elytron, it works just fine. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1794) AttachmentHandler, handle invalid options and batch steps handling.

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1794?page=com.atlassian.jira.plugi... ] Jean-Francois Denise updated WFCORE-1794: ----------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1798 > AttachmentHandler, handle invalid options and batch steps handling. > ------------------------------------------------------------------- > > Key: WFCORE-1794 > URL: https://issues.jboss.org/browse/WFCORE-1794 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > > The step number is not incremented. This makes the attachment command to behave strangely. As described in EAP7-602. > The file and overwrite options should be rejected for display. As described in EAP7-602 too. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7103) In elytron security domain add operation the realms attribute is not marked as required even though it is not nillable and has no default value with no default value

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7103?page=com.atlassian.jira.plugin.... ] Jan Kalina commented on WFLY-7103: ---------------------------------- As we already require filled default-realm, which must be one of realms, realms should be required too. > In elytron security domain add operation the realms attribute is not marked as required even though it is not nillable and has no default value with no default value > --------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7103 > URL: https://issues.jboss.org/browse/WFLY-7103 > Project: WildFly > Issue Type: Bug > Components: Domain Management, Security > Reporter: Radim Hatlapatka > Assignee: Jan Kalina > > When reading description of the {{add}} operation for elytron security domain => {{/subsystem=elytron/security-domain=test-domain:read-operation-description(name=add)}}, the realms attribute has set required to false. Still it needs to be defined as part of {{add}} operation as it is not nillable. > If it is really mandatory, it should be marked as required. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2092) MERGE3: merge never happens

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2092?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2092: -------------------------------- OK, after thinking long about this, below are the steps that can lead to a situation where there is no coordinator. The only case I found is caused by merging itself; regular leaves, joins or crashes cannot lead to such a scenario. The cluster nodes are \{A,B,C,D\}. Now there's a split between \{A\} and \{B,C,D\}. The views are now: {noformat} A: A B: BCD C: BCD D: BCD {noformat} The partition heals and a merge starts with merge participants A and B and merge leader B. A and B agree on the new MergeView \{D,C,B,A\} (this is possibly as lexical UUID sorting is used by default) and A and B multicast that view in both of their respective partitions. Let's say that D dropped the new view because its thread pool was full. Before B can retransmit the view, B crashes as well. The views are now: {noformat} A: DCBA B: - // crashed C: DCBA D: BCD // old view {noformat} Now B is suspected and removed from all views: {noformat} A: DCA C: DCA D: CD // old view {noformat} Because B crashed, D will never get the correct view \{D,C,A\} in which it would be a coordinator and thus start a successful merge. Therefore these steps lead to a scenario where a merge will never happen! Note that if a new member (e.g. E) joined as _singleton_ (view: \{E\}), then a successful merge would ensue as E would be the merge leader. Although the above steps are an edge case the probability of which happening is very small, it this does happen, there's no way MERGE3 and GMS it their current state can resolve this, as a merge will never even start. > MERGE3: merge never happens > --------------------------- > > Key: JGRP-2092 > URL: https://issues.jboss.org/browse/JGRP-2092 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.11, 4.0 > > Attachments: jgroups.txt > > > (Reported by Neal Dillman) > In the case below, a merge doesn't seem to happen. Write a unit test to reprodue this. > {noformat} > Host A view: B, X, Y, Z, A (where B should be coordinator) > Host B view: C, Q, R, S, B (where C should be coordinator) > Host C view: A, M, N, O, C (where A should be coordinator) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1716) JMX domains jboss.as and jboss.as.expr do not always correctly handle propertly list patters in queryMBeans and queryNames

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1716?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-1716: ------------------------------------------------- Radovan Netuka <rnetuka(a)redhat.com> changed the Status of [bug 1367784|https://bugzilla.redhat.com/show_bug.cgi?id=1367784] from NEW to ASSIGNED > JMX domains jboss.as and jboss.as.expr do not always correctly handle propertly list patters in queryMBeans and queryNames > -------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1716 > URL: https://issues.jboss.org/browse/WFCORE-1716 > Project: WildFly Core > Issue Type: Bug > Components: JMX > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 3.0.0.Alpha6 > > > The ObjectName filtering logic added for WFLY-3161 does not handle queryMBeans and queryNames correctly in some cases where the ObjectName param to the method is a property list pattern (i.e. one that includes a simple '*' at the end of the list of properties, meaning "all other properties besides previous ones whose keys were specifically enumerated, match".) > The problem occurs when the the ObjectName does specifically include some keys, and those keys don't correspond to the final elements of the related management resource's PathAddress. As the RootResourceIterator walks the management resource tree, ModelControllerMBeanHelper.ObjectNameMatchResourceAction will not identify the parent resources of children that should match as matching, with the result that the iterator will not descend into that part of the tree and the children will not be matched. For example, this query will return an empty set because the /socket-binding-group=standard-sockets parent will not be matched, preventing checks of the socket-binding-group children. > {code} > Set<ObjectInstance> instances = connection.queryMBeans(createObjectName("jboss.as:socket-binding=*,*"), null); > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1795) :query() operation fails with IllegalArgumentException when specifying a where parameter

by Alexey Loubyansky (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1795?page=com.atlassian.jira.plugi... ] Alexey Loubyansky reassigned WFCORE-1795: ----------------------------------------- Assignee: Jean-Francois Denise (was: Alexey Loubyansky) Jeff, could you please take a look? Thanks! > :query() operation fails with IllegalArgumentException when specifying a where parameter > ---------------------------------------------------------------------------------------- > > Key: WFCORE-1795 > URL: https://issues.jboss.org/browse/WFCORE-1795 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI, Domain Management > Reporter: Harald Pehl > Assignee: Jean-Francois Denise > > This operation works in WFLY 10: > {code} > /host=*/server=*:query(select=["name"],where={"server-group" = "main-server-group"}) > {code} > whereas it fails with an IllegalArgumentException in WFLY 11 > Without the {{where}} parameter the operation works. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2092) MERGE3: merge never happens

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2092?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2092: -------------------------------- Hi [~ndillman] {quote} We no longer see the issue as it was worked around with staggering responses for all of the "bulk response" messages (ie: view change, etc). {quote} This may have reduced the chances of such a scenario happening, but I don't think it eliminated it completely. In my next comment, I'll show how such a scenario can be reproduced. Yes, a solution will involve a non-coordinator becoming merge leader, but this requires code changes in 3 places: the merge detection, the merge leader determination and the actual merge merge. > MERGE3: merge never happens > --------------------------- > > Key: JGRP-2092 > URL: https://issues.jboss.org/browse/JGRP-2092 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.11, 4.0 > > Attachments: jgroups.txt > > > (Reported by Neal Dillman) > In the case below, a merge doesn't seem to happen. Write a unit test to reprodue this. > {noformat} > Host A view: B, X, Y, Z, A (where B should be coordinator) > Host B view: C, Q, R, S, B (where C should be coordinator) > Host C view: A, M, N, O, C (where A should be coordinator) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1795) :query() operation fails with IllegalArgumentException when specifying a where parameter

by Harald Pehl (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1795?page=com.atlassian.jira.plugi... ] Harald Pehl updated WFCORE-1795: -------------------------------- Summary: :query() operation fails with IllegalArgumentException when specifying a where parameter (was: :query operation fails with IllegalArgumentException when specifying a where parameter) > :query() operation fails with IllegalArgumentException when specifying a where parameter > ---------------------------------------------------------------------------------------- > > Key: WFCORE-1795 > URL: https://issues.jboss.org/browse/WFCORE-1795 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI, Domain Management > Reporter: Harald Pehl > Assignee: Alexey Loubyansky > > This operation works in WFLY 10: > {code} > /host=*/server=*:query(select=["name"],where={"server-group" = "main-server-group"}) > {code} > whereas it fails with an IllegalArgumentException in WFLY 11 > Without the {{where}} parameter the operation works. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1795) :query operation fails with IllegalArgumentException when specifying a where parameter

by Harald Pehl (JIRA)

Harald Pehl created WFCORE-1795: ----------------------------------- Summary: :query operation fails with IllegalArgumentException when specifying a where parameter Key: WFCORE-1795 URL: https://issues.jboss.org/browse/WFCORE-1795 Project: WildFly Core Issue Type: Feature Request Components: CLI, Domain Management Reporter: Harald Pehl Assignee: Alexey Loubyansky This operation works in WFLY 10: {code} /host=*/server=*:query(select=["name"],where={"server-group" = "main-server-group"}) {code} whereas it fails with an IllegalArgumentException in WFLY 11 Without the {{where}} parameter the operation works. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1794) AttachmentHandler, handle invalid options and batch steps handling.

by Jean-Francois Denise (JIRA)

Jean-Francois Denise created WFCORE-1794: -------------------------------------------- Summary: AttachmentHandler, handle invalid options and batch steps handling. Key: WFCORE-1794 URL: https://issues.jboss.org/browse/WFCORE-1794 Project: WildFly Core Issue Type: Bug Components: CLI Reporter: Jean-Francois Denise Assignee: Jean-Francois Denise The step number is not incremented. This makes the attachment command to behave strangely. As described in EAP7-602. The file and overwrite options should be rejected for display. As described in EAP7-602 too. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7102) Allow subsystems to register their context handlers to the management endpoint

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/WFLY-7102?page=com.atlassian.jira.plugin.... ] Tristan Tarrant closed WFLY-7102. --------------------------------- Resolution: Duplicate Issue > Allow subsystems to register their context handlers to the management endpoint > ------------------------------------------------------------------------------ > > Key: WFLY-7102 > URL: https://issues.jboss.org/browse/WFLY-7102 > Project: WildFly > Issue Type: Feature Request > Components: Domain Management > Reporter: Tristan Tarrant > Assignee: Brian Stansberry > > For layered products, we would like to be able to register custom handlers to the management endpoint (e.g. for exposing health-check URLs) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7104) Elytron properties-realm enforces REALM_NAME comment

by Josef Cacek (JIRA)

Josef Cacek created WFLY-7104: --------------------------------- Summary: Elytron properties-realm enforces REALM_NAME comment Key: WFLY-7104 URL: https://issues.jboss.org/browse/WFLY-7104 Project: WildFly Issue Type: Bug Components: Security Reporter: Josef Cacek Assignee: Darran Lofthouse Elytron enforces existence of {{"#$REALM_NAME=...$"}} comment in property file referenced from properties-realms. When using legacy security and this line is missing, server starts without error. *Expected behavior:* Elytron's properties-realm *doesn't require* this comment. If the comment is present, it *may* verify if its content fits the realm name. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1285) NPE caused by forced flushing of unlinked path in stream mode

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-1285: ----------------------------------- Summary: NPE caused by forced flushing of unlinked path in stream mode Key: DROOLS-1285 URL: https://issues.jboss.org/browse/DROOLS-1285 Project: Drools Issue Type: Bug Components: core engine Reporter: Mario Fusco Assignee: Mario Fusco In stream mode it is necessary to enforce flushing of path memories. However doing this on an unlinked path is a waste of time and moreover can causes a NPE in presence of a subnetwork like the following: {code} java.lang.NullPointerException at org.drools.core.phreak.RuleNetworkEvaluator.deleteChildLeftTuple(RuleNetworkEvaluator.java:725) at org.drools.core.phreak.RuleNetworkEvaluator.unlinkAndDeleteChildLeftTuple(RuleNetworkEvaluator.java:718) at org.drools.core.phreak.PhreakJoinNode.doLeftDeletes(PhreakJoinNode.java:418) at org.drools.core.phreak.PhreakJoinNode.doNode(PhreakJoinNode.java:47) at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:519) at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:505) at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:341) at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:301) at org.drools.core.phreak.RuleNetworkEvaluator.doRiaNode(RuleNetworkEvaluator.java:573) at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:500) at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:341) at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:301) at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:136) at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:94) at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194) at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:73) at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:969) at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1311) at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1250) at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1356) at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1347) at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1328) {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6989) Java deadlock with IdleRemover thread

by Stefano Maestri (JIRA)

[ https://issues.jboss.org/browse/WFLY-6989?page=com.atlassian.jira.plugin.... ] Stefano Maestri resolved WFLY-6989. ----------------------------------- Resolution: Duplicate Issue [~simkam] is right. Closing as duplicate issue > Java deadlock with IdleRemover thread > ------------------------------------- > > Key: WFLY-6989 > URL: https://issues.jboss.org/browse/WFLY-6989 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 10.0.0.Final > Environment: Java 8 b102 64-bit on Linux > Using Oracle 12.c with Oracle thin client drivers. > Reporter: David Rothenberger > Assignee: Stefano Maestri > > We have had two Java deadlock issues involving the IdleRemover thread. > We are using the following datasource definition: > Data source definition: > {code:xml} > <datasource jndi-name="java:/EntomoNonTxDS" pool-name="EntomoNonTxDS" enabled="true" use-java-context="true"> > <connection-url>jdbc:oracle:thin:@//somehost:1541/somethingelse</connection-url> > <driver>ojdbc6.jar</driver> > <pool> > <max-pool-size>200</max-pool-size> > <allow-multiple-users>true</allow-multiple-users> > </pool> > <timeout> > <idle-timeout-minutes>5</idle-timeout-minutes> > </timeout> > <validation> > <validate-on-match>true</validate-on-match> > <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker"/> > <stale-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleStaleConnectionChecker"/> > <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter"/> > </validation> > </datasource> > {code} > The information from Java relevant to the deadlock: > {noformat} > Found one Java-level deadlock: > ============================= > "WorkflowMgr": > waiting for ownable synchronizer 0x00000002d37eb7f0, (a java.util.concurrent.locks.ReentrantLock$FairSync), > which is held by "IdleRemover" > "IdleRemover": > waiting to lock monitor 0x00007eff4c0a80e8 (object 0x00000002d280e6f0, a org.jboss.jca.core.connectionmanager.pool.strategy.PoolByCri), > which is held by "WorkflowMgr" > "WorkflowMgr": > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000002d37eb7f0> (a java.util.concurrent.locks.ReentrantLock$FairSync) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199) > at java.util.concurrent.locks.ReentrantLock$FairSync.lock(ReentrantLock.java:224) > at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285) > at org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover.internalRegisterPool(IdleRemover.java:184) > at org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover.registerPool(IdleRemover.java:166) > at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.initialize(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:184) > at org.jboss.jca.core.connectionmanager.pool.mcp.ManagedConnectionPoolFactory.init(ManagedConnectionPoolFactory.java:191) > at org.jboss.jca.core.connectionmanager.pool.mcp.ManagedConnectionPoolFactory.create(ManagedConnectionPoolFactory.java:173) > at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getManagedConnectionPool(AbstractPool.java:306) > - locked <0x00000002d280e6f0> (a org.jboss.jca.core.connectionmanager.pool.strategy.PoolByCri) > at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:590) > at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:590) > at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:429) > at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:747) > at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:162) > at org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:73) > ... > "IdleRemover": > at org.jboss.jca.core.connectionmanager.pool.AbstractPool.emptyManagedConnectionPool(AbstractPool.java:454) > - waiting to lock <0x00000002d280e6f0> (a org.jboss.jca.core.connectionmanager.pool.strategy.PoolByCri) > at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.removeIdleConnections(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:1034) > at org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover$IdleRemoverRunner.run(IdleRemover.java:275) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6989) Java deadlock with IdleRemover thread

by Martin Simka (JIRA)

[ https://issues.jboss.org/browse/WFLY-6989?page=com.atlassian.jira.plugin.... ] Martin Simka commented on WFLY-6989: ------------------------------------ this looks like JBJCA-1311 which is resolved in WildFly 10.1. > Java deadlock with IdleRemover thread > ------------------------------------- > > Key: WFLY-6989 > URL: https://issues.jboss.org/browse/WFLY-6989 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 10.0.0.Final > Environment: Java 8 b102 64-bit on Linux > Using Oracle 12.c with Oracle thin client drivers. > Reporter: David Rothenberger > Assignee: Stefano Maestri > > We have had two Java deadlock issues involving the IdleRemover thread. > We are using the following datasource definition: > Data source definition: > {code:xml} > <datasource jndi-name="java:/EntomoNonTxDS" pool-name="EntomoNonTxDS" enabled="true" use-java-context="true"> > <connection-url>jdbc:oracle:thin:@//somehost:1541/somethingelse</connection-url> > <driver>ojdbc6.jar</driver> > <pool> > <max-pool-size>200</max-pool-size> > <allow-multiple-users>true</allow-multiple-users> > </pool> > <timeout> > <idle-timeout-minutes>5</idle-timeout-minutes> > </timeout> > <validation> > <validate-on-match>true</validate-on-match> > <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker"/> > <stale-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleStaleConnectionChecker"/> > <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter"/> > </validation> > </datasource> > {code} > The information from Java relevant to the deadlock: > {noformat} > Found one Java-level deadlock: > ============================= > "WorkflowMgr": > waiting for ownable synchronizer 0x00000002d37eb7f0, (a java.util.concurrent.locks.ReentrantLock$FairSync), > which is held by "IdleRemover" > "IdleRemover": > waiting to lock monitor 0x00007eff4c0a80e8 (object 0x00000002d280e6f0, a org.jboss.jca.core.connectionmanager.pool.strategy.PoolByCri), > which is held by "WorkflowMgr" > "WorkflowMgr": > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000002d37eb7f0> (a java.util.concurrent.locks.ReentrantLock$FairSync) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199) > at java.util.concurrent.locks.ReentrantLock$FairSync.lock(ReentrantLock.java:224) > at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285) > at org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover.internalRegisterPool(IdleRemover.java:184) > at org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover.registerPool(IdleRemover.java:166) > at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.initialize(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:184) > at org.jboss.jca.core.connectionmanager.pool.mcp.ManagedConnectionPoolFactory.init(ManagedConnectionPoolFactory.java:191) > at org.jboss.jca.core.connectionmanager.pool.mcp.ManagedConnectionPoolFactory.create(ManagedConnectionPoolFactory.java:173) > at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getManagedConnectionPool(AbstractPool.java:306) > - locked <0x00000002d280e6f0> (a org.jboss.jca.core.connectionmanager.pool.strategy.PoolByCri) > at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:590) > at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:590) > at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:429) > at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:747) > at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:162) > at org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:73) > ... > "IdleRemover": > at org.jboss.jca.core.connectionmanager.pool.AbstractPool.emptyManagedConnectionPool(AbstractPool.java:454) > - waiting to lock <0x00000002d280e6f0> (a org.jboss.jca.core.connectionmanager.pool.strategy.PoolByCri) > at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.removeIdleConnections(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:1034) > at org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover$IdleRemoverRunner.run(IdleRemover.java:275) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6960) SFSB concurrent access timeout when the bean defines CDI producer for another SFSB

by Enrique González Martínez (JIRA)

[ https://issues.jboss.org/browse/WFLY-6960?page=com.atlassian.jira.plugin.... ] Enrique González Martínez commented on WFLY-6960: ------------------------------------------------- I think that what is happening is: when SF3Bean invokes SFBean1::foo, SFBean1 is instantiated and this bean joins the transaction. when SF3Bean invokes SFBean2::foo, SFBean2 is instantiated and during creation, it tries to instantiate the private member foo (in SFBean2) which depends on the producer method in SF1Bean. The problem is that during SFBean2 creation there is no transaction associated so when the producer method in SFBean1 is invoked (that method requires a transaction) it gets stuck trying to access the bean in {code}StatefulSessionSynchronizationInterceptor{code}. This means that SFBean1 is accessed by two different transactions which is not allowed by the interceptor. This interceptor has changed since wildfly 8.2.1 (the working version of the test case). > SFSB concurrent access timeout when the bean defines CDI producer for another SFSB > ---------------------------------------------------------------------------------- > > Key: WFLY-6960 > URL: https://issues.jboss.org/browse/WFLY-6960 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.0.0.Final, 10.1.0.CR1 > Reporter: Tomas Remes > Assignee: Enrique González Martínez > Attachments: test-case.zip > > > In the given scenario there are two calls to {{org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor#processInvocation}} in the same thread. In the first call the {{OwnableReentrantLock}} is obtained but it couldn't be reentered in the second call. This results to: > {noformat} > 14:54:21,184 ERROR [org.jboss.as.ejb3.invocation] (pool-2-thread-2) WFLYEJB0034: EJB Invocation failed on component SFBean1 for method public org.jboss.weld.tests.ejb.stateful.producer.Foo org.jboss.weld.tests.ejb.stateful.producer.SFBean1.produceString(): javax.ejb.ConcurrentAccessTimeoutException: WFLYEJB0228: EJB 3.1 FR 4.3.14.1 concurrent access timeout on SFBean1 - could not obtain lock within 5000 MILLISECONDS > at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:86) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) > at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64) > at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:65) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195) > at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73) > at org.jboss.weld.tests.ejb.stateful.producer.SFBean1$$$view5.produceString(Unknown Source) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:436) > at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:127) > at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) > at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) > at org.jboss.weld.tests.ejb.stateful.producer.SFBean1$Proxy$_$$_Weld$EnterpriseProxy$.produceString(Unknown Source) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78) > at org.jboss.weld.injection.producer.ProducerMethodProducer.produce(ProducerMethodProducer.java:99) > at org.jboss.weld.injection.producer.AbstractMemberProducer.produce(AbstractMemberProducer.java:161) > at org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:181) > at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:70) > at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101) > at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50) > at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:742) > at org.jboss.weld.manager.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:842) > at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:92) > at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:378) > at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:389) > at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:71) > at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) > at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:73) > at org.jboss.weld.injection.producer.ejb.SessionBeanInjectionTarget.inject(SessionBeanInjectionTarget.java:140) > at org.jboss.as.weld.injection.WeldInjectionContext.inject(WeldInjectionContext.java:39) > at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:51) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.weld.ejb.Jsr299BindingsCreateInterceptor.processInvocation(Jsr299BindingsCreateInterceptor.java:100) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:263) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.notSupported(CMTTxInterceptor.java:308) > at org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.processInvocation(LifecycleCMTTxInterceptor.java:62) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.jpa.interceptor.SFSBPreCreateInterceptor.processInvocation(SFSBPreCreateInterceptor.java:47) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161) > at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:150) > at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:75) > at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134) > at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:145) > at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:75) > at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88) > at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createInstance(StatefulSessionComponent.java:135) > at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createInstance(StatefulSessionComponent.java:75) > at org.jboss.as.ejb3.cache.simple.SimpleCache.create(SimpleCache.java:118) > at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238) > at org.jboss.as.weld.ejb.StatefulSessionObjectReferenceImpl.<init>(StatefulSessionObjectReferenceImpl.java:70) > at org.jboss.as.weld.services.bootstrap.WeldEjbServices.resolveEjb(WeldEjbServices.java:53) > at org.jboss.weld.bean.SessionBean.createReference(SessionBean.java:230) > at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.<init>(EnterpriseBeanProxyMethodHandler.java:83) > at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.<init>(EnterpriseBeanProxyMethodHandler.java:63) > at org.jboss.weld.injection.producer.ejb.SessionBeanProxyInstantiator.createEnterpriseTargetBeanInstance(SessionBeanProxyInstantiator.java:80) > at org.jboss.weld.injection.producer.ejb.SessionBeanProxyInstantiator.newInstance(SessionBeanProxyInstantiator.java:61) > at org.jboss.weld.bean.SessionBean.create(SessionBean.java:149) > at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96) > at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101) > at org.jboss.weld.bean.ContextualInstanceStrategy$CachingContextualInstanceStrategy.get(ContextualInstanceStrategy.java:178) > at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50) > at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:99) > at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125) > at org.jboss.weld.tests.ejb.stateful.producer.SFBean2$Proxy$_$$_WeldClientProxy.foo(Unknown Source) > at org.jboss.weld.tests.ejb.stateful.producer.SFBean3.ping(SFBean3.java:19) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) > at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82) > at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) > at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:57) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:125) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) > at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64) > at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:65) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195) > at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73) > at org.jboss.weld.tests.ejb.stateful.producer.SFBean3$$$view6.ping(Unknown Source) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:436) > at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:127) > at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) > at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) > at org.jboss.weld.tests.ejb.stateful.producer.SFBean3$Proxy$_$$_Weld$EnterpriseProxy$.ping(Unknown Source) > at org.jboss.weld.tests.ejb.stateful.producer.SFBean3$Proxy$_$$_WeldClientProxy.ping(Unknown Source) > at org.jboss.weld.tests.ejb.stateful.producer.ConcurrentAccessTest.test(ConcurrentAccessTest.java:31) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6924) driver-module-name not writable through the cli

by Stefano Maestri (JIRA)

[ https://issues.jboss.org/browse/WFLY-6924?page=com.atlassian.jira.plugin.... ] Stefano Maestri commented on WFLY-6924: --------------------------------------- All attributes of driver resource have always been read-only. > driver-module-name not writable through the cli > ----------------------------------------------- > > Key: WFLY-6924 > URL: https://issues.jboss.org/browse/WFLY-6924 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 10.0.0.Final > Reporter: trippstowe > Assignee: Stefano Maestri > Priority: Minor > > this used to work with previous versions > /subsystem=datasources/jdbc-driver=mysql/:write-attribute(name=driver-module-name,value=com.mysql.jdbc) > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0048: Attribute driver-module-name is not writable", > "rolled-back" => true > } -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6960) SFSB concurrent access timeout when the bean defines CDI producer for another SFSB

by Enrique González Martínez (JIRA)

[ https://issues.jboss.org/browse/WFLY-6960?page=com.atlassian.jira.plugin.... ] Enrique González Martínez edited comment on WFLY-6960 at 9/14/16 6:13 AM: -------------------------------------------------------------------------- Adding two test case. It happens the same in both cases. Just need to be deployed and invoke the servlets. was (Author: elguardian): Adding two test case. It happens the same in both cases. > SFSB concurrent access timeout when the bean defines CDI producer for another SFSB > ---------------------------------------------------------------------------------- > > Key: WFLY-6960 > URL: https://issues.jboss.org/browse/WFLY-6960 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.0.0.Final, 10.1.0.CR1 > Reporter: Tomas Remes > Assignee: Enrique González Martínez > Attachments: test-case.zip > > > In the given scenario there are two calls to {{org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor#processInvocation}} in the same thread. In the first call the {{OwnableReentrantLock}} is obtained but it couldn't be reentered in the second call. This results to: > {noformat} > 14:54:21,184 ERROR [org.jboss.as.ejb3.invocation] (pool-2-thread-2) WFLYEJB0034: EJB Invocation failed on component SFBean1 for method public org.jboss.weld.tests.ejb.stateful.producer.Foo org.jboss.weld.tests.ejb.stateful.producer.SFBean1.produceString(): javax.ejb.ConcurrentAccessTimeoutException: WFLYEJB0228: EJB 3.1 FR 4.3.14.1 concurrent access timeout on SFBean1 - could not obtain lock within 5000 MILLISECONDS > at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:86) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) > at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64) > at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:65) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195) > at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73) > at org.jboss.weld.tests.ejb.stateful.producer.SFBean1$$$view5.produceString(Unknown Source) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:436) > at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:127) > at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) > at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) > at org.jboss.weld.tests.ejb.stateful.producer.SFBean1$Proxy$_$$_Weld$EnterpriseProxy$.produceString(Unknown Source) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78) > at org.jboss.weld.injection.producer.ProducerMethodProducer.produce(ProducerMethodProducer.java:99) > at org.jboss.weld.injection.producer.AbstractMemberProducer.produce(AbstractMemberProducer.java:161) > at org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:181) > at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:70) > at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101) > at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50) > at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:742) > at org.jboss.weld.manager.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:842) > at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:92) > at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:378) > at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:389) > at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:71) > at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) > at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:73) > at org.jboss.weld.injection.producer.ejb.SessionBeanInjectionTarget.inject(SessionBeanInjectionTarget.java:140) > at org.jboss.as.weld.injection.WeldInjectionContext.inject(WeldInjectionContext.java:39) > at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:51) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.weld.ejb.Jsr299BindingsCreateInterceptor.processInvocation(Jsr299BindingsCreateInterceptor.java:100) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:263) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.notSupported(CMTTxInterceptor.java:308) > at org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.processInvocation(LifecycleCMTTxInterceptor.java:62) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.jpa.interceptor.SFSBPreCreateInterceptor.processInvocation(SFSBPreCreateInterceptor.java:47) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161) > at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:150) > at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:75) > at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134) > at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:145) > at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:75) > at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88) > at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createInstance(StatefulSessionComponent.java:135) > at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createInstance(StatefulSessionComponent.java:75) > at org.jboss.as.ejb3.cache.simple.SimpleCache.create(SimpleCache.java:118) > at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238) > at org.jboss.as.weld.ejb.StatefulSessionObjectReferenceImpl.<init>(StatefulSessionObjectReferenceImpl.java:70) > at org.jboss.as.weld.services.bootstrap.WeldEjbServices.resolveEjb(WeldEjbServices.java:53) > at org.jboss.weld.bean.SessionBean.createReference(SessionBean.java:230) > at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.<init>(EnterpriseBeanProxyMethodHandler.java:83) > at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.<init>(EnterpriseBeanProxyMethodHandler.java:63) > at org.jboss.weld.injection.producer.ejb.SessionBeanProxyInstantiator.createEnterpriseTargetBeanInstance(SessionBeanProxyInstantiator.java:80) > at org.jboss.weld.injection.producer.ejb.SessionBeanProxyInstantiator.newInstance(SessionBeanProxyInstantiator.java:61) > at org.jboss.weld.bean.SessionBean.create(SessionBean.java:149) > at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96) > at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101) > at org.jboss.weld.bean.ContextualInstanceStrategy$CachingContextualInstanceStrategy.get(ContextualInstanceStrategy.java:178) > at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50) > at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:99) > at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125) > at org.jboss.weld.tests.ejb.stateful.producer.SFBean2$Proxy$_$$_WeldClientProxy.foo(Unknown Source) > at org.jboss.weld.tests.ejb.stateful.producer.SFBean3.ping(SFBean3.java:19) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) > at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82) > at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) > at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:57) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:125) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) > at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64) > at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:65) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195) > at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73) > at org.jboss.weld.tests.ejb.stateful.producer.SFBean3$$$view6.ping(Unknown Source) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:436) > at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:127) > at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) > at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) > at org.jboss.weld.tests.ejb.stateful.producer.SFBean3$Proxy$_$$_Weld$EnterpriseProxy$.ping(Unknown Source) > at org.jboss.weld.tests.ejb.stateful.producer.SFBean3$Proxy$_$$_WeldClientProxy.ping(Unknown Source) > at org.jboss.weld.tests.ejb.stateful.producer.ConcurrentAccessTest.test(ConcurrentAccessTest.java:31) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6960) SFSB concurrent access timeout when the bean defines CDI producer for another SFSB

by Enrique González Martínez (JIRA)

[ https://issues.jboss.org/browse/WFLY-6960?page=com.atlassian.jira.plugin.... ] Enrique González Martínez updated WFLY-6960: -------------------------------------------- Attachment: test-case.zip Adding two test case. It happens the same in both cases. > SFSB concurrent access timeout when the bean defines CDI producer for another SFSB > ---------------------------------------------------------------------------------- > > Key: WFLY-6960 > URL: https://issues.jboss.org/browse/WFLY-6960 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.0.0.Final, 10.1.0.CR1 > Reporter: Tomas Remes > Assignee: Enrique González Martínez > Attachments: test-case.zip > > > In the given scenario there are two calls to {{org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor#processInvocation}} in the same thread. In the first call the {{OwnableReentrantLock}} is obtained but it couldn't be reentered in the second call. This results to: > {noformat} > 14:54:21,184 ERROR [org.jboss.as.ejb3.invocation] (pool-2-thread-2) WFLYEJB0034: EJB Invocation failed on component SFBean1 for method public org.jboss.weld.tests.ejb.stateful.producer.Foo org.jboss.weld.tests.ejb.stateful.producer.SFBean1.produceString(): javax.ejb.ConcurrentAccessTimeoutException: WFLYEJB0228: EJB 3.1 FR 4.3.14.1 concurrent access timeout on SFBean1 - could not obtain lock within 5000 MILLISECONDS > at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:86) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) > at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64) > at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:65) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195) > at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73) > at org.jboss.weld.tests.ejb.stateful.producer.SFBean1$$$view5.produceString(Unknown Source) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:436) > at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:127) > at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) > at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) > at org.jboss.weld.tests.ejb.stateful.producer.SFBean1$Proxy$_$$_Weld$EnterpriseProxy$.produceString(Unknown Source) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) > at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78) > at org.jboss.weld.injection.producer.ProducerMethodProducer.produce(ProducerMethodProducer.java:99) > at org.jboss.weld.injection.producer.AbstractMemberProducer.produce(AbstractMemberProducer.java:161) > at org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:181) > at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:70) > at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101) > at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50) > at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:742) > at org.jboss.weld.manager.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:842) > at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:92) > at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:378) > at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:389) > at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:71) > at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) > at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:73) > at org.jboss.weld.injection.producer.ejb.SessionBeanInjectionTarget.inject(SessionBeanInjectionTarget.java:140) > at org.jboss.as.weld.injection.WeldInjectionContext.inject(WeldInjectionContext.java:39) > at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:51) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.weld.ejb.Jsr299BindingsCreateInterceptor.processInvocation(Jsr299BindingsCreateInterceptor.java:100) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:263) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.notSupported(CMTTxInterceptor.java:308) > at org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.processInvocation(LifecycleCMTTxInterceptor.java:62) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.jpa.interceptor.SFSBPreCreateInterceptor.processInvocation(SFSBPreCreateInterceptor.java:47) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161) > at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:150) > at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:75) > at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134) > at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:145) > at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:75) > at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88) > at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createInstance(StatefulSessionComponent.java:135) > at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createInstance(StatefulSessionComponent.java:75) > at org.jboss.as.ejb3.cache.simple.SimpleCache.create(SimpleCache.java:118) > at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238) > at org.jboss.as.weld.ejb.StatefulSessionObjectReferenceImpl.<init>(StatefulSessionObjectReferenceImpl.java:70) > at org.jboss.as.weld.services.bootstrap.WeldEjbServices.resolveEjb(WeldEjbServices.java:53) > at org.jboss.weld.bean.SessionBean.createReference(SessionBean.java:230) > at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.<init>(EnterpriseBeanProxyMethodHandler.java:83) > at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.<init>(EnterpriseBeanProxyMethodHandler.java:63) > at org.jboss.weld.injection.producer.ejb.SessionBeanProxyInstantiator.createEnterpriseTargetBeanInstance(SessionBeanProxyInstantiator.java:80) > at org.jboss.weld.injection.producer.ejb.SessionBeanProxyInstantiator.newInstance(SessionBeanProxyInstantiator.java:61) > at org.jboss.weld.bean.SessionBean.create(SessionBean.java:149) > at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96) > at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101) > at org.jboss.weld.bean.ContextualInstanceStrategy$CachingContextualInstanceStrategy.get(ContextualInstanceStrategy.java:178) > at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50) > at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:99) > at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125) > at org.jboss.weld.tests.ejb.stateful.producer.SFBean2$Proxy$_$$_WeldClientProxy.foo(Unknown Source) > at org.jboss.weld.tests.ejb.stateful.producer.SFBean3.ping(SFBean3.java:19) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) > at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82) > at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) > at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:57) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:125) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) > at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64) > at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:65) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195) > at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73) > at org.jboss.weld.tests.ejb.stateful.producer.SFBean3$$$view6.ping(Unknown Source) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:436) > at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:127) > at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) > at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) > at org.jboss.weld.tests.ejb.stateful.producer.SFBean3$Proxy$_$$_Weld$EnterpriseProxy$.ping(Unknown Source) > at org.jboss.weld.tests.ejb.stateful.producer.SFBean3$Proxy$_$$_WeldClientProxy.ping(Unknown Source) > at org.jboss.weld.tests.ejb.stateful.producer.ConcurrentAccessTest.test(ConcurrentAccessTest.java:31) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6924) driver-module-name not writable through the cli

by Martin Simka (JIRA)

[ https://issues.jboss.org/browse/WFLY-6924?page=com.atlassian.jira.plugin.... ] Martin Simka commented on WFLY-6924: ------------------------------------ it seems to me that driver attributes have always been read-only. Oldest version I checked is JBoss AS 7.1.1 {noformat:title=JBoss AS 7.1.1} "driver-module-name" => { "description" => "The name of the module from which the driver was loaded, if it was loaded from the module path", "type" => STRING, "required" => false, "nillable" => true, "access-type" => "read-only", "storage" => "configuration" } {noformat} > driver-module-name not writable through the cli > ----------------------------------------------- > > Key: WFLY-6924 > URL: https://issues.jboss.org/browse/WFLY-6924 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 10.0.0.Final > Reporter: trippstowe > Assignee: Stefano Maestri > Priority: Minor > > this used to work with previous versions > /subsystem=datasources/jdbc-driver=mysql/:write-attribute(name=driver-module-name,value=com.mysql.jdbc) > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0048: Attribute driver-module-name is not writable", > "rolled-back" => true > } -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7098) Double check parallel boot and ApplicationSecurityDomain definitions are compatible

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7098?page=com.atlassian.jira.plugin.... ] Darran Lofthouse resolved WFLY-7098. ------------------------------------ Resolution: Rejected As described by Brian, the stages are sufficiently independent to ensure subsystem stages are complete before the deployers begin. > Double check parallel boot and ApplicationSecurityDomain definitions are compatible > ----------------------------------------------------------------------------------- > > Key: WFLY-7098 > URL: https://issues.jboss.org/browse/WFLY-7098 > Project: WildFly > Issue Type: Task > Components: EJB, Web (Undertow) > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 11.0.0.Alpha1 > > > Need to check there is no option for parallel boot to start deploying deployment before the full management model has been processed to the point all known ApplicationSecurityDomain definitions are known for both EJB and Undertow. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1783) CLI GUI throws exception when editing boolean attribute with expression

by Ivo Hrádek (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1783?page=com.atlassian.jira.plugi... ] Ivo Hrádek reassigned WFCORE-1783: ---------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1789 Assignee: Ivo Hrádek (was: Alexey Loubyansky) > CLI GUI throws exception when editing boolean attribute with expression > ----------------------------------------------------------------------- > > Key: WFCORE-1783 > URL: https://issues.jboss.org/browse/WFCORE-1783 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: John Mazzitelli > Assignee: Ivo Hrádek > Priority: Minor > > When in the CLI GUI, if you try to edit a boolean attribute whose current value is an expression then an exception is thrown and you can't edit it - the popup dialog is really small and blank. > See "Steps to Reproduce" for replication procedures. > Here's the exception: > java.lang.IllegalArgumentException > at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:66) > at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:262) > at org.jboss.as.cli.gui.OperationDialog$RequestProp.setInputComponentValue(OperationDialog.java:428) > at org.jboss.as.cli.gui.OperationDialog$RequestProp.<init>(OperationDialog.java:336) > at org.jboss.as.cli.gui.OperationDialog.setProps(OperationDialog.java:157) > at org.jboss.as.cli.gui.OperationDialog.<init>(OperationDialog.java:73) > at org.jboss.as.cli.gui.OperationMenu$OperationAction.actionPerformed(OperationMenu.java:152) > at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2022) > at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2348) > at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402) > at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259) > at javax.swing.AbstractButton.doClick(AbstractButton.java:376) > at javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:833) > at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:877) > at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:289) > at java.awt.Component.processMouseEvent(Component.java:6535) > at javax.swing.JComponent.processMouseEvent(JComponent.java:3324) > at java.awt.Component.processEvent(Component.java:6300) > at java.awt.Container.processEvent(Container.java:2236) > at java.awt.Component.dispatchEventImpl(Component.java:4891) > at java.awt.Container.dispatchEventImpl(Container.java:2294) > at java.awt.Component.dispatchEvent(Component.java:4713) > at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4888) > at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4525) > at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4466) > at java.awt.Container.dispatchEventImpl(Container.java:2280) > at java.awt.Window.dispatchEventImpl(Window.java:2750) > at java.awt.Component.dispatchEvent(Component.java:4713) > at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758) > at java.awt.EventQueue.access$500(EventQueue.java:97) > at java.awt.EventQueue$3.run(EventQueue.java:709) > at java.awt.EventQueue$3.run(EventQueue.java:703) > at java.security.AccessController.doPrivileged(Native Method) > at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76) > at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86) > at java.awt.EventQueue$4.run(EventQueue.java:731) > at java.awt.EventQueue$4.run(EventQueue.java:729) > at java.security.AccessController.doPrivileged(Native Method) > at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76) > at java.awt.EventQueue.dispatchEvent(EventQueue.java:728) > at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201) > at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) > at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) > at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7071) Changing default-realm of Elytron security-domain through CLI can put the server configuration to wrong state

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7071?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-7071: ---------------------------------------- +1 I think a write handler that validates here should be the main thing. > Changing default-realm of Elytron security-domain through CLI can put the server configuration to wrong state > ------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7071 > URL: https://issues.jboss.org/browse/WFLY-7071 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Jan Kalina > > Values of write-attribute operation for default-realm of Elytron security-domain are not checked. It means that CLI allows users to set application server to wrong state. The same happens if realm, which is considered as default-realm, is removed from used security-domain realms. CLI should deny write attribute operation with wrong value (in the same way as it works for another security-domain attributes). > After reload, server is not started and following logs occur in console: > {code} > ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 25) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("security-domain" => "ApplicationDomain") > ]) - failure description: "WFLYELY00013: The default_realm 'WrongRealm' is not in the list or realms referenced by this domain." > ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) "WFLYCTL0193: Failed executing subsystem elytron boot operations" > ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("parallel-subsystem-boot") failed - address: ([]) - failure description: "\"WFLYCTL0193: Failed executing subsystem elytron boot operations\"" > FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7071) Changing default-realm of Elytron security-domain through CLI can put the server configuration to wrong state

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7071?page=com.atlassian.jira.plugin.... ] Jan Kalina commented on WFLY-7071: ---------------------------------- i think what we need is validation on write attribute handler - what should be discussed here? > Changing default-realm of Elytron security-domain through CLI can put the server configuration to wrong state > ------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7071 > URL: https://issues.jboss.org/browse/WFLY-7071 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Jan Kalina > > Values of write-attribute operation for default-realm of Elytron security-domain are not checked. It means that CLI allows users to set application server to wrong state. The same happens if realm, which is considered as default-realm, is removed from used security-domain realms. CLI should deny write attribute operation with wrong value (in the same way as it works for another security-domain attributes). > After reload, server is not started and following logs occur in console: > {code} > ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 25) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("security-domain" => "ApplicationDomain") > ]) - failure description: "WFLYELY00013: The default_realm 'WrongRealm' is not in the list or realms referenced by this domain." > ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) "WFLYCTL0193: Failed executing subsystem elytron boot operations" > ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("parallel-subsystem-boot") failed - address: ([]) - failure description: "\"WFLYCTL0193: Failed executing subsystem elytron boot operations\"" > FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7103) In elytron security domain add operation the realms attribute is not marked as required even though it is not nillable and has no default value with no default value

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7103?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-7103: ---------------------------------------- In a rare twist of engineering asking for a bug report to have a higher priority than QE ask for I am going to raise this one back to major ;-) The reason being is the security-domain resource is one of the most central resources that will be used with Elytron so accuracy of the model description from the outset is going to be important. [~honza889] Can you please double check this one? I think the approach changed a bit on this one whilst deciding how to handle the default realm which you already have an issue for. > In elytron security domain add operation the realms attribute is not marked as required even though it is not nillable and has no default value with no default value > --------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7103 > URL: https://issues.jboss.org/browse/WFLY-7103 > Project: WildFly > Issue Type: Bug > Components: Domain Management, Security > Reporter: Radim Hatlapatka > Assignee: Jan Kalina > > When reading description of the {{add}} operation for elytron security domain => {{/subsystem=elytron/security-domain=test-domain:read-operation-description(name=add)}}, the realms attribute has set required to false. Still it needs to be defined as part of {{add}} operation as it is not nillable. > If it is really mandatory, it should be marked as required. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7103) In elytron security domain add operation the realms attribute is not marked as required even though it is not nillable and has no default value with no default value

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7103?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-7103: ----------------------------------- Priority: Major (was: Minor) > In elytron security domain add operation the realms attribute is not marked as required even though it is not nillable and has no default value with no default value > --------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7103 > URL: https://issues.jboss.org/browse/WFLY-7103 > Project: WildFly > Issue Type: Bug > Components: Domain Management, Security > Reporter: Radim Hatlapatka > Assignee: Jan Kalina > > When reading description of the {{add}} operation for elytron security domain => {{/subsystem=elytron/security-domain=test-domain:read-operation-description(name=add)}}, the realms attribute has set required to false. Still it needs to be defined as part of {{add}} operation as it is not nillable. > If it is really mandatory, it should be marked as required. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7103) In elytron security domain add operation the realms attribute is not marked as required even though it is not nillable and has no default value with no default value

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7103?page=com.atlassian.jira.plugin.... ] Darran Lofthouse reassigned WFLY-7103: -------------------------------------- Assignee: Jan Kalina (was: Darran Lofthouse) > In elytron security domain add operation the realms attribute is not marked as required even though it is not nillable and has no default value with no default value > --------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7103 > URL: https://issues.jboss.org/browse/WFLY-7103 > Project: WildFly > Issue Type: Bug > Components: Domain Management, Security > Reporter: Radim Hatlapatka > Assignee: Jan Kalina > Priority: Minor > > When reading description of the {{add}} operation for elytron security domain => {{/subsystem=elytron/security-domain=test-domain:read-operation-description(name=add)}}, the realms attribute has set required to false. Still it needs to be defined as part of {{add}} operation as it is not nillable. > If it is really mandatory, it should be marked as required. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7103) In elytron security domain add operation the realms attribute is not marked as required even though it is not nillable and has no default value with no default value

by Radim Hatlapatka (JIRA)

Radim Hatlapatka created WFLY-7103: -------------------------------------- Summary: In elytron security domain add operation the realms attribute is not marked as required even though it is not nillable and has no default value with no default value Key: WFLY-7103 URL: https://issues.jboss.org/browse/WFLY-7103 Project: WildFly Issue Type: Bug Components: Domain Management, Security Reporter: Radim Hatlapatka Assignee: Brian Stansberry Priority: Minor When reading description of the {{add}} operation for elytron security domain => {{/subsystem=elytron/security-domain=test-domain:read-operation-description(name=add)}}, the realms attribute has set required to false. Still it needs to be defined as part of {{add}} operation as it is not nillable. If it is really mandatory, it should be marked as required. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7103) In elytron security domain add operation the realms attribute is not marked as required even though it is not nillable and has no default value with no default value

by Radim Hatlapatka (JIRA)

[ https://issues.jboss.org/browse/WFLY-7103?page=com.atlassian.jira.plugin.... ] Radim Hatlapatka reassigned WFLY-7103: -------------------------------------- Assignee: Darran Lofthouse (was: Brian Stansberry) > In elytron security domain add operation the realms attribute is not marked as required even though it is not nillable and has no default value with no default value > --------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7103 > URL: https://issues.jboss.org/browse/WFLY-7103 > Project: WildFly > Issue Type: Bug > Components: Domain Management, Security > Reporter: Radim Hatlapatka > Assignee: Darran Lofthouse > Priority: Minor > > When reading description of the {{add}} operation for elytron security domain => {{/subsystem=elytron/security-domain=test-domain:read-operation-description(name=add)}}, the realms attribute has set required to false. Still it needs to be defined as part of {{add}} operation as it is not nillable. > If it is really mandatory, it should be marked as required. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7102) Allow subsystems to register their context handlers to the management endpoint

by Tristan Tarrant (JIRA)

Tristan Tarrant created WFLY-7102: ------------------------------------- Summary: Allow subsystems to register their context handlers to the management endpoint Key: WFLY-7102 URL: https://issues.jboss.org/browse/WFLY-7102 Project: WildFly Issue Type: Feature Request Components: Domain Management Reporter: Tristan Tarrant Assignee: Brian Stansberry For layered products, we would like to be able to register custom handlers to the management endpoint (e.g. for exposing health-check URLs) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1793) add-content operation fails to overwrite existing content with overwrite=true set when passing content by file path

by Michal Jurc (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1793?page=com.atlassian.jira.plugi... ] Michal Jurc updated WFCORE-1793: -------------------------------- Description: Upon overwriting content in managed exploded deployments on wildfly-core, the following errors are produced: {{CLI}} {code}[standalone@localhost:9990 /] deploy /home/mjurc/testing/eap7-204/jboss-kitchensink-ear.ear [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:undeploy {"outcome" => "success"} [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:explode {"outcome" => "success"} [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:deploy {"outcome" => "success"} [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:add-content(content=[{path=/home/mjurc/testing/eap7-204/test.txt, target-path=test.txt}], overwrite=true) { "outcome" => "failed", "failure-description" => "org.jboss.as.repository.ExplodedContentException: WFLYDR0021: Error updating content of exploded deployment", "rolled-back" => true } [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:add-content(content=[{path=/home/mjurc/testing/eap7-204/test.txt, target-path=test.txt}], overwrite=false) { "outcome" => "failed", "failure-description" => "org.jboss.as.repository.ExplodedContentException: WFLYDR0021: Error updating content of exploded deployment", "rolled-back" => true } [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:add-content(content=[{path=/home/mjurc/testing/eap7-204/test.txt, target-path=test.txt}]) { "outcome" => "failed", "failure-description" => "org.jboss.as.repository.ExplodedContentException: WFLYDR0021: Error updating content of exploded deployment", "rolled-back" => true }{code} {{Server}} {code}09:41:36,029 WARN [org.jboss.as.repository] (management-handler-thread - 5) java.nio.file.FileAlreadyExistsException: /home/mjurc/testing/wildfly-core/build/target/wildfly-core-3.0.0.Alpha8-SNAPSHOT/standalone/data/content/content7797527203290314566/content/test.txt 09:45:27,505 WARN [org.jboss.as.repository] (management-handler-thread - 12) java.nio.file.FileAlreadyExistsException: /home/mjurc/testing/wildfly-core/build/target/wildfly-core-3.0.0.Alpha8-SNAPSHOT/standalone/data/content/content721393778736298367/content/test.txt 09:45:36,352 WARN [org.jboss.as.repository] (management-handler-thread - 10) java.nio.file.FileAlreadyExistsException: /home/mjurc/testing/wildfly-core/build/target/wildfly-core-3.0.0.Alpha8-SNAPSHOT/standalone/data/content/content344811471223714239/content/test.txt{code} This issue does not seem to arise when the content is passed to the server by input stream index. was: Upon overwriting content in managed exploded deployments on wildfly-core, the following errors are produced: {{CLI}} {code}[standalone@localhost:9990 /] deploy /home/mjurc/testing/eap7-204/jboss-kitchensink-ear.ear [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:undeploy {"outcome" => "success"} [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:explode {"outcome" => "success"} [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:deploy {"outcome" => "success"} [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:add-content(content=[{path=/home/mjurc/testing/eap7-204/test.txt, target-path=test.txt}], overwrite=true) { "outcome" => "failed", "failure-description" => "org.jboss.as.repository.ExplodedContentException: WFLYDR0021: Error updating content of exploded deployment", "rolled-back" => true } [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:add-content(content=[{path=/home/mjurc/testing/eap7-204/test.txt, target-path=test.txt}], overwrite=false) { "outcome" => "failed", "failure-description" => "org.jboss.as.repository.ExplodedContentException: WFLYDR0021: Error updating content of exploded deployment", "rolled-back" => true } [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:add-content(content=[{path=/home/mjurc/testing/eap7-204/test.txt, target-path=test.txt}]) { "outcome" => "failed", "failure-description" => "org.jboss.as.repository.ExplodedContentException: WFLYDR0021: Error updating content of exploded deployment", "rolled-back" => true }{code} {{Server}} {code}09:41:36,029 WARN [org.jboss.as.repository] (management-handler-thread - 5) java.nio.file.FileAlreadyExistsException: /home/mjurc/testing/wildfly-core/build/target/wildfly-core-3.0.0.Alpha8-SNAPSHOT/standalone/data/content/content7797527203290314566/content/test.txt 09:45:27,505 WARN [org.jboss.as.repository] (management-handler-thread - 12) java.nio.file.FileAlreadyExistsException: /home/mjurc/testing/wildfly-core/build/target/wildfly-core-3.0.0.Alpha8-SNAPSHOT/standalone/data/content/content721393778736298367/content/test.txt 09:45:36,352 WARN [org.jboss.as.repository] (management-handler-thread - 10) java.nio.file.FileAlreadyExistsException: /home/mjurc/testing/wildfly-core/build/target/wildfly-core-3.0.0.Alpha8-SNAPSHOT/standalone/data/content/content344811471223714239/content/test.txt{code} > add-content operation fails to overwrite existing content with overwrite=true set when passing content by file path > ------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1793 > URL: https://issues.jboss.org/browse/WFCORE-1793 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Alpha8 > Reporter: Michal Jurc > Assignee: ehsavoie Hugonnet > > Upon overwriting content in managed exploded deployments on wildfly-core, the following errors are produced: > {{CLI}} > {code}[standalone@localhost:9990 /] deploy /home/mjurc/testing/eap7-204/jboss-kitchensink-ear.ear > [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:undeploy > {"outcome" => "success"} > [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:explode > {"outcome" => "success"} > [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:deploy > {"outcome" => "success"} > [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:add-content(content=[{path=/home/mjurc/testing/eap7-204/test.txt, target-path=test.txt}], overwrite=true) > { > "outcome" => "failed", > "failure-description" => "org.jboss.as.repository.ExplodedContentException: WFLYDR0021: Error updating content of exploded deployment", > "rolled-back" => true > } > [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:add-content(content=[{path=/home/mjurc/testing/eap7-204/test.txt, target-path=test.txt}], overwrite=false) > { > "outcome" => "failed", > "failure-description" => "org.jboss.as.repository.ExplodedContentException: WFLYDR0021: Error updating content of exploded deployment", > "rolled-back" => true > } > [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:add-content(content=[{path=/home/mjurc/testing/eap7-204/test.txt, target-path=test.txt}]) > { > "outcome" => "failed", > "failure-description" => "org.jboss.as.repository.ExplodedContentException: WFLYDR0021: Error updating content of exploded deployment", > "rolled-back" => true > }{code} > {{Server}} > {code}09:41:36,029 WARN [org.jboss.as.repository] (management-handler-thread - 5) java.nio.file.FileAlreadyExistsException: /home/mjurc/testing/wildfly-core/build/target/wildfly-core-3.0.0.Alpha8-SNAPSHOT/standalone/data/content/content7797527203290314566/content/test.txt > 09:45:27,505 WARN [org.jboss.as.repository] (management-handler-thread - 12) java.nio.file.FileAlreadyExistsException: /home/mjurc/testing/wildfly-core/build/target/wildfly-core-3.0.0.Alpha8-SNAPSHOT/standalone/data/content/content721393778736298367/content/test.txt > 09:45:36,352 WARN [org.jboss.as.repository] (management-handler-thread - 10) java.nio.file.FileAlreadyExistsException: /home/mjurc/testing/wildfly-core/build/target/wildfly-core-3.0.0.Alpha8-SNAPSHOT/standalone/data/content/content344811471223714239/content/test.txt{code} > This issue does not seem to arise when the content is passed to the server by input stream index. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1793) add-content operation fails to overwrite existing content with overwrite=true set when passing content by file path

by Michal Jurc (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1793?page=com.atlassian.jira.plugi... ] Michal Jurc updated WFCORE-1793: -------------------------------- Summary: add-content operation fails to overwrite existing content with overwrite=true set when passing content by file path (was: add-content operation fails to overwrite existing content with overwrite=true set) > add-content operation fails to overwrite existing content with overwrite=true set when passing content by file path > ------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1793 > URL: https://issues.jboss.org/browse/WFCORE-1793 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Alpha8 > Reporter: Michal Jurc > Assignee: ehsavoie Hugonnet > > Upon overwriting content in managed exploded deployments on wildfly-core, the following errors are produced: > {{CLI}} > {code}[standalone@localhost:9990 /] deploy /home/mjurc/testing/eap7-204/jboss-kitchensink-ear.ear > [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:undeploy > {"outcome" => "success"} > [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:explode > {"outcome" => "success"} > [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:deploy > {"outcome" => "success"} > [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:add-content(content=[{path=/home/mjurc/testing/eap7-204/test.txt, target-path=test.txt}], overwrite=true) > { > "outcome" => "failed", > "failure-description" => "org.jboss.as.repository.ExplodedContentException: WFLYDR0021: Error updating content of exploded deployment", > "rolled-back" => true > } > [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:add-content(content=[{path=/home/mjurc/testing/eap7-204/test.txt, target-path=test.txt}], overwrite=false) > { > "outcome" => "failed", > "failure-description" => "org.jboss.as.repository.ExplodedContentException: WFLYDR0021: Error updating content of exploded deployment", > "rolled-back" => true > } > [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:add-content(content=[{path=/home/mjurc/testing/eap7-204/test.txt, target-path=test.txt}]) > { > "outcome" => "failed", > "failure-description" => "org.jboss.as.repository.ExplodedContentException: WFLYDR0021: Error updating content of exploded deployment", > "rolled-back" => true > }{code} > {{Server}} > {code}09:41:36,029 WARN [org.jboss.as.repository] (management-handler-thread - 5) java.nio.file.FileAlreadyExistsException: /home/mjurc/testing/wildfly-core/build/target/wildfly-core-3.0.0.Alpha8-SNAPSHOT/standalone/data/content/content7797527203290314566/content/test.txt > 09:45:27,505 WARN [org.jboss.as.repository] (management-handler-thread - 12) java.nio.file.FileAlreadyExistsException: /home/mjurc/testing/wildfly-core/build/target/wildfly-core-3.0.0.Alpha8-SNAPSHOT/standalone/data/content/content721393778736298367/content/test.txt > 09:45:36,352 WARN [org.jboss.as.repository] (management-handler-thread - 10) java.nio.file.FileAlreadyExistsException: /home/mjurc/testing/wildfly-core/build/target/wildfly-core-3.0.0.Alpha8-SNAPSHOT/standalone/data/content/content344811471223714239/content/test.txt{code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1793) add-content operation fails to overwrite existing content with overwrite=true set

by Michal Jurc (JIRA)

Michal Jurc created WFCORE-1793: ----------------------------------- Summary: add-content operation fails to overwrite existing content with overwrite=true set Key: WFCORE-1793 URL: https://issues.jboss.org/browse/WFCORE-1793 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 3.0.0.Alpha8 Reporter: Michal Jurc Assignee: ehsavoie Hugonnet Upon overwriting content in managed exploded deployments on wildfly-core, the following errors are produced: {{CLI}} {code}[standalone@localhost:9990 /] deploy /home/mjurc/testing/eap7-204/jboss-kitchensink-ear.ear [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:undeploy {"outcome" => "success"} [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:explode {"outcome" => "success"} [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:deploy {"outcome" => "success"} [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:add-content(content=[{path=/home/mjurc/testing/eap7-204/test.txt, target-path=test.txt}], overwrite=true) { "outcome" => "failed", "failure-description" => "org.jboss.as.repository.ExplodedContentException: WFLYDR0021: Error updating content of exploded deployment", "rolled-back" => true } [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:add-content(content=[{path=/home/mjurc/testing/eap7-204/test.txt, target-path=test.txt}], overwrite=false) { "outcome" => "failed", "failure-description" => "org.jboss.as.repository.ExplodedContentException: WFLYDR0021: Error updating content of exploded deployment", "rolled-back" => true } [standalone@localhost:9990 /] /deployment=jboss-kitchensink-ear.ear:add-content(content=[{path=/home/mjurc/testing/eap7-204/test.txt, target-path=test.txt}]) { "outcome" => "failed", "failure-description" => "org.jboss.as.repository.ExplodedContentException: WFLYDR0021: Error updating content of exploded deployment", "rolled-back" => true }{code} {{Server}} {code}09:41:36,029 WARN [org.jboss.as.repository] (management-handler-thread - 5) java.nio.file.FileAlreadyExistsException: /home/mjurc/testing/wildfly-core/build/target/wildfly-core-3.0.0.Alpha8-SNAPSHOT/standalone/data/content/content7797527203290314566/content/test.txt 09:45:27,505 WARN [org.jboss.as.repository] (management-handler-thread - 12) java.nio.file.FileAlreadyExistsException: /home/mjurc/testing/wildfly-core/build/target/wildfly-core-3.0.0.Alpha8-SNAPSHOT/standalone/data/content/content721393778736298367/content/test.txt 09:45:36,352 WARN [org.jboss.as.repository] (management-handler-thread - 10) java.nio.file.FileAlreadyExistsException: /home/mjurc/testing/wildfly-core/build/target/wildfly-core-3.0.0.Alpha8-SNAPSHOT/standalone/data/content/content344811471223714239/content/test.txt{code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1283) Memory leak using KieBuilder.build() method.

by Matteo Mortari (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1283?page=com.atlassian.jira.plugi... ] Matteo Mortari reassigned DROOLS-1283: -------------------------------------- Assignee: Matteo Mortari (was: Mario Fusco) > Memory leak using KieBuilder.build() method. > --------------------------------------------- > > Key: DROOLS-1283 > URL: https://issues.jboss.org/browse/DROOLS-1283 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.5.0.CR1 > Reporter: Tibor Zimányi > Assignee: Matteo Mortari > Labels: regression, reported-by-qe > > There is a memory leak when building KieBase using KieBuilder.build() method. When continuously calling kieBuilder.build() (also with no resources), the OOM exception occurs. > I will make PR with a reproducer for this. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1792) Allow tests to retrieve IP address of node1

by Jan Martiska (JIRA)

Jan Martiska created WFCORE-1792: ------------------------------------ Summary: Allow tests to retrieve IP address of node1 Key: WFCORE-1792 URL: https://issues.jboss.org/browse/WFCORE-1792 Project: WildFly Core Issue Type: Enhancement Components: Test Suite Affects Versions: 3.0.0.Alpha7 Reporter: Jan Martiska Assignee: Jan Martiska Currently, the {{TestSuiteEnvironment}} only allows to obtain the address of node0. Multinode tests in the wildfly full repository which need to obtain the address of node1, do it in various non-standardized ways, it would be nice to standardize that by adding a method to obtain node1's address and refactoring the tests to use it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1788) Allow tests to retrieve IP address of node1

by Jan Martiska (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1788?page=com.atlassian.jira.plugi... ] Jan Martiska commented on WFCORE-1788: -------------------------------------- I'll refactor the tests in wildfly full repo after this is merged. > Allow tests to retrieve IP address of node1 > ------------------------------------------- > > Key: WFCORE-1788 > URL: https://issues.jboss.org/browse/WFCORE-1788 > Project: WildFly Core > Issue Type: Enhancement > Components: Test Suite > Affects Versions: 3.0.0.Alpha7 > Reporter: Jan Martiska > Assignee: Jan Martiska > > Currently, the {{TestSuiteEnvironment}} only allows to obtain the address of node0. > Multinode tests in the wildfly full repository which need to obtain the address of node1, do it in various non-standardized ways, it would be nice to standardize that by adding a method to obtain node1's address and refactoring the tests to use it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-628) Allow JWT-based token realms to operate in parse-only mode

by Pedro Igor (JIRA)

[ https://issues.jboss.org/browse/ELY-628?page=com.atlassian.jira.plugin.sy... ] Pedro Igor updated ELY-628: --------------------------- Fix Version/s: 1.1.0.Beta9 > Allow JWT-based token realms to operate in parse-only mode > ---------------------------------------------------------- > > Key: ELY-628 > URL: https://issues.jboss.org/browse/ELY-628 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Realms > Affects Versions: 1.1.0.Beta8 > Reporter: Pedro Igor > Assignee: Pedro Igor > Fix For: 1.1.0.Beta9 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-628) Allow JWT-based token realms to operate in parse-only mode

by Pedro Igor (JIRA)

[ https://issues.jboss.org/browse/ELY-628?page=com.atlassian.jira.plugin.sy... ] Pedro Igor edited comment on ELY-628 at 9/13/16 6:22 PM: --------------------------------------------------------- In some situations, a JWT-based token realm can be used to only extract identities from tokens without performing validations such as issuer, audience or signatures. For instance, when the mechanism already provides the same validations (or custom validations) supported by the realm. A driven use case for this issue is Keycloak integration, where Keycloak adapter code (authentication mechanism) already provides all the necessary checks for JWTs. In this case, the realm is only used to build identities and to trust token evidences passed from the mechanism. was (Author: pcraveiro): In some situations, a JWT-based token realm can be used to only extract identities from tokens without performing validations such as issuer, audience or signatures. For instance, when the mechanism already provides the same validations (or custom validations) supported by the realm. A driven use case for this issue is Keycloak integration, where Keycloak adapter code (authentication mechanism) already provides all the necessary checks for JWTs. In this case, the realm is just used to build identities and to trust token evidences passed from the mechanism. > Allow JWT-based token realms to operate in parse-only mode > ---------------------------------------------------------- > > Key: ELY-628 > URL: https://issues.jboss.org/browse/ELY-628 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Realms > Affects Versions: 1.1.0.Beta8 > Reporter: Pedro Igor > Assignee: Pedro Igor > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-628) Allow JWT-based token realms to operate in parse-only mode

by Pedro Igor (JIRA)

[ https://issues.jboss.org/browse/ELY-628?page=com.atlassian.jira.plugin.sy... ] Pedro Igor edited comment on ELY-628 at 9/13/16 6:21 PM: --------------------------------------------------------- In some situations, a JWT-based token realm can be used to only extract identities from tokens without performing validations such as issuer, audience or signatures. For instance, when the mechanism already provides the same validations (or custom validations) supported by the realm. A driven use case for this issue is Keycloak integration, where Keycloak adapter code (authentication mechanism) already provides all the necessary checks for JWTs. In this case, the realm is just used to build identities and to trust token evidences passed from the mechanism. was (Author: pcraveiro): In some situations, a JWT-based token realm can be used to only extract identities from tokens without performing validations such as issuer, audience or signatures. For instance, when the mechanism already provides the same validations (or custom validations) supported by the realm. A driven use case for this issue is Keycloak integration, where Keycloak adapter code (authentication mechanisms) already provides all the necessary checks for JWTs. In this case, the realm is just used to build identities and to trust token evidences passed from the mechanism. > Allow JWT-based token realms to operate in parse-only mode > ---------------------------------------------------------- > > Key: ELY-628 > URL: https://issues.jboss.org/browse/ELY-628 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Realms > Affects Versions: 1.1.0.Beta8 > Reporter: Pedro Igor > Assignee: Pedro Igor > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-628) Allow JWT-based token realms to operate in parse-only mode

by Pedro Igor (JIRA)

[ https://issues.jboss.org/browse/ELY-628?page=com.atlassian.jira.plugin.sy... ] Pedro Igor commented on ELY-628: -------------------------------- In some situations, a JWT-based token realm can be used to only extract identities from tokens without performing validations such as issuer, audience or signatures. For instance, when the mechanism already provides the same validations (or custom validations) supported by the realm. A driven use case for this issue is Keycloak integration, where Keycloak adapter code (authentication mechanisms) already provides all the necessary checks for JWTs. In this case, the realm is just used to build identities and to trust token evidences passed from the mechanism. > Allow JWT-based token realms to operate in parse-only mode > ---------------------------------------------------------- > > Key: ELY-628 > URL: https://issues.jboss.org/browse/ELY-628 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Realms > Affects Versions: 1.1.0.Beta8 > Reporter: Pedro Igor > Assignee: Pedro Igor > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-628) Allow JWT-based token realms to operate in parse-only mode

by Pedro Igor (JIRA)

[ https://issues.jboss.org/browse/ELY-628?page=com.atlassian.jira.plugin.sy... ] Pedro Igor updated ELY-628: --------------------------- Summary: Allow JWT-based token realms to operate in parse-only mode (was: Allow JWT-based token realms to only parse JWTs) > Allow JWT-based token realms to operate in parse-only mode > ---------------------------------------------------------- > > Key: ELY-628 > URL: https://issues.jboss.org/browse/ELY-628 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Realms > Affects Versions: 1.1.0.Beta8 > Reporter: Pedro Igor > Assignee: Pedro Igor > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-628) Allow JWT-based token realms to only parse JWTs

by Pedro Igor (JIRA)

[ https://issues.jboss.org/browse/ELY-628?page=com.atlassian.jira.plugin.sy... ] Pedro Igor updated ELY-628: --------------------------- Summary: Allow JWT-based token realms to only parse JWTs (was: Allow JWT-based token realms to only extract identities without performing any check) > Allow JWT-based token realms to only parse JWTs > ----------------------------------------------- > > Key: ELY-628 > URL: https://issues.jboss.org/browse/ELY-628 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Realms > Affects Versions: 1.1.0.Beta8 > Reporter: Pedro Igor > Assignee: Pedro Igor > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-628) Allow JWT-based token realms to only extract identities without performing any check

by Pedro Igor (JIRA)

Pedro Igor created ELY-628: ------------------------------ Summary: Allow JWT-based token realms to only extract identities without performing any check Key: ELY-628 URL: https://issues.jboss.org/browse/ELY-628 Project: WildFly Elytron Issue Type: Enhancement Components: Realms Affects Versions: 1.1.0.Beta8 Reporter: Pedro Igor Assignee: Pedro Igor -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4376) Incorrect callback handler used during authentication (SASL)

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4376?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-4376: ----------------------------------------------- Brad Maxwell <bmaxwell(a)redhat.com> changed the Status of [bug 901248|https://bugzilla.redhat.com/show_bug.cgi?id=901248] from POST to MODIFIED > Incorrect callback handler used during authentication (SASL) > ------------------------------------------------------------- > > Key: WFLY-4376 > URL: https://issues.jboss.org/browse/WFLY-4376 > Project: WildFly > Issue Type: Bug > Components: Clustering, EJB > Reporter: Enrique González Martínez > Assignee: Enrique González Martínez > Fix For: 10.0.0.CR5 > > > Cluster topology messages are not using the proper callbackhandler when the connection is being established. > {code} > 06:59:44,609 ERROR [org.jboss.remoting.remote.connection] (Remoting "config-based-ejb-client-endpoint" read-1) JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed > 06:59:44,611 INFO [org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager] (ejb-client-cluster-node-connection-creation-2-thread-2) Could not create a connection for cluster node ClusterNode{clusterName='ejb', nodeName='perf18', clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='10.16.90.54', destinationPort=4447}], resolvedDestination=[Destination address=10.16.90.54, destination port=4447]} in cluster ejb > java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed > at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:91) > at org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:89) > at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:406) > at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:380) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:662) > Caused by: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed > at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:382) > at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:225) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) > at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189) > at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) > at org.xnio.nio.NioHandle.run(NioHandle.java:90) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:187) > at ...asynchronous invocation...(Unknown Source) > at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:270) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:386) > at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:151) > at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:132) > at org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:87) > ... 7 more > {code} > Before that, this log is produced: > {code} > DEBUG: Client authentication failed for mechanism DIGEST-MD5: javax.security.sasl.SaslException: DIGEST-MD5: Cannot perform callback to acquire realm, authentication ID or password [Caused by javax.security.auth.callback.UnsupportedCallbackException] > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1791) Strange operation-id handling in domain server reload execution

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-1791: ---------------------------------------- Summary: Strange operation-id handling in domain server reload execution Key: WFCORE-1791 URL: https://issues.jboss.org/browse/WFCORE-1791 Project: WildFly Core Issue Type: Bug Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry When the HC sends a reload op to a managed server it includes an undocumented "operation-id" parameter. But, I don’t see how it is used with a reload. When it was added to the code the intent clearly was that it would be used, but now at least is not. ServerDomainProcessReloadHandler reads it from the op and sets DomainServerCommunicationServices.initialOperationId, but that field is only read when HostControllerConnectionService is instantiated. HostControllerConnectionService then caches the value in a final field. A reload does not result in a new instantiation of HostControllerConnectionService; that object is only instantiated during initial process boot when ServerStartTask is unmarshaled from stdin and run. So changing the DomainServerCommunicationServices.initialOperationId in a reload should do nothing. https://github.com/wildfly/wildfly-core/commit/302949cf60823d8aa3989d74df... is the initial commit when this update of the id in reload was added in. The intent was that by providing this id, when the reloading server connects to the HC to get the boot ops, that read of boot ops would be able to "join" any active operation that triggered the reload, and thus would not have to block waiting for that operation to complete. Afaict, if the "blocking" param on an op like /host=x/server[-config]=y:reload is set to 'true' the op should deadlock. On the HC, ServerReloadHandler will acquire the exclusive lock by calling context.getServiceRegistry(true). Then ServerInventoryImpl.reloadServer will block waiting for the server to reach STARTED state. But the server won't reach that because it's registration request will not be able to acquire the HC lock. Task here is to 1) Confirm the above and then 2) Either a) get the operation-id propagated b) or rip the operation-id bit out of reload because investigation showed it was not needed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1791) Strange operation-id handling in domain server reload execution

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1791?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-1791: ---------------------------------------- Assignee: (was: Brian Stansberry) > Strange operation-id handling in domain server reload execution > --------------------------------------------------------------- > > Key: WFCORE-1791 > URL: https://issues.jboss.org/browse/WFCORE-1791 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > > When the HC sends a reload op to a managed server it includes an undocumented "operation-id" parameter. But, I don’t see how it is used with a reload. When it was added to the code the intent clearly was that it would be used, but now at least is not. ServerDomainProcessReloadHandler reads it from the op and sets DomainServerCommunicationServices.initialOperationId, but that field is only read when HostControllerConnectionService is instantiated. HostControllerConnectionService then caches the value in a final field. A reload does not result in a new instantiation of HostControllerConnectionService; that object is only instantiated during initial process boot when ServerStartTask is unmarshaled from stdin and run. So changing the DomainServerCommunicationServices.initialOperationId in a reload should do nothing. > https://github.com/wildfly/wildfly-core/commit/302949cf60823d8aa3989d74df... is the initial commit when this update of the id in reload was added in. The intent was that by providing this id, when the reloading server connects to the HC to get the boot ops, that read of boot ops would be able to "join" any active operation that triggered the reload, and thus would not have to block waiting for that operation to complete. > Afaict, if the "blocking" param on an op like /host=x/server[-config]=y:reload is set to 'true' the op should deadlock. On the HC, ServerReloadHandler will acquire the exclusive lock by calling context.getServiceRegistry(true). Then ServerInventoryImpl.reloadServer will block waiting for the server to reach STARTED state. But the server won't reach that because it's registration request will not be able to acquire the HC lock. > Task here is to > 1) Confirm the above and then > 2) Either > a) get the operation-id propagated > b) or rip the operation-id bit out of reload because investigation showed it was not needed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1775) CLI command for enabling tracking configuration changes act differently when host is specifiend and when it is not

by Ivan Straka (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1775?page=com.atlassian.jira.plugi... ] Ivan Straka commented on WFCORE-1775: ------------------------------------- Thank you. > CLI command for enabling tracking configuration changes act differently when host is specifiend and when it is not > ------------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-1775 > URL: https://issues.jboss.org/browse/WFCORE-1775 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Ivan Straka > Assignee: Brian Stansberry > > If I execute > {code} > /host=slave/core-service=management/service=configuration-changes:add(history-size=10) > {code} > on host controller, everything is fine. > But, if > {code} > /core-service=management/service=configuration-changes:add(history-size=10) > {code} > is executed, > {code:json} > { > "outcome" => "failed", > "failure-description" => "WFLYDC0032: Operation add for address [ > (\"core-service\" => \"management\"), > (\"service\" => \"configuration-changes\") > ] can only be handled by the master Domain Controller; this host is not the master Domain Controller", > "rolled-back" => true > } > {code} > is returned. > I have discussed this with [~ehugonnet], and it has not been decided whether this is correct behavior. For some reason it is trying to route the request to the DC. > This jira is supposed to start a discussion about this - is it a bug, or correct behavior? > IMHO results of these two commands should should be the same. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1283) Memory leak using KieBuilder.build() method.

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1283?page=com.atlassian.jira.plugi... ] Mario Fusco commented on DROOLS-1283: ------------------------------------- I reproduced the problem in a simpler way using the test case I'm pasting below. There isn't any assertion there but you can see the memory occupation constantly increasing at each loop. {code} @Test public void testCreateKieBaseInLoop() { final String drl = "package " + this.getClass().getPackage().getName() + ";" + " rule R1 \n" + " when \n" + " String() \n" + " then \n" + " end "; final KieResources kieResources = KieServices.Factory.get().getResources(); final org.kie.api.io.Resource drlResource = kieResources.newByteArrayResource( drl.getBytes(), "UTF-8" ); drlResource.setTargetPath("src/main/resources/rule.drl"); while (true) { createKieBase(drlResource); System.out.println(getUsedMemory()); } } private void createKieBase(final org.kie.api.io.Resource... resources ) { final KieHelper kieHelper = new KieHelper(); for ( org.kie.api.io.Resource resource : resources) { kieHelper.addResource(resource); } kieHelper.build(); } private long getUsedMemory() { System.gc(); final Runtime runtime = Runtime.getRuntime(); return runtime.totalMemory() - runtime.freeMemory(); } {code} The leak is not a real leak but only caused by the fact that all kcontainers are stored in this map https://github.com/droolsjbpm/drools/blob/master/drools-compiler/src/main... The kcontainers will be removed by that map when calling dispose() on the single kcontainer itself. The problem is that nobody is calling that dispose() method, even in our own KieHelper. Also we are not sure if we want to rely on the fact that the users will always call that dispose() method (that however is still not exposed in the public API) so we are still discussing all possible solutions. > Memory leak using KieBuilder.build() method. > --------------------------------------------- > > Key: DROOLS-1283 > URL: https://issues.jboss.org/browse/DROOLS-1283 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.5.0.CR1 > Reporter: Tibor Zimányi > Assignee: Mario Fusco > Labels: regression, reported-by-qe > > There is a memory leak when building KieBase using KieBuilder.build() method. When continuously calling kieBuilder.build() (also with no resources), the OOM exception occurs. > I will make PR with a reproducer for this. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3759) Make IP address of remote EJB client accessible to the developer from within app authentication code

by Bilge Ozpeynirci (JIRA)

[ https://issues.jboss.org/browse/WFLY-3759?page=com.atlassian.jira.plugin.... ] Bilge Ozpeynirci updated WFLY-3759: ----------------------------------- Summary: Make IP address of remote EJB client accessible to the developer from within app authentication code (was: Make IP address of remote EJB client accessible from within a login module) > Make IP address of remote EJB client accessible to the developer from within app authentication code > ---------------------------------------------------------------------------------------------------- > > Key: WFLY-3759 > URL: https://issues.jboss.org/browse/WFLY-3759 > Project: WildFly > Issue Type: Feature Request > Components: Domain Management, Security > Reporter: Derek Horton > Assignee: Darran Lofthouse > > Make the IP address of remote EJB clients accessible from within a login module login module when the security-realm is configured to defer to JAAS. > This is possible when the authentication is handled by the security-realm, but it is not possible when the security-realm defers to a security-domain (JAAS). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1785) Extension remove is not cleaning out provided capabilities

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1785?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1785: ------------------------------------------ Yes, this is a general problem with the extension remove handling, and is not specific to any particular extension. > Extension remove is not cleaning out provided capabilities > ---------------------------------------------------------- > > Key: WFCORE-1785 > URL: https://issues.jboss.org/browse/WFCORE-1785 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Alpha7 > Reporter: Jan Tymel > Assignee: Tomaz Cerar > Labels: affects_elytron > Fix For: 3.0.0.Alpha8 > > > It is not possible to add Elytron extension that was previously removed. Everything works fine if the server is reloaded between steps 5 and 6, hence I assume that there is either 'reload required' state missing or Elytron extension is not removed properly. > Actual result: > {code} > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.providers' is already registered in context 'global'.", > "rolled-back" => true > } > {code} > {code} > ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([("extension" => "org.wildfly.extension.elytron")]): java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.providers' is already registered in context 'global'. > at org.jboss.as.controller.CapabilityRegistry.lambda$registerPossibleCapability$0(CapabilityRegistry.java:518) > at java.util.concurrent.ConcurrentHashMap.computeIfPresent(ConcurrentHashMap.java:1769) > at org.jboss.as.controller.CapabilityRegistry.registerPossibleCapability(CapabilityRegistry.java:512) > at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerCapability(ConcreteResourceRegistration.java:669) > at org.jboss.as.controller.SimpleResourceDefinition.registerCapabilities(SimpleResourceDefinition.java:368) > at org.jboss.as.controller.registry.NodeSubregistry.registerChild(NodeSubregistry.java:108) > at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:226) > at org.wildfly.extension.elytron.ElytronDefinition.registerChildren(ElytronDefinition.java:83) > at org.jboss.as.controller.registry.NodeSubregistry.registerChild(NodeSubregistry.java:107) > at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:226) > at org.jboss.as.controller.extension.ExtensionRegistry$SubsystemRegistrationImpl.registerSubsystemModel(ExtensionRegistry.java:694) > at org.wildfly.extension.elytron.ElytronExtension.initialize(ElytronExtension.java:99) > at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:131) > at org.jboss.as.controller.extension.ExtensionAddHandler.execute(ExtensionAddHandler.java:83) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:951) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:694) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:389) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAs(Subject.java:422) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} > Expected result: > It is possible to add Elytron subsystem after its removal. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1790) Invalid value-type for some operation arguments

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1790?page=com.atlassian.jira.plugi... ] Jean-Francois Denise closed WFCORE-1790. ---------------------------------------- Resolution: Rejected This is not a bug, but a valid data representation. > Invalid value-type for some operation arguments > ----------------------------------------------- > > Key: WFCORE-1790 > URL: https://issues.jboss.org/browse/WFCORE-1790 > Project: WildFly Core > Issue Type: Bug > Components: Security, Server > Reporter: Jean-Francois Denise > Assignee: Darran Lofthouse > > vault:add and authentication=<x>:add have arguments of type OBJECT with a value-type of STRING. The arguments passed to the operations are complex-type, so the value-type should be containing the complex type description. > Examples: > /core-service=vault:add(vault-options={KEYSTORE_PASSWORD=>MASK-20OB41ZkH8YzlPTICpKg5.,KEYSTORE_ALIAS=>jboss,SALT=>12345678,ITERATION_COUNT=>50,ENC_FILE_DIR=>/path/to/enc/file}) > /subsystem=security/security-domain=test/authentication=classic:add(login-modules=[{code=UsersRoles,flag=required,module-options={usersProperties=$\{jboss.server.config.dir\}/users.properties,rolesProperties=$\{jboss.server.config.dir\}/roles.properties}}] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1790) Invalid value-type for some operation arguments

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1790?page=com.atlassian.jira.plugi... ] Jean-Francois Denise commented on WFCORE-1790: ---------------------------------------------- Oh, I missed the Map data structure... I will close the bug and will take a second look to my fix. > Invalid value-type for some operation arguments > ----------------------------------------------- > > Key: WFCORE-1790 > URL: https://issues.jboss.org/browse/WFCORE-1790 > Project: WildFly Core > Issue Type: Bug > Components: Security, Server > Reporter: Jean-Francois Denise > Assignee: Darran Lofthouse > > vault:add and authentication=<x>:add have arguments of type OBJECT with a value-type of STRING. The arguments passed to the operations are complex-type, so the value-type should be containing the complex type description. > Examples: > /core-service=vault:add(vault-options={KEYSTORE_PASSWORD=>MASK-20OB41ZkH8YzlPTICpKg5.,KEYSTORE_ALIAS=>jboss,SALT=>12345678,ITERATION_COUNT=>50,ENC_FILE_DIR=>/path/to/enc/file}) > /subsystem=security/security-domain=test/authentication=classic:add(login-modules=[{code=UsersRoles,flag=required,module-options={usersProperties=$\{jboss.server.config.dir\}/users.properties,rolesProperties=$\{jboss.server.config.dir\}/roles.properties}}] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1790) Invalid value-type for some operation arguments

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1790?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1790: ------------------------------------------ Generally Map<String, String> type attributes are discouraged because they can't be fully self-describing. But in some cases there's really no alternative, as the attribute is configuring some plugin point and we can't know in advance what options are supported by that plugin. > Invalid value-type for some operation arguments > ----------------------------------------------- > > Key: WFCORE-1790 > URL: https://issues.jboss.org/browse/WFCORE-1790 > Project: WildFly Core > Issue Type: Bug > Components: Security, Server > Reporter: Jean-Francois Denise > Assignee: Darran Lofthouse > > vault:add and authentication=<x>:add have arguments of type OBJECT with a value-type of STRING. The arguments passed to the operations are complex-type, so the value-type should be containing the complex type description. > Examples: > /core-service=vault:add(vault-options={KEYSTORE_PASSWORD=>MASK-20OB41ZkH8YzlPTICpKg5.,KEYSTORE_ALIAS=>jboss,SALT=>12345678,ITERATION_COUNT=>50,ENC_FILE_DIR=>/path/to/enc/file}) > /subsystem=security/security-domain=test/authentication=classic:add(login-modules=[{code=UsersRoles,flag=required,module-options={usersProperties=$\{jboss.server.config.dir\}/users.properties,rolesProperties=$\{jboss.server.config.dir\}/roles.properties}}] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1790) Invalid value-type for some operation arguments

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1790?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1790: ------------------------------------------ An attribute of type OBJECT with a value-type of STRING is equivalent to a Map<String,String>. A Map has no predefined set of valid keys, so there is no full description of keys and values. >From https://docs.jboss.org/author/display/WFLY/Admin+Guide#AdminGuide-Descrip... value-type – ModelType or complex structure – Only present if type is LIST or OBJECT. If all elements in the LIST or all the values of the OBJECT type are of the same type, this will be one of the ModelType enums BIG_DECIMAL, BIG_INTEGER, BOOLEAN, BYTES, DOUBLE, INT, LONG, STRING. Otherwise, value-type will detail the structure of the attribute value, enumerating the value's fields and the type of their value. So, if the type of the ModelNode for the value-type description is ModelType.TYPE, then the attribute is a Map<String, X> where X is indicated by the enum value. If the type of the ModelNode for the value-type description is ModelType.OBJECT, then the keys in the object are the legal fields and the values are the description of the field. > Invalid value-type for some operation arguments > ----------------------------------------------- > > Key: WFCORE-1790 > URL: https://issues.jboss.org/browse/WFCORE-1790 > Project: WildFly Core > Issue Type: Bug > Components: Security, Server > Reporter: Jean-Francois Denise > Assignee: Darran Lofthouse > > vault:add and authentication=<x>:add have arguments of type OBJECT with a value-type of STRING. The arguments passed to the operations are complex-type, so the value-type should be containing the complex type description. > Examples: > /core-service=vault:add(vault-options={KEYSTORE_PASSWORD=>MASK-20OB41ZkH8YzlPTICpKg5.,KEYSTORE_ALIAS=>jboss,SALT=>12345678,ITERATION_COUNT=>50,ENC_FILE_DIR=>/path/to/enc/file}) > /subsystem=security/security-domain=test/authentication=classic:add(login-modules=[{code=UsersRoles,flag=required,module-options={usersProperties=$\{jboss.server.config.dir\}/users.properties,rolesProperties=$\{jboss.server.config.dir\}/roles.properties}}] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1785) Extension remove is not cleaning out provided capabilities

by Michal Petrov (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1785?page=com.atlassian.jira.plugi... ] Michal Petrov commented on WFCORE-1785: --------------------------------------- [~brian.stansberry], for what it's worth similar error is thrown when you try to remove and add back EJB3 extension. As far as I can tell the problem is that the capabilities are registered for the extension's children (in this case [ProviderLoaderDefinition|https://github.com/wildfly-security/elytron-subs...]) which don't seem to be processed when the extension is removed. > Extension remove is not cleaning out provided capabilities > ---------------------------------------------------------- > > Key: WFCORE-1785 > URL: https://issues.jboss.org/browse/WFCORE-1785 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Alpha7 > Reporter: Jan Tymel > Assignee: Tomaz Cerar > Labels: affects_elytron > Fix For: 3.0.0.Alpha8 > > > It is not possible to add Elytron extension that was previously removed. Everything works fine if the server is reloaded between steps 5 and 6, hence I assume that there is either 'reload required' state missing or Elytron extension is not removed properly. > Actual result: > {code} > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.providers' is already registered in context 'global'.", > "rolled-back" => true > } > {code} > {code} > ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([("extension" => "org.wildfly.extension.elytron")]): java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.providers' is already registered in context 'global'. > at org.jboss.as.controller.CapabilityRegistry.lambda$registerPossibleCapability$0(CapabilityRegistry.java:518) > at java.util.concurrent.ConcurrentHashMap.computeIfPresent(ConcurrentHashMap.java:1769) > at org.jboss.as.controller.CapabilityRegistry.registerPossibleCapability(CapabilityRegistry.java:512) > at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerCapability(ConcreteResourceRegistration.java:669) > at org.jboss.as.controller.SimpleResourceDefinition.registerCapabilities(SimpleResourceDefinition.java:368) > at org.jboss.as.controller.registry.NodeSubregistry.registerChild(NodeSubregistry.java:108) > at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:226) > at org.wildfly.extension.elytron.ElytronDefinition.registerChildren(ElytronDefinition.java:83) > at org.jboss.as.controller.registry.NodeSubregistry.registerChild(NodeSubregistry.java:107) > at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:226) > at org.jboss.as.controller.extension.ExtensionRegistry$SubsystemRegistrationImpl.registerSubsystemModel(ExtensionRegistry.java:694) > at org.wildfly.extension.elytron.ElytronExtension.initialize(ElytronExtension.java:99) > at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:131) > at org.jboss.as.controller.extension.ExtensionAddHandler.execute(ExtensionAddHandler.java:83) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:951) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:694) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:389) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAs(Subject.java:422) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} > Expected result: > It is possible to add Elytron subsystem after its removal. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7097) The constant-role-mapper is not able to handle role name with space in it

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7097?page=com.atlassian.jira.plugin.... ] Darran Lofthouse reassigned WFLY-7097: -------------------------------------- Assignee: Darran Lofthouse (was: Ilia Vassilev) > The constant-role-mapper is not able to handle role name with space in it > ------------------------------------------------------------------------- > > Key: WFLY-7097 > URL: https://issues.jboss.org/browse/WFLY-7097 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Darran Lofthouse > Priority: Critical > > Adding a role with a space in the name results in 2 roles (for parts of the name) added. The problem is visible after server reload. E.g. adding role "JBoss Admin" results in 2 roles assigned "JBoss" and "Admin" > *Expected behavior* > Spaces in role name must be supported and correctly handled. E.g. After adding "JBoss Admin" and server reload "JBoss Admin" is assigned. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7097) The constant-role-mapper is not able to handle role name with space in it

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7097?page=com.atlassian.jira.plugin.... ] Darran Lofthouse reassigned WFLY-7097: -------------------------------------- Assignee: Jan Kalina (was: Darran Lofthouse) > The constant-role-mapper is not able to handle role name with space in it > ------------------------------------------------------------------------- > > Key: WFLY-7097 > URL: https://issues.jboss.org/browse/WFLY-7097 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Jan Kalina > Priority: Critical > > Adding a role with a space in the name results in 2 roles (for parts of the name) added. The problem is visible after server reload. E.g. adding role "JBoss Admin" results in 2 roles assigned "JBoss" and "Admin" > *Expected behavior* > Spaces in role name must be supported and correctly handled. E.g. After adding "JBoss Admin" and server reload "JBoss Admin" is assigned. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7097) The constant-role-mapper is not able to handle role name with space in it

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/WFLY-7097?page=com.atlassian.jira.plugin.... ] Ilia Vassilev reassigned WFLY-7097: ----------------------------------- Assignee: Ilia Vassilev (was: Darran Lofthouse) > The constant-role-mapper is not able to handle role name with space in it > ------------------------------------------------------------------------- > > Key: WFLY-7097 > URL: https://issues.jboss.org/browse/WFLY-7097 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Ilia Vassilev > Priority: Critical > > Adding a role with a space in the name results in 2 roles (for parts of the name) added. The problem is visible after server reload. E.g. adding role "JBoss Admin" results in 2 roles assigned "JBoss" and "Admin" > *Expected behavior* > Spaces in role name must be supported and correctly handled. E.g. After adding "JBoss Admin" and server reload "JBoss Admin" is assigned. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1787) Try to add resource with OBJECT type attribute cause IllegalArgumentException

by Alexey Loubyansky (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1787?page=com.atlassian.jira.plugi... ] Alexey Loubyansky commented on WFCORE-1787: ------------------------------------------- Especially if it's a regression. Although bad descriptions should be forced to get fixed. Once they are fixed, the CLI should not be expected to accept them, perhaps, unless the validation is off. > Try to add resource with OBJECT type attribute cause IllegalArgumentException > ----------------------------------------------------------------------------- > > Key: WFCORE-1787 > URL: https://issues.jboss.org/browse/WFCORE-1787 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Hynek Švábek > Assignee: Jean-Francois Denise > Priority: Blocker > > Try to add resource with OBJECT type attribute cause IllegalArgumentException. > *Actual result:* > CLI operation failed with IllegalArgumentException > *Expected results:* > Success CLI operation > *My investigation:* > In my opinion is problem caused by this PR to wildfly-core > https://github.com/wildfly/wildfly-core/pull/1698/files#diff-835f377f8fa5... > Look at lines 1333-1350 Util.java -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1787) Try to add resource with OBJECT type attribute cause IllegalArgumentException

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1787?page=com.atlassian.jira.plugi... ] Jean-Francois Denise commented on WFCORE-1787: ---------------------------------------------- We could say that the link is "caused-by" but the CLI should resist to this kind of description. > Try to add resource with OBJECT type attribute cause IllegalArgumentException > ----------------------------------------------------------------------------- > > Key: WFCORE-1787 > URL: https://issues.jboss.org/browse/WFCORE-1787 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Hynek Švábek > Assignee: Jean-Francois Denise > Priority: Blocker > > Try to add resource with OBJECT type attribute cause IllegalArgumentException. > *Actual result:* > CLI operation failed with IllegalArgumentException > *Expected results:* > Success CLI operation > *My investigation:* > In my opinion is problem caused by this PR to wildfly-core > https://github.com/wildfly/wildfly-core/pull/1698/files#diff-835f377f8fa5... > Look at lines 1333-1350 Util.java -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1790) Invalid value-type for some operation arguments

by Jean-Francois Denise (JIRA)

Jean-Francois Denise created WFCORE-1790: -------------------------------------------- Summary: Invalid value-type for some operation arguments Key: WFCORE-1790 URL: https://issues.jboss.org/browse/WFCORE-1790 Project: WildFly Core Issue Type: Bug Components: Security, Server Reporter: Jean-Francois Denise Assignee: Darran Lofthouse vault:add and authentication=<x>:add have arguments of type OBJECT with a value-type of STRING. The arguments passed to the operations are complex-type, so the value-type should be containing the complex type description. Examples: /core-service=vault:add(vault-options={KEYSTORE_PASSWORD=>MASK-20OB41ZkH8YzlPTICpKg5.,KEYSTORE_ALIAS=>jboss,SALT=>12345678,ITERATION_COUNT=>50,ENC_FILE_DIR=>/path/to/enc/file}) /subsystem=security/security-domain=test/authentication=classic:add(login-modules=[{code=UsersRoles,flag=required,module-options={usersProperties=$\{jboss.server.config.dir\}/users.properties,rolesProperties=$\{jboss.server.config.dir\}/roles.properties}}] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1789) PreparedResponseTestCase from wf-core-eap fails intermittently

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1789?page=com.atlassian.jira.plugi... ] ehsavoie Hugonnet moved JBEAP-5996 to WFCORE-1789: -------------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-1789 (was: JBEAP-5996) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Test Suite (was: Test Suite) Affects Version/s: 3.0.0.Alpha7 (was: 7.1.0.DR2) > PreparedResponseTestCase from wf-core-eap fails intermittently > -------------------------------------------------------------- > > Key: WFCORE-1789 > URL: https://issues.jboss.org/browse/WFCORE-1789 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Affects Versions: 3.0.0.Alpha7 > Reporter: ehsavoie Hugonnet > Assignee: ehsavoie Hugonnet > > *Description of problem:* > PreparedResponseTestCase from wf-core-eap fails intermittently with two different stack-trace > *How reproducible:* > 2% > *Actual results: (1. issue)* > Stack Trace: > {noformat} > java.lang.AssertionError: null > at org.junit.Assert.fail(Assert.java:86) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.junit.Assert.assertTrue(Assert.java:52) > at org.wildfly.core.test.standalone.mgmt.PreparedResponseTestCase.reloadServer(PreparedResponseTestCase.java:113) > {noformat} > Standard Output: > {noformat} > &amp#27;[0m01:34:22,658 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) WFLYSRV0028: Stopped deployment slow-stop.jar (runtime-name: slow-stop.jar) in 3025ms > &amp#27;[0m&amp#27;[0m01:34:22,701 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0050: WildFly Core 3.0.0.Alpha4-redhat-1 "Kenny" stopped in 3071ms > &amp#27;[0m&amp#27;[0m01:34:22,710 INFO [org.jboss.as] (MSC service thread 1-5) WFLYSRV0049: WildFly Core 3.0.0.Alpha4-redhat-1 "Kenny" starting > &amp#27;[0m&amp#27;[0m01:34:23,243 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http) > &amp#27;[0m&amp#27;[0m01:34:23,331 INFO [org.jboss.as.patching] (MSC service thread 1-4) WFLYPAT0050: WildFly cumulative patch ID is: base, one-off patches include: none > &amp#27;[0m&amp#27;[33m01:34:23,361 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-3) WFLYDM0111: Keystore /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-core-rhel/19de6045/testsuite/manualmode/target/wildfly-core/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost > &amp#27;[0m&amp#27;[33m01:34:23,355 WARN [org.jboss.as.domain.http.api.undertow] (MSC service thread 1-1) WFLYDMHTTP0003: Unable to load console module for slot main, disabling console > &amp#27;[0m&amp#27;[0m01:34:23,367 INFO [org.jboss.as.server.deployment] (MSC service thread 1-7) WFLYSRV0027: Starting deployment of "slow-stop.jar" (runtime-name: "slow-stop.jar") > &amp#27;[0m&amp#27;[33m01:34:23,449 WARN [org.jboss.as.dependency.private] (MSC service thread 1-1) WFLYSRV0018: Deployment "deployment.slow-stop.jar" is using a private module ("org.jboss.as.controller:main") which may be changed or removed in future versions without notice. > &amp#27;[0m&amp#27;[33m01:34:23,450 WARN [org.jboss.as.dependency.private] (MSC service thread 1-1) WFLYSRV0018: Deployment "deployment.slow-stop.jar" is using a private module ("org.jboss.as.server:main") which may be changed or removed in future versions without notice. > &amp#27;[0m&amp#27;[33m01:34:23,452 WARN [org.jboss.as.dependency.private] (MSC service thread 1-1) WFLYSRV0018: Deployment "deployment.slow-stop.jar" is using a private module ("org.wildfly.extension.request-controller:main") which may be changed or removed in future versions without notice. > &amp#27;[0m&amp#27;[33m01:34:23,453 WARN [org.jboss.as.dependency.private] (MSC service thread 1-1) WFLYSRV0018: Deployment "deployment.slow-stop.jar" is using a private module ("org.jboss.as.network:main") which may be changed or removed in future versions without notice. > &amp#27;[0m&amp#27;[0m01:34:23,479 INFO [org.wildfly.test.shutdown.SlowStopService] (MSC service thread 1-7) Started with a stop duration of 3000 ms > &amp#27;[0m&amp#27;[0m01:34:23,528 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0010: Deployed "slow-stop.jar" (runtime-name : "slow-stop.jar") > &amp#27;[0m > {noformat} > *Actual results: (2. issue)* > Stack Trace: > {noformat} > java.lang.RuntimeException: java.io.IOException: java.util.concurrent.CancellationException: Operation was cancelled > at org.jboss.threads.AsyncFutureTask.operationCancelled(AsyncFutureTask.java:70) > at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:267) > at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.get(AbstractDelegatingAsyncFuture.java:57) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:75) > at org.wildfly.core.testrunner.ManagementClient.executeForResult(ManagementClient.java:234) > at org.wildfly.core.test.standalone.mgmt.PreparedResponseTestCase.reloadServer(PreparedResponseTestCase.java:102) > {noformat} > Standard Output: > {noformat} > 11:03:28,015 WARN [org.jboss.as.protocol.connection] (Remoting "management-client" task-5) WFLYPRT0018: No such request (1) associated with channel Channel ID a37ddd63 (outbound) of Remoting connection 68823cff to /10.16.180.146:9990 of endpoint "management-client" <6645cf9f> > {noformat} > *Expected results:* > No errors > *Additional info:* > Links to jenkins results: > * https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-AS-T... > * https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-as-testsuite-... > * https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-as-testsuite-... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1787) Try to add resource with OBJECT type attribute cause IllegalArgumentException

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1787?page=com.atlassian.jira.plugi... ] Jean-Francois Denise updated WFCORE-1787: ----------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1792 > Try to add resource with OBJECT type attribute cause IllegalArgumentException > ----------------------------------------------------------------------------- > > Key: WFCORE-1787 > URL: https://issues.jboss.org/browse/WFCORE-1787 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Hynek Švábek > Assignee: Jean-Francois Denise > Priority: Blocker > > Try to add resource with OBJECT type attribute cause IllegalArgumentException. > *Actual result:* > CLI operation failed with IllegalArgumentException > *Expected results:* > Success CLI operation > *My investigation:* > In my opinion is problem caused by this PR to wildfly-core > https://github.com/wildfly/wildfly-core/pull/1698/files#diff-835f377f8fa5... > Look at lines 1333-1350 Util.java -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-627) Elytron introduces SSL/TLS protocol constraints

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-627?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse commented on ELY-627: -------------------------------------- Needs to be discussed but first of all need to consider if following a similar pattern to CipherSuiteSelector is the way to go. > Elytron introduces SSL/TLS protocol constraints > ----------------------------------------------- > > Key: ELY-627 > URL: https://issues.jboss.org/browse/ELY-627 > Project: WildFly Elytron > Issue Type: Bug > Components: SSL > Affects Versions: 1.1.0.Beta8 > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Critical > > {noformat} > "protocols" => { > "type" => LIST, > "description" => "The enabled protocols.", > "expressions-allowed" => true, > "nillable" => false, > "allowed" => [ > "SSLv2", > "SSLv3", > "TLSv1", > "TLSv1_1", > "TLSv1_2", > "TLSv1_3" > ], > "value-type" => STRING, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > {noformat} > Why elytron on this place is going to validate user input and map standard java values [1] into proprietary values? > Whereas on other similar places (KeyManager algorithm, TrustManager algorithm, Keystore types) it leaves up to user to set proper value. > IMO, with such mapping another place, where bugs can raise was introduced. EAP will be here always one step back compared to java. > Note, IBM java already today defines little bit different protocols set [2] > I wonder, where is that mapping "TLSv1_2 -> TLSv1.2" acually performed? I couldn't find that place. > [1] https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardN... > [2] http://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.secu... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-627) Elytron introduces SSL/TLS protocol constraints

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-627?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse moved WFLY-7076 to ELY-627: -------------------------------------------- Project: WildFly Elytron (was: WildFly) Key: ELY-627 (was: WFLY-7076) Component/s: SSL (was: Security) Affects Version/s: 1.1.0.Beta8 (was: 11.0.0.Alpha1) > Elytron introduces SSL/TLS protocol constraints > ----------------------------------------------- > > Key: ELY-627 > URL: https://issues.jboss.org/browse/ELY-627 > Project: WildFly Elytron > Issue Type: Bug > Components: SSL > Affects Versions: 1.1.0.Beta8 > Reporter: Martin Choma > Assignee: Jan Kalina > > {noformat} > "protocols" => { > "type" => LIST, > "description" => "The enabled protocols.", > "expressions-allowed" => true, > "nillable" => false, > "allowed" => [ > "SSLv2", > "SSLv3", > "TLSv1", > "TLSv1_1", > "TLSv1_2", > "TLSv1_3" > ], > "value-type" => STRING, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > {noformat} > Why elytron on this place is going to validate user input and map standard java values [1] into proprietary values? > Whereas on other similar places (KeyManager algorithm, TrustManager algorithm, Keystore types) it leaves up to user to set proper value. > IMO, with such mapping another place, where bugs can raise was introduced. EAP will be here always one step back compared to java. > Note, IBM java already today defines little bit different protocols set [2] > I wonder, where is that mapping "TLSv1_2 -> TLSv1.2" acually performed? I couldn't find that place. > [1] https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardN... > [2] http://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.secu... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-627) Elytron introduces SSL/TLS protocol constraints

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-627?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-627: --------------------------------- Priority: Critical (was: Major) > Elytron introduces SSL/TLS protocol constraints > ----------------------------------------------- > > Key: ELY-627 > URL: https://issues.jboss.org/browse/ELY-627 > Project: WildFly Elytron > Issue Type: Bug > Components: SSL > Affects Versions: 1.1.0.Beta8 > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Critical > > {noformat} > "protocols" => { > "type" => LIST, > "description" => "The enabled protocols.", > "expressions-allowed" => true, > "nillable" => false, > "allowed" => [ > "SSLv2", > "SSLv3", > "TLSv1", > "TLSv1_1", > "TLSv1_2", > "TLSv1_3" > ], > "value-type" => STRING, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > {noformat} > Why elytron on this place is going to validate user input and map standard java values [1] into proprietary values? > Whereas on other similar places (KeyManager algorithm, TrustManager algorithm, Keystore types) it leaves up to user to set proper value. > IMO, with such mapping another place, where bugs can raise was introduced. EAP will be here always one step back compared to java. > Note, IBM java already today defines little bit different protocols set [2] > I wonder, where is that mapping "TLSv1_2 -> TLSv1.2" acually performed? I couldn't find that place. > [1] https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardN... > [2] http://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.secu... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1787) Try to add resource with OBJECT type attribute cause IllegalArgumentException

by Alexey Loubyansky (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1787?page=com.atlassian.jira.plugi... ] Alexey Loubyansky reassigned WFCORE-1787: ----------------------------------------- Assignee: Jean-Francois Denise (was: Alexey Loubyansky) Jeff, could you please have a look? Thanks. > Try to add resource with OBJECT type attribute cause IllegalArgumentException > ----------------------------------------------------------------------------- > > Key: WFCORE-1787 > URL: https://issues.jboss.org/browse/WFCORE-1787 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Hynek Švábek > Assignee: Jean-Francois Denise > Priority: Blocker > > Try to add resource with OBJECT type attribute cause IllegalArgumentException. > *Actual result:* > CLI operation failed with IllegalArgumentException > *Expected results:* > Success CLI operation > *My investigation:* > In my opinion is problem caused by this PR to wildfly-core > https://github.com/wildfly/wildfly-core/pull/1698/files#diff-835f377f8fa5... > Look at lines 1333-1350 Util.java -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1788) Allow tests to retrieve IP address of node1

by Jan Martiska (JIRA)

Jan Martiska created WFCORE-1788: ------------------------------------ Summary: Allow tests to retrieve IP address of node1 Key: WFCORE-1788 URL: https://issues.jboss.org/browse/WFCORE-1788 Project: WildFly Core Issue Type: Enhancement Components: Test Suite Affects Versions: 3.0.0.Alpha7 Reporter: Jan Martiska Assignee: Jan Martiska Currently, the {{TestSuiteEnvironment}} only allows to obtain the address of node0. Multinode tests in the wildfly full repository which need to obtain the address of node1, do it in various non-standardized ways, it would be nice to standardize that by adding a method to obtain node1's address and refactoring the tests to use it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-626) Adding simple-permission-mapper with some permission throws NPE

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-626?page=com.atlassian.jira.plugin.sy... ] Jan Kalina moved WFLY-7082 to ELY-626: -------------------------------------- Project: WildFly Elytron (was: WildFly) Key: ELY-626 (was: WFLY-7082) Component/s: Permissions (was: Security) Affects Version/s: (was: 11.0.0.Alpha1) > Adding simple-permission-mapper with some permission throws NPE > --------------------------------------------------------------- > > Key: ELY-626 > URL: https://issues.jboss.org/browse/ELY-626 > Project: WildFly Elytron > Issue Type: Bug > Components: Permissions > Reporter: Ondrej Lukas > Assignee: Jan Kalina > > Adding simple-permission-mapper with ChangeRoleMapperPermission or RunAsPrincipalPermission throws NPE. In case when LoginPermission is used then it works correctly. > {code} > /subsystem=elytron/simple-permission-mapper=SomeMapper:add(permission-mappings=[{roles=[All],permissions=[{class-name="org.wildfly.security.auth.permission.ChangeRoleMapperPermission"}]}]) > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.permission-mapper.SomeMapper" => "org.jboss.msc.service.StartException in service org.wildfly.security.permission-mapper.SomeMapper: Failed to start service > Caused by: java.lang.NullPointerException"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.permission-mapper.SomeMapper"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > }, > "rolled-back" => true > } > {code} > NPE occurs in server log: > {code} > ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service org.wildfly.security.permission-mapper.SomeMapper: org.jboss.msc.service.StartException in service org.wildfly.security.permission-mapper.SomeMapper: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NullPointerException > at org.wildfly.security.permission.ByNamePermissionCollection.doAdd(ByNamePermissionCollection.java:59) > at org.wildfly.security.permission.AbstractPermissionCollection.add(AbstractPermissionCollection.java:83) > at java.security.Permissions.add(Permissions.java:133) > at org.wildfly.extension.elytron.PermissionMapperDefinitions.createSimplePermissionMapper(PermissionMapperDefinitions.java:214) > at org.wildfly.extension.elytron.PermissionMapperDefinitions.access$000(PermissionMapperDefinitions.java:67) > at org.wildfly.extension.elytron.PermissionMapperDefinitions$2.lambda$getValueSupplier$0(PermissionMapperDefinitions.java:188) > at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > ... 3 more > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7082) Adding simple-permission-mapper with some permission throws NPE

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7082?page=com.atlassian.jira.plugin.... ] Jan Kalina commented on WFLY-7082: ---------------------------------- Problem is missing null name check in permission - will be fixed in Elytron. > Adding simple-permission-mapper with some permission throws NPE > --------------------------------------------------------------- > > Key: WFLY-7082 > URL: https://issues.jboss.org/browse/WFLY-7082 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Jan Kalina > > Adding simple-permission-mapper with ChangeRoleMapperPermission or RunAsPrincipalPermission throws NPE. In case when LoginPermission is used then it works correctly. > {code} > /subsystem=elytron/simple-permission-mapper=SomeMapper:add(permission-mappings=[{roles=[All],permissions=[{class-name="org.wildfly.security.auth.permission.ChangeRoleMapperPermission"}]}]) > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.permission-mapper.SomeMapper" => "org.jboss.msc.service.StartException in service org.wildfly.security.permission-mapper.SomeMapper: Failed to start service > Caused by: java.lang.NullPointerException"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.permission-mapper.SomeMapper"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > }, > "rolled-back" => true > } > {code} > NPE occurs in server log: > {code} > ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service org.wildfly.security.permission-mapper.SomeMapper: org.jboss.msc.service.StartException in service org.wildfly.security.permission-mapper.SomeMapper: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NullPointerException > at org.wildfly.security.permission.ByNamePermissionCollection.doAdd(ByNamePermissionCollection.java:59) > at org.wildfly.security.permission.AbstractPermissionCollection.add(AbstractPermissionCollection.java:83) > at java.security.Permissions.add(Permissions.java:133) > at org.wildfly.extension.elytron.PermissionMapperDefinitions.createSimplePermissionMapper(PermissionMapperDefinitions.java:214) > at org.wildfly.extension.elytron.PermissionMapperDefinitions.access$000(PermissionMapperDefinitions.java:67) > at org.wildfly.extension.elytron.PermissionMapperDefinitions$2.lambda$getValueSupplier$0(PermissionMapperDefinitions.java:188) > at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > ... 3 more > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7098) Double check parallel boot and ApplicationSecurityDomain definitions are compatible

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-7098?page=com.atlassian.jira.plugin.... ] Brian Stansberry commented on WFLY-7098: ---------------------------------------- Parallel boot is implemented as 2 steps in the overall set of boot operation steps, with one for Stage.MODEL and one for Stage.RUNTIME. Each step submits tasks that concurrently process ops for their stage. Each task process ops for a single subsystem. The step that submits those tasks blocks and does not complete until all the tasks it has submitted complete. So, the next step in the overall set of boot operation steps does not begin executing until the parallel tasks complete. Deployment ops execute after subsystem steps because until the subsystems have run the DUP chain is not known. > Double check parallel boot and ApplicationSecurityDomain definitions are compatible > ----------------------------------------------------------------------------------- > > Key: WFLY-7098 > URL: https://issues.jboss.org/browse/WFLY-7098 > Project: WildFly > Issue Type: Task > Components: EJB, Web (Undertow) > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 11.0.0.Alpha1 > > > Need to check there is no option for parallel boot to start deploying deployment before the full management model has been processed to the point all known ApplicationSecurityDomain definitions are known for both EJB and Undertow. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1284) KieModuleModel property configurations are not preserved during incremental compilation

by Anton Giertli (JIRA)

Anton Giertli created DROOLS-1284: ------------------------------------- Summary: KieModuleModel property configurations are not preserved during incremental compilation Key: DROOLS-1284 URL: https://issues.jboss.org/browse/DROOLS-1284 Project: Drools Issue Type: Bug Components: core engine Reporter: Anton Giertli Assignee: Mario Fusco Fix For: 6.5.0.Final, 7.0.0.Beta2 When a KieBuilder configuration is set into the kmodule.xml as in the following example, this configuration is not preserved during incremental compilation. {code} <?xml version=\"1.0\" encoding=\"UTF-8\"?> <kmodule xmlns=\"http://jboss.org/kie/6.0.0/kmodule\"> <configuration> <property key=\"drools.propertySpecific\" value=\"ALWAYS\" /> </configuration> </kmodule> {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1787) Try to add resource with OBJECT type attribute cause IllegalArgumentException

by Hynek Švábek (JIRA)

Hynek Švábek created WFCORE-1787: ------------------------------------ Summary: Try to add resource with OBJECT type attribute cause IllegalArgumentException Key: WFCORE-1787 URL: https://issues.jboss.org/browse/WFCORE-1787 Project: WildFly Core Issue Type: Bug Components: CLI Reporter: Hynek Švábek Assignee: Alexey Loubyansky Priority: Blocker Try to add resource with OBJECT type attribute cause IllegalArgumentException. *Actual result:* CLI operation failed with IllegalArgumentException *Expected results:* Success CLI operation *My investigation:* In my opinion is problem caused by this PR to wildfly-core https://github.com/wildfly/wildfly-core/pull/1698/files#diff-835f377f8fa5... Look at lines 1333-1350 Util.java -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1786) SelfContainedContainer: Allow the ConfigurationPersisterFactory to be customised

by Heiko Braun (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1786?page=com.atlassian.jira.plugi... ] Heiko Braun updated WFCORE-1786: -------------------------------- Comment: was deleted (was: It's probably best to expose the Configuration right away) > SelfContainedContainer: Allow the ConfigurationPersisterFactory to be customised > -------------------------------------------------------------------------------- > > Key: WFCORE-1786 > URL: https://issues.jboss.org/browse/WFCORE-1786 > Project: WildFly Core > Issue Type: Feature Request > Components: Server > Reporter: Heiko Braun > Assignee: Heiko Braun > Fix For: 3.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1786) SelfContainedContainer: Allow the ConfigurationPersisterFactory to be customised

by Heiko Braun (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1786?page=com.atlassian.jira.plugi... ] Heiko Braun commented on WFCORE-1786: ------------------------------------- It's probably best to expose the Configuration right away > SelfContainedContainer: Allow the ConfigurationPersisterFactory to be customised > -------------------------------------------------------------------------------- > > Key: WFCORE-1786 > URL: https://issues.jboss.org/browse/WFCORE-1786 > Project: WildFly Core > Issue Type: Feature Request > Components: Server > Reporter: Heiko Braun > Assignee: Heiko Braun > Fix For: 3.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7101) Wildfly 10.1.0 blocks calls to Singleton EJBs in PostConstruct

by jaikiran pai (JIRA)

[ https://issues.jboss.org/browse/WFLY-7101?page=com.atlassian.jira.plugin.... ] jaikiran pai moved WFCORE-1782 to WFLY-7101: -------------------------------------------- Project: WildFly (was: WildFly Core) Key: WFLY-7101 (was: WFCORE-1782) Component/s: EJB (was: Server) Affects Version/s: 10.1.0.Final (was: 2.2.0.Final) Fix Version/s: (was: 2.2.1.Final) > Wildfly 10.1.0 blocks calls to Singleton EJBs in PostConstruct > -------------------------------------------------------------- > > Key: WFLY-7101 > URL: https://issues.jboss.org/browse/WFLY-7101 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.1.0.Final > Environment: Wildfly 10.1.0 running under Windows 10 with Java 1.8.0_91 > Reporter: Dietrich Schmidt > Assignee: Jason Greene > Attachments: Verklemmung.zip > > > Wildfly 8.2.0 and 10.0.0 work fine with a Singleton Bean, which has a @Postconstruct method and in this method several threads are created with the ManagedExecutorService. These threads call a method in another Singleton EJB, which has been injected. > This call is blocked in Wildfly 10.1.0 until the Prostconstruct thread has ended. > I assume that the behaviour of Wildfly 8.2.0 + 10.0.0 is correct and the behaviour of Wildfly 10.1.0 is a bug. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1742) Allow registering a custom handler for management interface

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1742?page=com.atlassian.jira.plugi... ] Sebastian Łaskawiec commented on WFCORE-1742: --------------------------------------------- Infinispan also has a custom management console for the record. I think a short limited mapping api would be ok (at least for us). Something like map this long URI to this short URI. It gets slightly more interesting when we need to change HTTP methods - e.g. showing runtime resources requires sending HTTP PUT (not GET)... > Allow registering a custom handler for management interface > ----------------------------------------------------------- > > Key: WFCORE-1742 > URL: https://issues.jboss.org/browse/WFCORE-1742 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Sebastian Łaskawiec > > When building [HealthCheck API for Infisnispan|https://github.com/infinispan/infinispan/pull/4499] we noticed there is no way to register a custom endpoint on Management REST interface. Without it, calling the API requires using HTTP POST method (since it includes runtime parameters) and the URL is very long (and not intuitive for our users): > {noformat} > curl --digest -L -D - "http://localhost:9990/management/subsystem/datagrid-infinispan/cache-cont..." --header "Content-Type: application/json" -u ispnadmin:ispnadmin > HTTP/1.1 401 Unauthorized > Connection: keep-alive > WWW-Authenticate: Digest realm="ManagementRealm",domain="/management",nonce="AuZzFxz7uC4NMTQ3MDgyNTU1NTQ3OCfIJBHXVpPHPBdzGUy7Qts=",opaque="00000000000000000000000000000000",algorithm=MD5,qop="auth" > Content-Length: 77 > Content-Type: text/html > Date: Wed, 10 Aug 2016 10:39:15 GMT > HTTP/1.1 200 OK > Connection: keep-alive > Authentication-Info: nextnonce="AuZzFxz7uC4NMTQ3MDgyNTU1NTQ3OCfIJBHXVpPHPBdzGUy7Qts=",qop="auth",rspauth="b518c3170e627bd732055c382ce5d970",cnonce="NGViOWM0NDY5OGJmNjY0MjcyOWE4NDkyZDU3YzNhYjY=",nc=00000001 > Content-Type: application/json; charset=utf-8 > Content-Length: 1927 > Date: Wed, 10 Aug 2016 10:39:15 GMT > { > "cache-health" : "GREEN", > "cluster-health" : ["test"], > "cluster-name" : "clustered", > "free-memory" : 96778, > "log-tail" : [ > "2016-08-10 11:54:14,706 INFO [org.infinispan.server.endpoint] (MSC service thread 1-5) DGENDPT10001: HotRodServer listening on 127.0.0.1:11222", > "2016-08-10 11:54:14,706 INFO [org.infinispan.server.endpoint] (MSC service thread 1-1) DGENDPT10001: MemcachedServer listening on 127.0.0.1:11211", > "2016-08-10 11:54:14,785 INFO [org.jboss.as.clustering.infinispan] (MSC service thread 1-6) DGISPN0001: Started ___protobuf_metadata cache from clustered container", > "2016-08-10 11:54:14,800 INFO [org.jboss.as.clustering.infinispan] (MSC service thread 1-6) DGISPN0001: Started ___script_cache cache from clustered container", > "2016-08-10 11:54:15,159 INFO [org.jboss.as.clustering.infinispan] (MSC service thread 1-5) DGISPN0001: Started ___hotRodTopologyCache cache from clustered container", > "2016-08-10 11:54:15,210 INFO [org.infinispan.rest.NettyRestServer] (MSC service thread 1-6) ISPN012003: REST server starting, listening on 127.0.0.1:8080", > "2016-08-10 11:54:15,210 INFO [org.infinispan.server.endpoint] (MSC service thread 1-6) DGENDPT10002: REST mapped to /rest", > "2016-08-10 11:54:15,306 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management", > "2016-08-10 11:54:15,307 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990", > "2016-08-10 11:54:15,307 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: Infinispan Server 9.0.0-SNAPSHOT (WildFly Core 2.2.0.CR9) started in 8681ms - Started 196 of 237 services (121 services are lazy, passive or on-demand)" > ], > "number-of-cpus" : 8, > "number-of-nodes" : 1, > "total-memory" : 235520 > }% > {noformat} > It would be very convenient to allow exposing such endpoints with optional authorization and using custom URLs (e.g. something like http://localhost:9990/health). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1786) SelfContainedContainer: Allow the ConfigurationPersisterFactory to be customised

by Heiko Braun (JIRA)

Heiko Braun created WFCORE-1786: ----------------------------------- Summary: SelfContainedContainer: Allow the ConfigurationPersisterFactory to be customised Key: WFCORE-1786 URL: https://issues.jboss.org/browse/WFCORE-1786 Project: WildFly Core Issue Type: Feature Request Components: Server Reporter: Heiko Braun Assignee: Heiko Braun Fix For: 3.0.0.Beta1 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1786) SelfContainedContainer: Allow the ConfigurationPersisterFactory to be customised

by Heiko Braun (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1786?page=com.atlassian.jira.plugi... ] Heiko Braun commented on WFCORE-1786: ------------------------------------- Needs a backport to 2.x > SelfContainedContainer: Allow the ConfigurationPersisterFactory to be customised > -------------------------------------------------------------------------------- > > Key: WFCORE-1786 > URL: https://issues.jboss.org/browse/WFCORE-1786 > Project: WildFly Core > Issue Type: Feature Request > Components: Server > Reporter: Heiko Braun > Assignee: Heiko Braun > Fix For: 3.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7096) Security domain casche dosn't respect infinispan settings

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7096?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-7096: ---------------------------------------- The Infinispan cache setting is something left over from initial development in 2011 - to properly support Infinispan based caching both the cache container and the name of the cache would need to be configurable within the security subystem. > Security domain casche dosn't respect infinispan settings > --------------------------------------------------------- > > Key: WFLY-7096 > URL: https://issues.jboss.org/browse/WFLY-7096 > Project: WildFly > Issue Type: Feature Request > Components: Security > Affects Versions: 10.0.0.Final, 10.1.0.Final > Environment: Tested on Windows 7 > Reporter: Marcin Fatyga > Assignee: Darran Lofthouse > Attachments: patch.txt, standalone.xml, test_webapp.zip > > > In securitydomain we can set "casche-type" to infinispan. Auntentication request ara now stored in infinispan casch, but any settings of this casche (configured in infinispan subsystem) are not applied. Casche is always stored in memory and never expiries. > This is serious security issue because after first authentication request credentials, will never be verified again. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7096) Security domain casche dosn't respect infinispan settings

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7096?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-7096: ----------------------------------- Issue Type: Feature Request (was: Bug) > Security domain casche dosn't respect infinispan settings > --------------------------------------------------------- > > Key: WFLY-7096 > URL: https://issues.jboss.org/browse/WFLY-7096 > Project: WildFly > Issue Type: Feature Request > Components: Security > Affects Versions: 10.0.0.Final, 10.1.0.Final > Environment: Tested on Windows 7 > Reporter: Marcin Fatyga > Assignee: Darran Lofthouse > Attachments: patch.txt, standalone.xml, test_webapp.zip > > > In securitydomain we can set "casche-type" to infinispan. Auntentication request ara now stored in infinispan casch, but any settings of this casche (configured in infinispan subsystem) are not applied. Casche is always stored in memory and never expiries. > This is serious security issue because after first authentication request credentials, will never be verified again. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7096) Security domain casche dosn't respect infinispan settings

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7096?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-7096: ----------------------------------- Security Sensitive Issue: (was: This issue is security relevant) > Security domain casche dosn't respect infinispan settings > --------------------------------------------------------- > > Key: WFLY-7096 > URL: https://issues.jboss.org/browse/WFLY-7096 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 10.0.0.Final, 10.1.0.Final > Environment: Tested on Windows 7 > Reporter: Marcin Fatyga > Assignee: Darran Lofthouse > Attachments: patch.txt, standalone.xml, test_webapp.zip > > > In securitydomain we can set "casche-type" to infinispan. Auntentication request ara now stored in infinispan casch, but any settings of this casche (configured in infinispan subsystem) are not applied. Casche is always stored in memory and never expiries. > This is serious security issue because after first authentication request credentials, will never be verified again. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7096) Security domain casche dosn't respect infinispan settings

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7096?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-7096: ----------------------------------- Security: (was: Security Issue) > Security domain casche dosn't respect infinispan settings > --------------------------------------------------------- > > Key: WFLY-7096 > URL: https://issues.jboss.org/browse/WFLY-7096 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 10.0.0.Final, 10.1.0.Final > Environment: Tested on Windows 7 > Reporter: Marcin Fatyga > Assignee: Darran Lofthouse > Attachments: patch.txt, standalone.xml, test_webapp.zip > > > In securitydomain we can set "casche-type" to infinispan. Auntentication request ara now stored in infinispan casch, but any settings of this casche (configured in infinispan subsystem) are not applied. Casche is always stored in memory and never expiries. > This is serious security issue because after first authentication request credentials, will never be verified again. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7082) Adding simple-permission-mapper with some permission throws NPE

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7082?page=com.atlassian.jira.plugin.... ] Jan Kalina commented on WFLY-7082: ---------------------------------- Problem is in missing *target-name* attribute: {code:xml} <permission class-name="org.wildfly.security.auth.permission.ChangeRoleMapperPermission" target-name="test" /> {code} Without it ChangeRoleMapperPermission.getName() returns null, which is not acceptable by *ByNamePermissionCollection*. I will improve error handling. > Adding simple-permission-mapper with some permission throws NPE > --------------------------------------------------------------- > > Key: WFLY-7082 > URL: https://issues.jboss.org/browse/WFLY-7082 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Jan Kalina > > Adding simple-permission-mapper with ChangeRoleMapperPermission or RunAsPrincipalPermission throws NPE. In case when LoginPermission is used then it works correctly. > {code} > /subsystem=elytron/simple-permission-mapper=SomeMapper:add(permission-mappings=[{roles=[All],permissions=[{class-name="org.wildfly.security.auth.permission.ChangeRoleMapperPermission"}]}]) > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.permission-mapper.SomeMapper" => "org.jboss.msc.service.StartException in service org.wildfly.security.permission-mapper.SomeMapper: Failed to start service > Caused by: java.lang.NullPointerException"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.permission-mapper.SomeMapper"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > }, > "rolled-back" => true > } > {code} > NPE occurs in server log: > {code} > ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service org.wildfly.security.permission-mapper.SomeMapper: org.jboss.msc.service.StartException in service org.wildfly.security.permission-mapper.SomeMapper: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NullPointerException > at org.wildfly.security.permission.ByNamePermissionCollection.doAdd(ByNamePermissionCollection.java:59) > at org.wildfly.security.permission.AbstractPermissionCollection.add(AbstractPermissionCollection.java:83) > at java.security.Permissions.add(Permissions.java:133) > at org.wildfly.extension.elytron.PermissionMapperDefinitions.createSimplePermissionMapper(PermissionMapperDefinitions.java:214) > at org.wildfly.extension.elytron.PermissionMapperDefinitions.access$000(PermissionMapperDefinitions.java:67) > at org.wildfly.extension.elytron.PermissionMapperDefinitions$2.lambda$getValueSupplier$0(PermissionMapperDefinitions.java:188) > at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > ... 3 more > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6596) WrongClassException when using infinispan as remote-store for hibernate entity cache

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/WFLY-6596?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on WFLY-6596: ----------------------------------- [~gvwolf3d] Uh, that's quite a low hit ratio! But if that still improves the performance, be it... I understand that with 16 app machines any load removed from the single DB machine counts. Btw., if you want to have some nodes less loaded but still part of the cluster, distributed caches offer a way to set that some nodes contain less (or even none) data, see http://infinispan.org/docs/8.1.x/user_guide/user_guide.html#capacity_factors (this does not apply to invalidation caches as these contain all data that has been read and not invalidated). Just FYI. > WrongClassException when using infinispan as remote-store for hibernate entity cache > ------------------------------------------------------------------------------------ > > Key: WFLY-6596 > URL: https://issues.jboss.org/browse/WFLY-6596 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 10.0.0.Final, 10.1.0.Final > Environment: Java version: 1.8.0_45, vendor: Oracle Corporation > Java home: C:\Program Files\Java\jdk1.8.0_45\jre > Default locale: de_DE, platform encoding: Cp1252 > OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "dos" > Infifnspan 8.1.2 or 8.2.0 > Reporter: Gunther v. Wolffersdorff > Assignee: Scott Marlow > Labels: inifinispan-commons, org.hibernate.WrongClassException, remote-store > Attachments: ClassicalCacheKeysFactory.java, clustered.sample.xml, infinispan.zip, sample-10.1.0.Final-2.zip, sample-10.1.0.Final-fix.zip, sample-10.1.0.Final.zip, sample.zip, standalone.sample.ha-10.1.0.Final.xml, standalone.sample.ha.xml > > > Starting an application and then requesting a list of cachable JPA entitties ( configured cachable using a hibernate entity invalidation-cache with a remote-server as remote-store ) causes: > {code} > 13:00:52,541 MESZ ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /sample-web/rest/members/listAll: org.jboss.resteasy.spi.UnhandledException: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=100] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member > at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:77) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:220) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:418) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_66] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_66] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66] > Caused by: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member > at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1692) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1602) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:492) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.jpa.criteria.compile.CriteriaQueryTypeQueryAdapter.getResultList(CriteriaQueryTypeQueryAdapter.java:50) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final] > at org.jboss.as.jpa.container.TypedQueryNonTxInvocationDetacher.getResultList(TypedQueryNonTxInvocationDetacher.java:58) [wildfly-jpa-10.1.0.Final.jar:10.1.0.Final] > at de.alvara.ticket.sample.data.MemberRepository.findAllOrderedByName(MemberRepository.java:58) [sample-ejb.jar:] > at de.alvara.ticket.sample.data.MemberRepository$Proxy$_$$_WeldClientProxy.findAllOrderedByName(Unknown Source) [sample-ejb.jar:] > at de.alvara.ticket.sample.rest.MemberResourceRESTService.listAllMembers(MemberResourceRESTService.java:75) [classes:] > at de.alvara.ticket.sample.rest.MemberResourceRESTService$Proxy$_$$_WeldClientProxy.listAllMembers(Unknown Source) [classes:] > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_66] > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_66] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_66] > at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_66] > at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > ... 43 more > Caused by: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member > at org.hibernate.event.internal.DefaultLoadEventListener.processCachedEntry(DefaultLoadEventListener.java:631) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.loadFromSecondLevelCache(DefaultLoadEventListener.java:602) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:462) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:219) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:278) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.doOnLoad(DefaultLoadEventListener.java:121) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:89) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1129) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.internal.SessionImpl.internalLoad(SessionImpl.java:1022) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:632) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.type.EntityType.resolve(EntityType.java:424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:154) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:128) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:1133) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.processResultSet(Loader.java:992) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.doQuery(Loader.java:930) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:336) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.doList(Loader.java:2617) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.doList(Loader.java:2600) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2429) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.list(Loader.java:2424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:501) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:371) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:216) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1326) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.internal.QueryImpl.list(QueryImpl.java:87) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.jpa.internal.QueryImpl.list(QueryImpl.java:606) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:483) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final] > ... 58 more > {code} > Entity cache is configured like this: > {code:xml} > ... > <invalidation-cache name="entity" mode="SYNC"> > <eviction strategy="LRU" max-entries="1000"/> > <expiration lifespan="45000" max-idle="30000"/> > <remote-store cache="hibernateDistributed" socket-timeout="60000" tcp-no-delay="true" remote-servers="local-cache-server" fetch-state="false" passivation="false" preload="false" purge="true" shared="true"/> > </invalidation-cache> > ... > <outbound-socket-binding name="local-cache-server"> > <remote-destination host="${jboss.bind.address:127.0.0.1}" port="11322"/> > </outbound-socket-binding> > ... > {code} > see standalone.sample.ha-10.1.0.Final.xml . > *This constellation works fine using Wildfly 8.2.0 and Infinispan 7.2.5 .* -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7100) Reimplement Singleton services using JGroups instead of Infinispan

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-7100: ---------------------------------- Summary: Reimplement Singleton services using JGroups instead of Infinispan Key: WFLY-7100 URL: https://issues.jboss.org/browse/WFLY-7100 Project: WildFly Issue Type: Enhancement Components: Clustering Affects Versions: 10.1.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 11.0.0.Alpha1 The singleton subsystem currently requires the Infinispan subsystem. To minimize the requirements for using the singleton subsystem within the context of the host-controller, we should reimplement singleton service using JGroups directly, instead of requiring an Infinispan cache. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6981) Upgrade Weld to 2.4.0.Final

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/WFLY-6981?page=com.atlassian.jira.plugin.... ] Martin Kouba updated WFLY-6981: ------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/9185 (was: https://github.com/wildfly/wildfly/pull/9145) > Upgrade Weld to 2.4.0.Final > --------------------------- > > Key: WFLY-6981 > URL: https://issues.jboss.org/browse/WFLY-6981 > Project: WildFly > Issue Type: Component Upgrade > Components: CDI / Weld > Reporter: Martin Kouba > Assignee: Martin Kouba > Fix For: 11.0.0.Alpha1 > > > See also http://weld.cdi-spec.org/news/2016/08/19/weld-240CR1/. > Also remove the dependency on {{com.google.guava:guava}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7099) Database connection on POSTGRE required max_prepared_statement

by Tom Jenkinson (JIRA)

Tom Jenkinson created WFLY-7099: ----------------------------------- Summary: Database connection on POSTGRE required max_prepared_statement Key: WFLY-7099 URL: https://issues.jboss.org/browse/WFLY-7099 Project: WildFly Issue Type: Bug Components: Transactions Affects Versions: 8.2.0.Final Reporter: Tom Jenkinson Assignee: Tom Jenkinson Priority: Minor max_prepared_statement is required on the file (postgre.conf) to connect on pgsql base. If this option wasn't activate, the method end is called twice on PGXAConnection Please find below original discussion : https://developer.jboss.org/message/958507#958507 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7098) Double check parallel boot and ApplicationSecurityDomain definitions are compatible

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFLY-7098: -------------------------------------- Summary: Double check parallel boot and ApplicationSecurityDomain definitions are compatible Key: WFLY-7098 URL: https://issues.jboss.org/browse/WFLY-7098 Project: WildFly Issue Type: Task Components: EJB, Web (Undertow) Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 11.0.0.Alpha1 Need to check there is no option for parallel boot to start deploying deployment before the full management model has been processed to the point all known ApplicationSecurityDomain definitions are known for both EJB and Undertow. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6596) WrongClassException when using infinispan as remote-store for hibernate entity cache

by Gunther v. Wolffersdorff (JIRA)

[ https://issues.jboss.org/browse/WFLY-6596?page=com.atlassian.jira.plugin.... ] Gunther v. Wolffersdorff commented on WFLY-6596: ------------------------------------------------ [~rvansa] The infinispan cluster overall average values are: hitRation: 0.178, readWriteRatio: 1.395 , numberOfEntities: 20000 (at each node) We started just with near 2LC only ( not running a infinispan cluster). Starting with the need of some custom caches we also added the remote store to the hibermnate cache container. At this moment we had a local-cache holding 1000 entries and a remote-store. We do not recongnized any performance problems but some inconsistences because of the local-cache (which is not synchronized). So we switched the local-cache to an small (near) invalidation-cache (having still a remote-store configured). Another reason for moving the hibernate entity cache to a remote store is that we can have a different number of wildfly and cache nodes. Without a separate cache cluster each new wildfly node is also a new cache node. So the communication effort between the wildfly nodes increases. A separated cache cluster can have e.g. still 4 nodes while the wildfly cluster grows up to 16 nodes. > WrongClassException when using infinispan as remote-store for hibernate entity cache > ------------------------------------------------------------------------------------ > > Key: WFLY-6596 > URL: https://issues.jboss.org/browse/WFLY-6596 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 10.0.0.Final, 10.1.0.Final > Environment: Java version: 1.8.0_45, vendor: Oracle Corporation > Java home: C:\Program Files\Java\jdk1.8.0_45\jre > Default locale: de_DE, platform encoding: Cp1252 > OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "dos" > Infifnspan 8.1.2 or 8.2.0 > Reporter: Gunther v. Wolffersdorff > Assignee: Scott Marlow > Labels: inifinispan-commons, org.hibernate.WrongClassException, remote-store > Attachments: ClassicalCacheKeysFactory.java, clustered.sample.xml, infinispan.zip, sample-10.1.0.Final-2.zip, sample-10.1.0.Final-fix.zip, sample-10.1.0.Final.zip, sample.zip, standalone.sample.ha-10.1.0.Final.xml, standalone.sample.ha.xml > > > Starting an application and then requesting a list of cachable JPA entitties ( configured cachable using a hibernate entity invalidation-cache with a remote-server as remote-store ) causes: > {code} > 13:00:52,541 MESZ ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /sample-web/rest/members/listAll: org.jboss.resteasy.spi.UnhandledException: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=100] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member > at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:77) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:220) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:418) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_66] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_66] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66] > Caused by: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member > at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1692) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1602) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:492) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.jpa.criteria.compile.CriteriaQueryTypeQueryAdapter.getResultList(CriteriaQueryTypeQueryAdapter.java:50) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final] > at org.jboss.as.jpa.container.TypedQueryNonTxInvocationDetacher.getResultList(TypedQueryNonTxInvocationDetacher.java:58) [wildfly-jpa-10.1.0.Final.jar:10.1.0.Final] > at de.alvara.ticket.sample.data.MemberRepository.findAllOrderedByName(MemberRepository.java:58) [sample-ejb.jar:] > at de.alvara.ticket.sample.data.MemberRepository$Proxy$_$$_WeldClientProxy.findAllOrderedByName(Unknown Source) [sample-ejb.jar:] > at de.alvara.ticket.sample.rest.MemberResourceRESTService.listAllMembers(MemberResourceRESTService.java:75) [classes:] > at de.alvara.ticket.sample.rest.MemberResourceRESTService$Proxy$_$$_WeldClientProxy.listAllMembers(Unknown Source) [classes:] > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_66] > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_66] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_66] > at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_66] > at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > ... 43 more > Caused by: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member > at org.hibernate.event.internal.DefaultLoadEventListener.processCachedEntry(DefaultLoadEventListener.java:631) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.loadFromSecondLevelCache(DefaultLoadEventListener.java:602) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:462) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:219) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:278) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.doOnLoad(DefaultLoadEventListener.java:121) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:89) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1129) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.internal.SessionImpl.internalLoad(SessionImpl.java:1022) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:632) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.type.EntityType.resolve(EntityType.java:424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:154) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:128) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:1133) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.processResultSet(Loader.java:992) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.doQuery(Loader.java:930) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:336) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.doList(Loader.java:2617) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.doList(Loader.java:2600) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2429) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.list(Loader.java:2424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:501) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:371) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:216) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1326) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.internal.QueryImpl.list(QueryImpl.java:87) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.jpa.internal.QueryImpl.list(QueryImpl.java:606) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:483) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final] > ... 58 more > {code} > Entity cache is configured like this: > {code:xml} > ... > <invalidation-cache name="entity" mode="SYNC"> > <eviction strategy="LRU" max-entries="1000"/> > <expiration lifespan="45000" max-idle="30000"/> > <remote-store cache="hibernateDistributed" socket-timeout="60000" tcp-no-delay="true" remote-servers="local-cache-server" fetch-state="false" passivation="false" preload="false" purge="true" shared="true"/> > </invalidation-cache> > ... > <outbound-socket-binding name="local-cache-server"> > <remote-destination host="${jboss.bind.address:127.0.0.1}" port="11322"/> > </outbound-socket-binding> > ... > {code} > see standalone.sample.ha-10.1.0.Final.xml . > *This constellation works fine using Wildfly 8.2.0 and Infinispan 7.2.5 .* -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1283) Memory leak using KieBuilder.build() method.

by Tibor Zimányi (JIRA)

Tibor Zimányi created DROOLS-1283: ------------------------------------- Summary: Memory leak using KieBuilder.build() method. Key: DROOLS-1283 URL: https://issues.jboss.org/browse/DROOLS-1283 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 6.5.0.CR1 Reporter: Tibor Zimányi Assignee: Mario Fusco There is a memory leak when building KieBase using KieBuilder.build() method. When continuously calling kieBuilder.build() (also with no resources), the OOM exception occurs. I will make PR with a reproducer for this. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7097) The constant-role-mapper is not able to handle role name with space in it

by Josef Cacek (JIRA)

Josef Cacek created WFLY-7097: --------------------------------- Summary: The constant-role-mapper is not able to handle role name with space in it Key: WFLY-7097 URL: https://issues.jboss.org/browse/WFLY-7097 Project: WildFly Issue Type: Bug Components: Security Reporter: Josef Cacek Assignee: Darran Lofthouse Priority: Critical Adding a role with a space in the name results in 2 roles (for parts of the name) added. The problem is visible after server reload. E.g. adding role "JBoss Admin" results in 2 roles assigned "JBoss" and "Admin" *Expected behavior* Spaces in role name must be supported and correctly handled. E.g. After adding "JBoss Admin" and server reload "JBoss Admin" is assigned. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7076) Elytron introduces SSL/TLS protocol constraints

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7076?page=com.atlassian.jira.plugin.... ] Jan Kalina commented on WFLY-7076: ---------------------------------- *To discuss:* Should be Protocol enum removed and Strings used instead? (Alternative: only allow standard names ("TLSv1.2") and add Oracle protocol names) > Elytron introduces SSL/TLS protocol constraints > ----------------------------------------------- > > Key: WFLY-7076 > URL: https://issues.jboss.org/browse/WFLY-7076 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Jan Kalina > > {noformat} > "protocols" => { > "type" => LIST, > "description" => "The enabled protocols.", > "expressions-allowed" => true, > "nillable" => false, > "allowed" => [ > "SSLv2", > "SSLv3", > "TLSv1", > "TLSv1_1", > "TLSv1_2", > "TLSv1_3" > ], > "value-type" => STRING, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > {noformat} > Why elytron on this place is going to validate user input and map standard java values [1] into proprietary values? > Whereas on other similar places (KeyManager algorithm, TrustManager algorithm, Keystore types) it leaves up to user to set proper value. > IMO, with such mapping another place, where bugs can raise was introduced. EAP will be here always one step back compared to java. > Note, IBM java already today defines little bit different protocols set [2] > I wonder, where is that mapping "TLSv1_2 -> TLSv1.2" acually performed? I couldn't find that place. > [1] https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardN... > [2] http://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.secu... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1282) KieModuleModel property configurations are not preserved during incremental compilation

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-1282: ----------------------------------- Summary: KieModuleModel property configurations are not preserved during incremental compilation Key: DROOLS-1282 URL: https://issues.jboss.org/browse/DROOLS-1282 Project: Drools Issue Type: Bug Components: core engine Reporter: Mario Fusco Assignee: Mario Fusco When a KieBuilder configuration is set into the kmodule.xml as in the following example, this configuration is not preserved during incremental compilation. {code} <?xml version=\"1.0\" encoding=\"UTF-8\"?> <kmodule xmlns=\"http://jboss.org/kie/6.0.0/kmodule\"> <configuration> <property key=\"drools.propertySpecific\" value=\"ALWAYS\" /> </configuration> </kmodule> {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6748) Database connection on POSTGRE required max_prepared_statement

by Florian Mélot (JIRA)

[ https://issues.jboss.org/browse/WFLY-6748?page=com.atlassian.jira.plugin.... ] Florian Mélot commented on WFLY-6748: ------------------------------------- Pached tested, it's work fine. > Database connection on POSTGRE required max_prepared_statement > -------------------------------------------------------------- > > Key: WFLY-6748 > URL: https://issues.jboss.org/browse/WFLY-6748 > Project: WildFly > Issue Type: Bug > Components: Transactions > Affects Versions: 8.2.0.Final > Reporter: Florian Mélot > Assignee: Tom Jenkinson > Priority: Minor > > max_prepared_statement is required on the file (postgre.conf) to connect on pgsql base. > If this option wasn't activate, the method end is called twice on PGXAConnection > Please find below original discussion : > https://developer.jboss.org/message/958507#958507 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1728) Pretty-printing XML validation errors

by Toby Crawley (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1728?page=com.atlassian.jira.plugi... ] Toby Crawley commented on WFCORE-1728: -------------------------------------- I've pushed a [PR|https://github.com/wildfly/wildfly-core/pull/1791] for this, and have [output samples|https://gist.github.com/d3aecbeb4f430a17fb0ec8ccb55da6f6] for all of the [example configs|https://github.com/projectodd/vdx/tree/master/wildfly/src/test/re...]. > Pretty-printing XML validation errors > ------------------------------------- > > Key: WFCORE-1728 > URL: https://issues.jboss.org/browse/WFCORE-1728 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management, Server > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > Toby Crawley from Bob McWhirter's team has developed a small library for creating nicer feedback messages when xml parsing errors are found, based on analysis of the xsd.[1] He has done some work on integrating this library into WildFly for parsing the server/domain config documents and has proposed adding it in.[2] > [1] http://post-office.corp.redhat.com/archives/jboss-tag-public/2016-June/ms... > [2] http://lists.jboss.org/pipermail/wildfly-dev/2016-July/005280.html -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2092) MERGE3: merge never happens

by Neal Dillman (JIRA)

[ https://issues.jboss.org/browse/JGRP-2092?page=com.atlassian.jira.plugin.... ] Neal Dillman commented on JGRP-2092: ------------------------------------ This scenario happened several times in our lab. We no longer see the issue as it was worked around with staggering responses for all of the "bulk response" messages (ie: view change, etc). However, I believe that this could happen again with a marge enough network and low enough bandwidth. In other words my ounce of prevention is working out, be the pound of cure would still be the best solution. I had created a unit test as well and hound the same results. We also ran into partial scenarios where the consistency checker was being run by one functioning coordinator, but other, non-functioning coordinators would not respond to the merge and/or the coordinator running the checker did not think it should be merge leader. In all cases the issue is complicated by the fact that none of the non-coordinators will trust a new coordinator that is not a member of their group. I believe that a solution will involve the 2nd rank host (and maybe the 3rd?) running a checker to see if the coordinator's viewInfo shows the coordinator as thinking it is, in fact, a coordinator. > MERGE3: merge never happens > --------------------------- > > Key: JGRP-2092 > URL: https://issues.jboss.org/browse/JGRP-2092 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.11, 4.0 > > Attachments: jgroups.txt > > > (Reported by Neal Dillman) > In the case below, a merge doesn't seem to happen. Write a unit test to reprodue this. > {noformat} > Host A view: B, X, Y, Z, A (where B should be coordinator) > Host B view: C, Q, R, S, B (where C should be coordinator) > Host C view: A, M, N, O, C (where A should be coordinator) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7094) Too much code duplication between AddStepHandler and BoottimeAddStepHandler

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-7094: ---------------------------------- Summary: Too much code duplication between AddStepHandler and BoottimeAddStepHandler Key: WFLY-7094 URL: https://issues.jboss.org/browse/WFLY-7094 Project: WildFly Issue Type: Enhancement Components: Clustering Affects Versions: 10.0.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 11.0.0.Alpha1 As the logic in AddStepHandler grows, it needs to be duplicated by BoottimeAddStepHandler, since BoottimeAddStepHandler extends AbstractBoottimeAddStepHandler. To simplify maintenance of these classes, we should have BoottimeAddStepHandler extend AddStepHandler instead, and reimplement the logic from AbstractBoottimeAddStepHandler. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2092) MERGE3: merge never happens

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2092?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2092: -------------------------------- The unit test in MergeTest5 > MERGE3: merge never happens > --------------------------- > > Key: JGRP-2092 > URL: https://issues.jboss.org/browse/JGRP-2092 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.11, 4.0 > > Attachments: jgroups.txt > > > (Reported by Neal Dillman) > In the case below, a merge doesn't seem to happen. Write a unit test to reprodue this. > {noformat} > Host A view: B, X, Y, Z, A (where B should be coordinator) > Host B view: C, Q, R, S, B (where C should be coordinator) > Host C view: A, M, N, O, C (where A should be coordinator) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2092) MERGE3: merge never happens

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2092?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-2092 at 9/12/16 11:58 AM: ---------------------------------------------------------- [~ndillman] How did you arrive at this scenario? Did this happen in real life, or did you bring the system into this state on purpose, e.g. in testing? I never thought of such a scenario, but of course I need to address it... The first problem is that since nobody is the coordinator or its local view, nobody will start the view consistency checker task which checks for inconsistent views. The second issue is that even if a view consistency check task was started (e.g. via JMX), it would run a similar check as the one above and never become the _merge leader_! was (Author: belaban): [~ndillman] How did you arrive at this scenario? Did this happen in real life, or did you bring the system into this state on purpose, e.g. in testing? I never thought of such a scenario, but of course I need to address it... > MERGE3: merge never happens > --------------------------- > > Key: JGRP-2092 > URL: https://issues.jboss.org/browse/JGRP-2092 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.11, 4.0 > > Attachments: jgroups.txt > > > (Reported by Neal Dillman) > In the case below, a merge doesn't seem to happen. Write a unit test to reprodue this. > {noformat} > Host A view: B, X, Y, Z, A (where B should be coordinator) > Host B view: C, Q, R, S, B (where C should be coordinator) > Host C view: A, M, N, O, C (where A should be coordinator) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2092) MERGE3: merge never happens

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2092?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2092: -------------------------------- [~ndillman] How did you arrive at this scenario? Did this happen in real life, or did you bring the system into this state on purpose, e.g. in testing? I never thought of such a scenario, but of course I need to address it... > MERGE3: merge never happens > --------------------------- > > Key: JGRP-2092 > URL: https://issues.jboss.org/browse/JGRP-2092 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.11, 4.0 > > Attachments: jgroups.txt > > > (Reported by Neal Dillman) > In the case below, a merge doesn't seem to happen. Write a unit test to reprodue this. > {noformat} > Host A view: B, X, Y, Z, A (where B should be coordinator) > Host B view: C, Q, R, S, B (where C should be coordinator) > Host C view: A, M, N, O, C (where A should be coordinator) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2092) MERGE3: merge never happens

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2092?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2092: -------------------------------- So no member has a view in which it is the actual coordinator... We can probably shorten this to: {noformat} A: BAC B: CAB C: ABC {noformat}, and would still get the same result. I need to verify this, as it would make testing simpler. This definitely breaks {{MERGE3}} as no member will ever assume the task of merge leader as {{view[first] == local_addr}} will always be false! > MERGE3: merge never happens > --------------------------- > > Key: JGRP-2092 > URL: https://issues.jboss.org/browse/JGRP-2092 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.11, 4.0 > > Attachments: jgroups.txt > > > (Reported by Neal Dillman) > In the case below, a merge doesn't seem to happen. Write a unit test to reprodue this. > {noformat} > Host A view: B, X, Y, Z, A (where B should be coordinator) > Host B view: C, Q, R, S, B (where C should be coordinator) > Host C view: A, M, N, O, C (where A should be coordinator) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3636) Improve monitoring of JMS pooled connection in JBoss CLI

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-3636?page=com.atlassian.jira.plugin.... ] Jeff Mesnil updated WFLY-3636: ------------------------------ Fix Version/s: 11.0.0.Alpha1 > Improve monitoring of JMS pooled connection in JBoss CLI > -------------------------------------------------------- > > Key: WFLY-3636 > URL: https://issues.jboss.org/browse/WFLY-3636 > Project: WildFly > Issue Type: Feature Request > Components: JMS > Affects Versions: 8.1.0.Final > Environment: JBoss EAP 6.x > Reporter: Tom Ross > Assignee: Jeff Mesnil > Fix For: 11.0.0.Alpha1 > > > At the moment there is no way of monitoring pooled JMS connections in JBoss CLI. It would be nice if there was some information available similar to what is available for JDBC pools: > {noformat} > "pool" => { > "ActiveCount" => "0", > "AvailableCount" => "0", > "AverageBlockingTime" => "0", > "AverageCreationTime" => "0", > "CreatedCount" => "0", > "DestroyedCount" => "0", > "InUseCount" => "0", > "MaxCreationTime" => "0", > "MaxUsedCount" => "0", > "MaxWaitCount" => "0", > "MaxWaitTime" => "0", > "TimedOut" => "0", > "TotalBlockingTime" => "0", > "TotalCreationTime" => "0", > "statistics-enabled" => false > } > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3636) Improve monitoring of JMS pooled connection in JBoss CLI

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-3636?page=com.atlassian.jira.plugin.... ] Jeff Mesnil commented on WFLY-3636: ----------------------------------- [~will.tatam] sorry, the code is not yet checked in WildFly (nor in EAP7). It's targeted for WFLY 11. > Improve monitoring of JMS pooled connection in JBoss CLI > -------------------------------------------------------- > > Key: WFLY-3636 > URL: https://issues.jboss.org/browse/WFLY-3636 > Project: WildFly > Issue Type: Feature Request > Components: JMS > Affects Versions: 8.1.0.Final > Environment: JBoss EAP 6.x > Reporter: Tom Ross > Assignee: Jeff Mesnil > Fix For: 11.0.0.Alpha1 > > > At the moment there is no way of monitoring pooled JMS connections in JBoss CLI. It would be nice if there was some information available similar to what is available for JDBC pools: > {noformat} > "pool" => { > "ActiveCount" => "0", > "AvailableCount" => "0", > "AverageBlockingTime" => "0", > "AverageCreationTime" => "0", > "CreatedCount" => "0", > "DestroyedCount" => "0", > "InUseCount" => "0", > "MaxCreationTime" => "0", > "MaxUsedCount" => "0", > "MaxWaitCount" => "0", > "MaxWaitTime" => "0", > "TimedOut" => "0", > "TotalBlockingTime" => "0", > "TotalCreationTime" => "0", > "statistics-enabled" => false > } > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3636) Improve monitoring of JMS pooled connection in JBoss CLI

by Will Tatam (JIRA)

[ https://issues.jboss.org/browse/WFLY-3636?page=com.atlassian.jira.plugin.... ] Will Tatam commented on WFLY-3636: ---------------------------------- Hi [~jmesnil] could you provide an example of how you get the pool stats? Does this also work in EAP 7.0 ? > Improve monitoring of JMS pooled connection in JBoss CLI > -------------------------------------------------------- > > Key: WFLY-3636 > URL: https://issues.jboss.org/browse/WFLY-3636 > Project: WildFly > Issue Type: Feature Request > Components: JMS > Affects Versions: 8.1.0.Final > Environment: JBoss EAP 6.x > Reporter: Tom Ross > Assignee: Jeff Mesnil > > At the moment there is no way of monitoring pooled JMS connections in JBoss CLI. It would be nice if there was some information available similar to what is available for JDBC pools: > {noformat} > "pool" => { > "ActiveCount" => "0", > "AvailableCount" => "0", > "AverageBlockingTime" => "0", > "AverageCreationTime" => "0", > "CreatedCount" => "0", > "DestroyedCount" => "0", > "InUseCount" => "0", > "MaxCreationTime" => "0", > "MaxUsedCount" => "0", > "MaxWaitCount" => "0", > "MaxWaitTime" => "0", > "TimedOut" => "0", > "TotalBlockingTime" => "0", > "TotalCreationTime" => "0", > "statistics-enabled" => false > } > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7033) EL break page compilation

by Marco Mondini (JIRA)

[ https://issues.jboss.org/browse/WFLY-7033?page=com.atlassian.jira.plugin.... ] Marco Mondini updated WFLY-7033: -------------------------------- Attachment: elfix.patch This should fix the issue. > EL break page compilation > ------------------------- > > Key: WFLY-7033 > URL: https://issues.jboss.org/browse/WFLY-7033 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.1.0.Final > Reporter: Marco Mondini > Assignee: Tomaz Cerar > Attachments: elfix.patch > > > In case of an expression with multiple ELs, fix for WFLY-4455 breaks braces precedence. > As a conseguence, if a single quote is present between expressions, EL Parser can't find function in second expression. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1245) Improve readability of missing dependency logs

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1245?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-1245: ------------------------------------------------- Brad Maxwell <bmaxwell(a)redhat.com> changed the Status of [bug 1283294|https://bugzilla.redhat.com/show_bug.cgi?id=1283294] from POST to CLOSED > Improve readability of missing dependency logs > ---------------------------------------------- > > Key: WFCORE-1245 > URL: https://issues.jboss.org/browse/WFCORE-1245 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Bartosz Spyrko-Śmietanko > Assignee: Bartosz Spyrko-Śmietanko > Fix For: 2.2.0.CR1, 3.0.0.Alpha1 > > Attachments: after_1.log, after_2.log, before.log, bz1283294-reproducer.zip > > > When deploying an ear using initialize-in-order option, if one of the subdeployments contains an EJB that depends on an EJB from another subdeployment and the dependency subdeployment fails log output makes it hard to understand the root cause. > Structure of deployment is as follows: > {noformat} > reproducer.ear > |- service-locator.jar > | |- ServiceLocator (Stateless EJB) > | |- TestQueue (JNDI Resource) > |- client.jar > |- TestEjb (Stateless EJB) > |- ServiceLocator > {noformat} > If the TestQueue JNDI resource cannot be injected in the ServiceLocator, the deployment failure output lists a number of missing services per each EJB in the dependant subdeployment (.ORB, .HandleDelegate, .ValidatorFactory, etc). > When the dependant subdeployment has a larger number of EJBs the log output very quickly becomes hard to read. > Example with a single dependant EJB: > {noformat} > 14:27:43,092 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("deploy") failed - address: ({"deployment" => "reproducer-1.0-SNAPSHOT.ear"}) - failure description: { > "WFLYCTL0180: Services with missing/unavailable dependencies" => [ > "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"client.jar\".batch.environment is missing [jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"client.jar\".beanmanager]", > "jboss.naming.context.java.comp.testEar.client.TestEjb.ValidatorFactory is missing [jboss.naming.context.java.comp.testEar.client.TestEjb]", > "jboss.naming.context.java.comp.testEar.client.TestEjb.ORB is missing [jboss.naming.context.java.comp.testEar.client.TestEjb]", > "jboss.naming.context.java.comp.testEar.client.TestEjb.HandleDelegate is missing [jboss.naming.context.java.comp.testEar.client.TestEjb]", > "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"client.jar\".weld.weldClassIntrospector is missing [jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"client.jar\".beanmanager]", > "jboss.deployment.unit.\"reproducer-1.0-SNAPSHOT.ear\".deploymentCompleteService is missing [jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"client.jar\".deploymentCompleteService]", > "jboss.naming.context.java.comp.testEar.client.TestEjb.InstanceName is missing [jboss.naming.context.java.comp.testEar.client.TestEjb]", > "jboss.naming.context.java.comp.testEar.client.TestEjb.Validator is missing [jboss.naming.context.java.comp.testEar.client.TestEjb]", > "jboss.naming.context.java.comp.testEar.service-locator.test_ServiceLocator.env.queue.TestQueue is missing [jboss.naming.context.java.jboss.resources.queue.TestQueue]", > "jboss.naming.context.java.comp.testEar.client.TestEjb.InAppClientContainer is missing [jboss.naming.context.java.comp.testEar.client.TestEjb]" > ], > "WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => { > "Services that were unable to start:" => [ > "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"client.jar\".INSTALL", > "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"service-locator.jar\".CLEANUP", > "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"service-locator.jar\".component.test_ServiceLocator.JndiBindingsService", > "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"service-locator.jar\".component.test_ServiceLocator.START", > "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"service-locator.jar\".deploymentCompleteService", > "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"service-locator.jar\".jndiDependencyService", > "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"service-locator.jar\".moduleDeploymentRuntimeInformationStart", > "jboss.deployment.unit.\"reproducer-1.0-SNAPSHOT.ear\".CLEANUP" > ] > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1774) Use core-service=capability-registry to provide tab completion suggestions for model reference attributes

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1774?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1774: ------------------------------------------ [~jdenise] If the tab completion can work based solely on the capability registry and not involving analyzing resource addresses, that is better. It looks like it's possible given the data present in the registry. Please feel free to request server side management API enhancements if they will make it easier, e.g. by reducing the amount of data the CLI needs to pull to calculate the answer. That said, in the specific example here of a JGroups transport diagnostic-socket-binding attribute, the attribute references capability org.wildfly.network.socket-binding and there the dynamic part of the valid names does not include tcp.TCP, udp.UDP etc. {code} [standalone@embedded /] /subsystem=jgroups/stack=udp/transport=UDP:read-resource-description { "outcome" => "success", "result" => { .... "attributes" => { .... "diagnostics-socket-binding" => { "type" => STRING, "description" => "The diagnostics socket binding specification for this protocol layer, used to specify IP interfaces and ports for communication.", "expressions-allowed" => true, "nillable" => true, "capability-reference" => "org.wildfly.network.socket-binding", "min-length" => 1L, "max-length" => 2147483647L, "access-constraints" => {"sensitive" => {"socket-binding-ref" => {"type" => "core"}}}, "access-type" => "read-write", "storage" => "configuration", "restart-required" => "resource-services" }, {code} I don't believe the capability org.wildly.clustering.transport.diagnostics-socket-binding capability is actually meant to be referenced. It would be fairly unfriendly to the users of capabilities named that way were used as reference targets. But, if a developer did that, the way you propose would be the only way I could see to identify the correct candidates. Re: static capabilities an attribute cannot reference one because the attribute value must point to something dynamic. > Use core-service=capability-registry to provide tab completion suggestions for model reference attributes > --------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1774 > URL: https://issues.jboss.org/browse/WFCORE-1774 > Project: WildFly Core > Issue Type: Enhancement > Components: CLI > Reporter: Brian Stansberry > Assignee: Jean-Francois Denise > > A "model reference" attribute is one whose value points to some other aspect of the model, e.g. "socket-binding" => "http". With the capability and requirement function we are rolling out in the server[1] we have the ability for clients to understand what values are valid for the reference. This should be used in CLI tab completion. > [~claudio4j] has utitlized this for UI suggestions in HAL so he or Harald can be a resource for the exact algorithm that has worked best. Here's the basics though: > 1) This applies to attributes or operation params where the read-resource-description or read-operation-description includes a "capability-reference" field. The value of the field shows the static portion of the capability name. For example an attribute that's used for a socket binding name would show "org.wildfly.network.socket-binding". > 2) The [/host=*]/core-service=capability resource shows information about what capabilities are available on the system. This includes 2 attributes "capabilities" and "possible-capabilities". The former shows the specific capabilities that are actually present; i.e. the resources that provide the capability are part of the configuration. The latter shows capabilities that could be present, given the installed extensions, if the relevant resources were added. > That resource includes two operations "get-capability" and "get-provider-points" that can show more details about what resources provide a capability: > {code} > [standalone@embedded core-service=capability-registry] :get-provider-points(name=org.wildfly.network.socket-binding) > { > "outcome" => "success", > "result" => ["/socket-binding-group=*/socket-binding=*"] > } > {code} > That tells you that capabilities of type org.wildfly.network.socket-binding are registered by resources using address pattern /socket-binding-group=*/socket-binding=* > 3) With that information the CLI can see what resources actually exist on the system and use the value portion of the final element of their address as the suggestion list for tab completion. > HAL may be doing something slightly different from what I describe; they have concrete experience. > It may be possible for the API exposed by core-service=capability-registry to be enhanced to make this easier. If you want something, please don't hesitate to ask Tomaz Cerar or myself. > [1] https://docs.jboss.org/author/display/WFLY/Working+with+WildFly+Capabilities -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7093) Transfer of contextData back to the jboss ejb client

by Teresa Miyar (JIRA)

Teresa Miyar created WFLY-7093: ---------------------------------- Summary: Transfer of contextData back to the jboss ejb client Key: WFLY-7093 URL: https://issues.jboss.org/browse/WFLY-7093 Project: WildFly Issue Type: Bug Components: EJB Affects Versions: 10.1.0.Final Reporter: Teresa Miyar Priority: Minor The spec says: The getContextData method enables a business method, lifecycle callback method, or timeout method to retrieve any interceptor/webservices context associated with its invocation. The way this context data travels from client to server is by copying the data into a server context, this data is used inside the server ejb but not copied back to client. Client requests that this contextData is populated from client to server and vice versa. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7081) Elytron + https-listener in undertow listener doesn't work with enable-http2 set to "true"

by Hynek Švábek (JIRA)

[ https://issues.jboss.org/browse/WFLY-7081?page=com.atlassian.jira.plugin.... ] Hynek Švábek updated WFLY-7081: ------------------------------- Priority: Blocker (was: Critical) > Elytron + https-listener in undertow listener doesn't work with enable-http2 set to "true" > ------------------------------------------------------------------------------------------ > > Key: WFLY-7081 > URL: https://issues.jboss.org/browse/WFLY-7081 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Hynek Švábek > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 11.0.0.Alpha1 > > > When I want to use HTTPS settings in combination with Elytron subsystem then I have to set "enable-http2" to "false" value. > For settings I followed this blog post http://darranl.blogspot.cz/2016/02/wildfly-elytron-ssl-configuration.html > And as keystore I used default application.keystore -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7081) Elytron + https-listener in undertow listener doesn't work with enable-http2 set to "true"

by Hynek Švábek (JIRA)

[ https://issues.jboss.org/browse/WFLY-7081?page=com.atlassian.jira.plugin.... ] Hynek Švábek reopened WFLY-7081: -------------------------------- Added the required details to JBEAP jira > Elytron + https-listener in undertow listener doesn't work with enable-http2 set to "true" > ------------------------------------------------------------------------------------------ > > Key: WFLY-7081 > URL: https://issues.jboss.org/browse/WFLY-7081 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Hynek Švábek > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 11.0.0.Alpha1 > > > When I want to use HTTPS settings in combination with Elytron subsystem then I have to set "enable-http2" to "false" value. > For settings I followed this blog post http://darranl.blogspot.cz/2016/02/wildfly-elytron-ssl-configuration.html > And as keystore I used default application.keystore -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1783) CLI GUI throws exception when editing boolean attribute with expression

by Ivo Hrádek (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1783?page=com.atlassian.jira.plugi... ] Ivo Hrádek commented on WFCORE-1783: ------------------------------------ [~brian.stansberry] - I've re-implemented PR, as you have suggested. > CLI GUI throws exception when editing boolean attribute with expression > ----------------------------------------------------------------------- > > Key: WFCORE-1783 > URL: https://issues.jboss.org/browse/WFCORE-1783 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: John Mazzitelli > Assignee: Alexey Loubyansky > Priority: Minor > > When in the CLI GUI, if you try to edit a boolean attribute whose current value is an expression then an exception is thrown and you can't edit it - the popup dialog is really small and blank. > See "Steps to Reproduce" for replication procedures. > Here's the exception: > java.lang.IllegalArgumentException > at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:66) > at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:262) > at org.jboss.as.cli.gui.OperationDialog$RequestProp.setInputComponentValue(OperationDialog.java:428) > at org.jboss.as.cli.gui.OperationDialog$RequestProp.<init>(OperationDialog.java:336) > at org.jboss.as.cli.gui.OperationDialog.setProps(OperationDialog.java:157) > at org.jboss.as.cli.gui.OperationDialog.<init>(OperationDialog.java:73) > at org.jboss.as.cli.gui.OperationMenu$OperationAction.actionPerformed(OperationMenu.java:152) > at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2022) > at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2348) > at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402) > at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259) > at javax.swing.AbstractButton.doClick(AbstractButton.java:376) > at javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:833) > at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:877) > at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:289) > at java.awt.Component.processMouseEvent(Component.java:6535) > at javax.swing.JComponent.processMouseEvent(JComponent.java:3324) > at java.awt.Component.processEvent(Component.java:6300) > at java.awt.Container.processEvent(Container.java:2236) > at java.awt.Component.dispatchEventImpl(Component.java:4891) > at java.awt.Container.dispatchEventImpl(Container.java:2294) > at java.awt.Component.dispatchEvent(Component.java:4713) > at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4888) > at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4525) > at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4466) > at java.awt.Container.dispatchEventImpl(Container.java:2280) > at java.awt.Window.dispatchEventImpl(Window.java:2750) > at java.awt.Component.dispatchEvent(Component.java:4713) > at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758) > at java.awt.EventQueue.access$500(EventQueue.java:97) > at java.awt.EventQueue$3.run(EventQueue.java:709) > at java.awt.EventQueue$3.run(EventQueue.java:703) > at java.security.AccessController.doPrivileged(Native Method) > at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76) > at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86) > at java.awt.EventQueue$4.run(EventQueue.java:731) > at java.awt.EventQueue$4.run(EventQueue.java:729) > at java.security.AccessController.doPrivileged(Native Method) > at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76) > at java.awt.EventQueue.dispatchEvent(EventQueue.java:728) > at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201) > at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) > at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) > at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1239) Deleting of drools project cause error on Windows 10

by Robert (Bob) Brodt (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1239?page=com.atlassian.jira.plugi... ] Robert (Bob) Brodt closed DROOLS-1239. -------------------------------------- Resolution: Duplicate Issue Duplicate of RHBRMS-2568 > Deleting of drools project cause error on Windows 10 > ---------------------------------------------------- > > Key: DROOLS-1239 > URL: https://issues.jboss.org/browse/DROOLS-1239 > Project: Drools > Issue Type: Bug > Components: eclipse plugin > Affects Versions: 6.4.0.Final > Environment: Windows 10 > jdk 1.8.0 > Reporter: Tomas David > Assignee: Robert (Bob) Brodt > Labels: reported-by-qe > Attachments: error.png, log > > > If you create a new drools project with all samples and delete it, an error appears. This happens only sometimes on windows 10 machines. See the screenshot and log file. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1785) Extension remove is not cleaning out provided capabilities

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1785?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1785: ------------------------------------- Summary: Extension remove is not cleaning out provided capabilities (was: Not possible to add Elytron subsystem after it was previously removed) > Extension remove is not cleaning out provided capabilities > ---------------------------------------------------------- > > Key: WFCORE-1785 > URL: https://issues.jboss.org/browse/WFCORE-1785 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Alpha7 > Reporter: Jan Tymel > Assignee: Brian Stansberry > Labels: affects_elytron > Fix For: 3.0.0.Alpha8 > > > It is not possible to add Elytron extension that was previously removed. Everything works fine if the server is reloaded between steps 5 and 6, hence I assume that there is either 'reload required' state missing or Elytron extension is not removed properly. > Actual result: > {code} > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.providers' is already registered in context 'global'.", > "rolled-back" => true > } > {code} > {code} > ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([("extension" => "org.wildfly.extension.elytron")]): java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.providers' is already registered in context 'global'. > at org.jboss.as.controller.CapabilityRegistry.lambda$registerPossibleCapability$0(CapabilityRegistry.java:518) > at java.util.concurrent.ConcurrentHashMap.computeIfPresent(ConcurrentHashMap.java:1769) > at org.jboss.as.controller.CapabilityRegistry.registerPossibleCapability(CapabilityRegistry.java:512) > at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerCapability(ConcreteResourceRegistration.java:669) > at org.jboss.as.controller.SimpleResourceDefinition.registerCapabilities(SimpleResourceDefinition.java:368) > at org.jboss.as.controller.registry.NodeSubregistry.registerChild(NodeSubregistry.java:108) > at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:226) > at org.wildfly.extension.elytron.ElytronDefinition.registerChildren(ElytronDefinition.java:83) > at org.jboss.as.controller.registry.NodeSubregistry.registerChild(NodeSubregistry.java:107) > at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:226) > at org.jboss.as.controller.extension.ExtensionRegistry$SubsystemRegistrationImpl.registerSubsystemModel(ExtensionRegistry.java:694) > at org.wildfly.extension.elytron.ElytronExtension.initialize(ElytronExtension.java:99) > at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:131) > at org.jboss.as.controller.extension.ExtensionAddHandler.execute(ExtensionAddHandler.java:83) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:951) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:694) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:389) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAs(Subject.java:422) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} > Expected result: > It is possible to add Elytron subsystem after its removal. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1785) Extension remove is not cleaning out provided capabilities

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1785?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-1785: ---------------------------------------- Assignee: Tomaz Cerar (was: Brian Stansberry) > Extension remove is not cleaning out provided capabilities > ---------------------------------------------------------- > > Key: WFCORE-1785 > URL: https://issues.jboss.org/browse/WFCORE-1785 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Alpha7 > Reporter: Jan Tymel > Assignee: Tomaz Cerar > Labels: affects_elytron > Fix For: 3.0.0.Alpha8 > > > It is not possible to add Elytron extension that was previously removed. Everything works fine if the server is reloaded between steps 5 and 6, hence I assume that there is either 'reload required' state missing or Elytron extension is not removed properly. > Actual result: > {code} > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.providers' is already registered in context 'global'.", > "rolled-back" => true > } > {code} > {code} > ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([("extension" => "org.wildfly.extension.elytron")]): java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.providers' is already registered in context 'global'. > at org.jboss.as.controller.CapabilityRegistry.lambda$registerPossibleCapability$0(CapabilityRegistry.java:518) > at java.util.concurrent.ConcurrentHashMap.computeIfPresent(ConcurrentHashMap.java:1769) > at org.jboss.as.controller.CapabilityRegistry.registerPossibleCapability(CapabilityRegistry.java:512) > at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerCapability(ConcreteResourceRegistration.java:669) > at org.jboss.as.controller.SimpleResourceDefinition.registerCapabilities(SimpleResourceDefinition.java:368) > at org.jboss.as.controller.registry.NodeSubregistry.registerChild(NodeSubregistry.java:108) > at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:226) > at org.wildfly.extension.elytron.ElytronDefinition.registerChildren(ElytronDefinition.java:83) > at org.jboss.as.controller.registry.NodeSubregistry.registerChild(NodeSubregistry.java:107) > at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:226) > at org.jboss.as.controller.extension.ExtensionRegistry$SubsystemRegistrationImpl.registerSubsystemModel(ExtensionRegistry.java:694) > at org.wildfly.extension.elytron.ElytronExtension.initialize(ElytronExtension.java:99) > at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:131) > at org.jboss.as.controller.extension.ExtensionAddHandler.execute(ExtensionAddHandler.java:83) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:951) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:694) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:389) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAs(Subject.java:422) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} > Expected result: > It is possible to add Elytron subsystem after its removal. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2099) TP: one single thread pool

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2099?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-2099. ---------------------------- Resolution: Done > TP: one single thread pool > -------------------------- > > Key: JGRP-2099 > URL: https://issues.jboss.org/browse/JGRP-2099 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > Currently, TP has 4 thread pools: > * OOB > * Regular > * Internal > * Timer (used by TimeScheduler3) > The reason for this was mainly to prevent certain types of tasks from getting dropped due to a full pool. However, this can be changed by (1) making the pool have no queue and (2) handling the RejectedExecutionException (e.g. by spawning a new thread, or upping the max-threads value) for (e.g.) INTERNAL messages and timer tasks. > This not only simplify configuration (1 config section rather than 4), but also reduces the size of TP (removal of accessors, attributes). Things might also become a bit faster as a result. > The new common pool would have the following characteristics: > * Default rejection policy of "abort" (so we can handle pool exhaustion) > * No queue ({{SynchronousQueue}}), so new threads up to max-threads are created if none of the existing ones are available. The queue config attribute will be removed > * Catch RejectedExecutionException for INTERNAL messages and timer tasks. A new thread will be spawned on a RejectedExecutionException. This will be used mainly by INTERNAL messages and timer tasks > * Alternatively, we could increase max-threads (if {{ergonomics==true}}) if we get a constant rate of these exceptions -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-844) Crash when node is deleted from query node

by Fabian Meyer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-844?page=com.atlassian.jira.plugin... ] Fabian Meyer commented on DROOLS-844: ------------------------------------- Just went back to 6.3.0.Final and did some testing: no ClassCast- or NullpointerExceptions. Maybe the fix was reverted? > Crash when node is deleted from query node > ------------------------------------------ > > Key: DROOLS-844 > URL: https://issues.jboss.org/browse/DROOLS-844 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.4.0.Final, 7.0.0.Beta1 > Reporter: Fabian Meyer > Assignee: Mario Fusco > Priority: Critical > Fix For: 6.4.0.Beta1 > > > When a left delete is performed on a PhreakQueryNode, the fact handle of the left tuple might be null, resulting in a NullPointerException. > Exception in thread "Thread-6" java.lang.NullPointerException > at org.drools.core.phreak.PhreakQueryNode.doLeftDeletes(PhreakQueryNode.java:176) > at org.drools.core.phreak.PhreakQueryNode.doNode(PhreakQueryNode.java:46) > at org.drools.core.phreak.RuleNetworkEvaluator.evalQueryNode(RuleNetworkEvaluator.java:460) > at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:360) > at org.drools.core.phreak.RuleNetworkEvaluator.doRiaNode(RuleNetworkEvaluator.java:598) > at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:524) > at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:336) > at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:166) > at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:123) > at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194) > at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:73) > at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:973) > at org.drools.core.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1251) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1353) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1331) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3636) Improve monitoring of JMS pooled connection in JBoss CLI

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-3636?page=com.atlassian.jira.plugin.... ] Jeff Mesnil commented on WFLY-3636: ----------------------------------- JBJCA-1330 prevents XA statistics to work (but pool stats works fine) > Improve monitoring of JMS pooled connection in JBoss CLI > -------------------------------------------------------- > > Key: WFLY-3636 > URL: https://issues.jboss.org/browse/WFLY-3636 > Project: WildFly > Issue Type: Feature Request > Components: JMS > Affects Versions: 8.1.0.Final > Environment: JBoss EAP 6.x > Reporter: Tom Ross > Assignee: Jeff Mesnil > > At the moment there is no way of monitoring pooled JMS connections in JBoss CLI. It would be nice if there was some information available similar to what is available for JDBC pools: > {noformat} > "pool" => { > "ActiveCount" => "0", > "AvailableCount" => "0", > "AverageBlockingTime" => "0", > "AverageCreationTime" => "0", > "CreatedCount" => "0", > "DestroyedCount" => "0", > "InUseCount" => "0", > "MaxCreationTime" => "0", > "MaxUsedCount" => "0", > "MaxWaitCount" => "0", > "MaxWaitTime" => "0", > "TimedOut" => "0", > "TotalBlockingTime" => "0", > "TotalCreationTime" => "0", > "statistics-enabled" => false > } > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6981) Upgrade Weld to 2.4.0.Final

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/WFLY-6981?page=com.atlassian.jira.plugin.... ] Martin Kouba updated WFLY-6981: ------------------------------- Summary: Upgrade Weld to 2.4.0.Final (was: Upgrade Weld to 2.4.0.CR1) > Upgrade Weld to 2.4.0.Final > --------------------------- > > Key: WFLY-6981 > URL: https://issues.jboss.org/browse/WFLY-6981 > Project: WildFly > Issue Type: Component Upgrade > Components: CDI / Weld > Reporter: Martin Kouba > Assignee: Martin Kouba > Fix For: 11.0.0.Alpha1 > > > See also http://weld.cdi-spec.org/news/2016/08/19/weld-240CR1/. > Also remove the dependency on {{com.google.guava:guava}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1785) Not possible to add Elytron subsystem after it was previously removed

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1785?page=com.atlassian.jira.plugi... ] Darran Lofthouse commented on WFCORE-1785: ------------------------------------------ Moved, I will keep an eye on this in case we need anything in the Elytron subsystem. > Not possible to add Elytron subsystem after it was previously removed > --------------------------------------------------------------------- > > Key: WFCORE-1785 > URL: https://issues.jboss.org/browse/WFCORE-1785 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Alpha7 > Reporter: Jan Tymel > Assignee: Brian Stansberry > Labels: affects_elytron > Fix For: 3.0.0.Alpha8 > > > It is not possible to add Elytron extension that was previously removed. Everything works fine if the server is reloaded between steps 5 and 6, hence I assume that there is either 'reload required' state missing or Elytron extension is not removed properly. > Actual result: > {code} > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.providers' is already registered in context 'global'.", > "rolled-back" => true > } > {code} > {code} > ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([("extension" => "org.wildfly.extension.elytron")]): java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.providers' is already registered in context 'global'. > at org.jboss.as.controller.CapabilityRegistry.lambda$registerPossibleCapability$0(CapabilityRegistry.java:518) > at java.util.concurrent.ConcurrentHashMap.computeIfPresent(ConcurrentHashMap.java:1769) > at org.jboss.as.controller.CapabilityRegistry.registerPossibleCapability(CapabilityRegistry.java:512) > at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerCapability(ConcreteResourceRegistration.java:669) > at org.jboss.as.controller.SimpleResourceDefinition.registerCapabilities(SimpleResourceDefinition.java:368) > at org.jboss.as.controller.registry.NodeSubregistry.registerChild(NodeSubregistry.java:108) > at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:226) > at org.wildfly.extension.elytron.ElytronDefinition.registerChildren(ElytronDefinition.java:83) > at org.jboss.as.controller.registry.NodeSubregistry.registerChild(NodeSubregistry.java:107) > at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:226) > at org.jboss.as.controller.extension.ExtensionRegistry$SubsystemRegistrationImpl.registerSubsystemModel(ExtensionRegistry.java:694) > at org.wildfly.extension.elytron.ElytronExtension.initialize(ElytronExtension.java:99) > at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:131) > at org.jboss.as.controller.extension.ExtensionAddHandler.execute(ExtensionAddHandler.java:83) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:951) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:694) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:389) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAs(Subject.java:422) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} > Expected result: > It is possible to add Elytron subsystem after its removal. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1785) Not possible to add Elytron subsystem after it was previously removed

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1785?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-1785: ------------------------------------- Affects Version/s: 3.0.0.Alpha7 > Not possible to add Elytron subsystem after it was previously removed > --------------------------------------------------------------------- > > Key: WFCORE-1785 > URL: https://issues.jboss.org/browse/WFCORE-1785 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Alpha7 > Reporter: Jan Tymel > Assignee: Brian Stansberry > Labels: affects_elytron > Fix For: 3.0.0.Alpha8 > > > It is not possible to add Elytron extension that was previously removed. Everything works fine if the server is reloaded between steps 5 and 6, hence I assume that there is either 'reload required' state missing or Elytron extension is not removed properly. > Actual result: > {code} > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.providers' is already registered in context 'global'.", > "rolled-back" => true > } > {code} > {code} > ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([("extension" => "org.wildfly.extension.elytron")]): java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.providers' is already registered in context 'global'. > at org.jboss.as.controller.CapabilityRegistry.lambda$registerPossibleCapability$0(CapabilityRegistry.java:518) > at java.util.concurrent.ConcurrentHashMap.computeIfPresent(ConcurrentHashMap.java:1769) > at org.jboss.as.controller.CapabilityRegistry.registerPossibleCapability(CapabilityRegistry.java:512) > at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerCapability(ConcreteResourceRegistration.java:669) > at org.jboss.as.controller.SimpleResourceDefinition.registerCapabilities(SimpleResourceDefinition.java:368) > at org.jboss.as.controller.registry.NodeSubregistry.registerChild(NodeSubregistry.java:108) > at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:226) > at org.wildfly.extension.elytron.ElytronDefinition.registerChildren(ElytronDefinition.java:83) > at org.jboss.as.controller.registry.NodeSubregistry.registerChild(NodeSubregistry.java:107) > at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:226) > at org.jboss.as.controller.extension.ExtensionRegistry$SubsystemRegistrationImpl.registerSubsystemModel(ExtensionRegistry.java:694) > at org.wildfly.extension.elytron.ElytronExtension.initialize(ElytronExtension.java:99) > at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:131) > at org.jboss.as.controller.extension.ExtensionAddHandler.execute(ExtensionAddHandler.java:83) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:951) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:694) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:389) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAs(Subject.java:422) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} > Expected result: > It is possible to add Elytron subsystem after its removal. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1785) Not possible to add Elytron subsystem after it was previously removed

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1785?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-1785: ------------------------------------- Fix Version/s: 3.0.0.Alpha8 > Not possible to add Elytron subsystem after it was previously removed > --------------------------------------------------------------------- > > Key: WFCORE-1785 > URL: https://issues.jboss.org/browse/WFCORE-1785 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Alpha7 > Reporter: Jan Tymel > Assignee: Brian Stansberry > Labels: affects_elytron > Fix For: 3.0.0.Alpha8 > > > It is not possible to add Elytron extension that was previously removed. Everything works fine if the server is reloaded between steps 5 and 6, hence I assume that there is either 'reload required' state missing or Elytron extension is not removed properly. > Actual result: > {code} > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.providers' is already registered in context 'global'.", > "rolled-back" => true > } > {code} > {code} > ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([("extension" => "org.wildfly.extension.elytron")]): java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.providers' is already registered in context 'global'. > at org.jboss.as.controller.CapabilityRegistry.lambda$registerPossibleCapability$0(CapabilityRegistry.java:518) > at java.util.concurrent.ConcurrentHashMap.computeIfPresent(ConcurrentHashMap.java:1769) > at org.jboss.as.controller.CapabilityRegistry.registerPossibleCapability(CapabilityRegistry.java:512) > at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerCapability(ConcreteResourceRegistration.java:669) > at org.jboss.as.controller.SimpleResourceDefinition.registerCapabilities(SimpleResourceDefinition.java:368) > at org.jboss.as.controller.registry.NodeSubregistry.registerChild(NodeSubregistry.java:108) > at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:226) > at org.wildfly.extension.elytron.ElytronDefinition.registerChildren(ElytronDefinition.java:83) > at org.jboss.as.controller.registry.NodeSubregistry.registerChild(NodeSubregistry.java:107) > at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:226) > at org.jboss.as.controller.extension.ExtensionRegistry$SubsystemRegistrationImpl.registerSubsystemModel(ExtensionRegistry.java:694) > at org.wildfly.extension.elytron.ElytronExtension.initialize(ElytronExtension.java:99) > at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:131) > at org.jboss.as.controller.extension.ExtensionAddHandler.execute(ExtensionAddHandler.java:83) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:951) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:694) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:389) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAs(Subject.java:422) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} > Expected result: > It is possible to add Elytron subsystem after its removal. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1785) Not possible to add Elytron subsystem after it was previously removed

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1785?page=com.atlassian.jira.plugi... ] Darran Lofthouse reassigned WFCORE-1785: ---------------------------------------- Assignee: Brian Stansberry (was: Darran Lofthouse) > Not possible to add Elytron subsystem after it was previously removed > --------------------------------------------------------------------- > > Key: WFCORE-1785 > URL: https://issues.jboss.org/browse/WFCORE-1785 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Alpha7 > Reporter: Jan Tymel > Assignee: Brian Stansberry > Labels: affects_elytron > Fix For: 3.0.0.Alpha8 > > > It is not possible to add Elytron extension that was previously removed. Everything works fine if the server is reloaded between steps 5 and 6, hence I assume that there is either 'reload required' state missing or Elytron extension is not removed properly. > Actual result: > {code} > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.providers' is already registered in context 'global'.", > "rolled-back" => true > } > {code} > {code} > ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([("extension" => "org.wildfly.extension.elytron")]): java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.providers' is already registered in context 'global'. > at org.jboss.as.controller.CapabilityRegistry.lambda$registerPossibleCapability$0(CapabilityRegistry.java:518) > at java.util.concurrent.ConcurrentHashMap.computeIfPresent(ConcurrentHashMap.java:1769) > at org.jboss.as.controller.CapabilityRegistry.registerPossibleCapability(CapabilityRegistry.java:512) > at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerCapability(ConcreteResourceRegistration.java:669) > at org.jboss.as.controller.SimpleResourceDefinition.registerCapabilities(SimpleResourceDefinition.java:368) > at org.jboss.as.controller.registry.NodeSubregistry.registerChild(NodeSubregistry.java:108) > at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:226) > at org.wildfly.extension.elytron.ElytronDefinition.registerChildren(ElytronDefinition.java:83) > at org.jboss.as.controller.registry.NodeSubregistry.registerChild(NodeSubregistry.java:107) > at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:226) > at org.jboss.as.controller.extension.ExtensionRegistry$SubsystemRegistrationImpl.registerSubsystemModel(ExtensionRegistry.java:694) > at org.wildfly.extension.elytron.ElytronExtension.initialize(ElytronExtension.java:99) > at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:131) > at org.jboss.as.controller.extension.ExtensionAddHandler.execute(ExtensionAddHandler.java:83) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:951) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:694) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:389) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAs(Subject.java:422) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} > Expected result: > It is possible to add Elytron subsystem after its removal. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1785) Not possible to add Elytron subsystem after it was previously removed

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1785?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-1785: ------------------------------------- Labels: affects_elytron (was: ) > Not possible to add Elytron subsystem after it was previously removed > --------------------------------------------------------------------- > > Key: WFCORE-1785 > URL: https://issues.jboss.org/browse/WFCORE-1785 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Alpha7 > Reporter: Jan Tymel > Assignee: Brian Stansberry > Labels: affects_elytron > Fix For: 3.0.0.Alpha8 > > > It is not possible to add Elytron extension that was previously removed. Everything works fine if the server is reloaded between steps 5 and 6, hence I assume that there is either 'reload required' state missing or Elytron extension is not removed properly. > Actual result: > {code} > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.providers' is already registered in context 'global'.", > "rolled-back" => true > } > {code} > {code} > ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([("extension" => "org.wildfly.extension.elytron")]): java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.providers' is already registered in context 'global'. > at org.jboss.as.controller.CapabilityRegistry.lambda$registerPossibleCapability$0(CapabilityRegistry.java:518) > at java.util.concurrent.ConcurrentHashMap.computeIfPresent(ConcurrentHashMap.java:1769) > at org.jboss.as.controller.CapabilityRegistry.registerPossibleCapability(CapabilityRegistry.java:512) > at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerCapability(ConcreteResourceRegistration.java:669) > at org.jboss.as.controller.SimpleResourceDefinition.registerCapabilities(SimpleResourceDefinition.java:368) > at org.jboss.as.controller.registry.NodeSubregistry.registerChild(NodeSubregistry.java:108) > at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:226) > at org.wildfly.extension.elytron.ElytronDefinition.registerChildren(ElytronDefinition.java:83) > at org.jboss.as.controller.registry.NodeSubregistry.registerChild(NodeSubregistry.java:107) > at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:226) > at org.jboss.as.controller.extension.ExtensionRegistry$SubsystemRegistrationImpl.registerSubsystemModel(ExtensionRegistry.java:694) > at org.wildfly.extension.elytron.ElytronExtension.initialize(ElytronExtension.java:99) > at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:131) > at org.jboss.as.controller.extension.ExtensionAddHandler.execute(ExtensionAddHandler.java:83) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:951) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:694) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:389) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAs(Subject.java:422) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} > Expected result: > It is possible to add Elytron subsystem after its removal. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1785) Not possible to add Elytron subsystem after it was previously removed

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1785?page=com.atlassian.jira.plugi... ] Darran Lofthouse moved WFLY-7092 to WFCORE-1785: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-1785 (was: WFLY-7092) Component/s: Domain Management (was: Security) > Not possible to add Elytron subsystem after it was previously removed > --------------------------------------------------------------------- > > Key: WFCORE-1785 > URL: https://issues.jboss.org/browse/WFCORE-1785 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Jan Tymel > Assignee: Darran Lofthouse > > It is not possible to add Elytron extension that was previously removed. Everything works fine if the server is reloaded between steps 5 and 6, hence I assume that there is either 'reload required' state missing or Elytron extension is not removed properly. > Actual result: > {code} > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.providers' is already registered in context 'global'.", > "rolled-back" => true > } > {code} > {code} > ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([("extension" => "org.wildfly.extension.elytron")]): java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.providers' is already registered in context 'global'. > at org.jboss.as.controller.CapabilityRegistry.lambda$registerPossibleCapability$0(CapabilityRegistry.java:518) > at java.util.concurrent.ConcurrentHashMap.computeIfPresent(ConcurrentHashMap.java:1769) > at org.jboss.as.controller.CapabilityRegistry.registerPossibleCapability(CapabilityRegistry.java:512) > at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerCapability(ConcreteResourceRegistration.java:669) > at org.jboss.as.controller.SimpleResourceDefinition.registerCapabilities(SimpleResourceDefinition.java:368) > at org.jboss.as.controller.registry.NodeSubregistry.registerChild(NodeSubregistry.java:108) > at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:226) > at org.wildfly.extension.elytron.ElytronDefinition.registerChildren(ElytronDefinition.java:83) > at org.jboss.as.controller.registry.NodeSubregistry.registerChild(NodeSubregistry.java:107) > at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:226) > at org.jboss.as.controller.extension.ExtensionRegistry$SubsystemRegistrationImpl.registerSubsystemModel(ExtensionRegistry.java:694) > at org.wildfly.extension.elytron.ElytronExtension.initialize(ElytronExtension.java:99) > at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:131) > at org.jboss.as.controller.extension.ExtensionAddHandler.execute(ExtensionAddHandler.java:83) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:951) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:694) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:389) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAs(Subject.java:422) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} > Expected result: > It is possible to add Elytron subsystem after its removal. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1330) XA Stats not updated when the provided XAResource already implements XAResourceWrapper

by Jeff Mesnil (JIRA)

Jeff Mesnil created JBJCA-1330: ---------------------------------- Summary: XA Stats not updated when the provided XAResource already implements XAResourceWrapper Key: JBJCA-1330 URL: https://issues.jboss.org/browse/JBJCA-1330 Project: IronJacamar Issue Type: Feature Request Affects Versions: WildFly/IronJacamar 1.3.4.Final Reporter: Jeff Mesnil Use case: provide XA statistics to WildFly's messaging-activemq pooled-connection-factory leveraging org.jboss.as.connector.dynamicresource.StatisticsResourceDefinition. I have a dev branch[1] for this and pool statistics (from org.jboss.jca.core.api.connectionmanager.pool.PoolStatistics) are updated as expected. However xa states (from org.jboss.jca.core.spi.transaction.XAResourceStatistics) are not updated. The pooled-connection-factory uses a XAPool and its XAResource implementation extends org.jboss.jca.core.spi.transaction.xa.XAResourceWrapper[2]. Doing some debugging, the code at [3] does not look correct. The provided xar extends XAResourceWrapper, so txIntegration.createXAResourceWrapper() is not called and the xar is not wrapped by a XAResourceWrapperStatImpl that is the code responsible to update XA stats. [1] https://github.com/jmesnil/wildfly/tree/WFLY-3636_pooled-connection-facto... [2] https://github.com/rh-messaging/artemis-wildfly-integration/blob/master/s... [3] https://github.com/ironjacamar/ironjacamar/blob/1.3/core/src/main/java/or... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1330) XA Stats not updated when the provided XAResource already implements XAResourceWrapper

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1330?page=com.atlassian.jira.plugin... ] Jeff Mesnil reassigned JBJCA-1330: ---------------------------------- Assignee: Stefano Maestri > XA Stats not updated when the provided XAResource already implements XAResourceWrapper > --------------------------------------------------------------------------------------- > > Key: JBJCA-1330 > URL: https://issues.jboss.org/browse/JBJCA-1330 > Project: IronJacamar > Issue Type: Feature Request > Affects Versions: WildFly/IronJacamar 1.3.4.Final > Reporter: Jeff Mesnil > Assignee: Stefano Maestri > > Use case: provide XA statistics to WildFly's messaging-activemq pooled-connection-factory leveraging org.jboss.as.connector.dynamicresource.StatisticsResourceDefinition. > I have a dev branch[1] for this and pool statistics (from org.jboss.jca.core.api.connectionmanager.pool.PoolStatistics) are updated as expected. > However xa states (from org.jboss.jca.core.spi.transaction.XAResourceStatistics) are not updated. > The pooled-connection-factory uses a XAPool and its XAResource implementation extends org.jboss.jca.core.spi.transaction.xa.XAResourceWrapper[2]. > Doing some debugging, the code at [3] does not look correct. The provided xar extends XAResourceWrapper, so txIntegration.createXAResourceWrapper() is not called and the xar is not wrapped by a XAResourceWrapperStatImpl that is the code responsible to update XA stats. > [1] https://github.com/jmesnil/wildfly/tree/WFLY-3636_pooled-connection-facto... > [2] https://github.com/rh-messaging/artemis-wildfly-integration/blob/master/s... > [3] https://github.com/ironjacamar/ironjacamar/blob/1.3/core/src/main/java/or... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1330) XA Stats not updated when the provided XAResource already implements XAResourceWrapper

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1330?page=com.atlassian.jira.plugin... ] Jeff Mesnil updated JBJCA-1330: ------------------------------- Description: Use case: provide XA statistics to WildFly's messaging-activemq pooled-connection-factory leveraging org.jboss.as.connector.dynamicresource.StatisticsResourceDefinition. I have a dev branch[1] for this and pool statistics (from org.jboss.jca.core.api.connectionmanager.pool.PoolStatistics) are updated as expected. However xa stats (from org.jboss.jca.core.spi.transaction.XAResourceStatistics) are not updated. The pooled-connection-factory uses a XAPool and its XAResource implementation extends org.jboss.jca.core.spi.transaction.xa.XAResourceWrapper[2]. Doing some debugging, the code at [3] does not look correct. The provided xar extends XAResourceWrapper, so txIntegration.createXAResourceWrapper() is not called and the xar is not wrapped by a XAResourceWrapperStatImpl that is the code responsible to update XA stats. [1] https://github.com/jmesnil/wildfly/tree/WFLY-3636_pooled-connection-facto... [2] https://github.com/rh-messaging/artemis-wildfly-integration/blob/master/s... [3] https://github.com/ironjacamar/ironjacamar/blob/1.3/core/src/main/java/or... was: Use case: provide XA statistics to WildFly's messaging-activemq pooled-connection-factory leveraging org.jboss.as.connector.dynamicresource.StatisticsResourceDefinition. I have a dev branch[1] for this and pool statistics (from org.jboss.jca.core.api.connectionmanager.pool.PoolStatistics) are updated as expected. However xa states (from org.jboss.jca.core.spi.transaction.XAResourceStatistics) are not updated. The pooled-connection-factory uses a XAPool and its XAResource implementation extends org.jboss.jca.core.spi.transaction.xa.XAResourceWrapper[2]. Doing some debugging, the code at [3] does not look correct. The provided xar extends XAResourceWrapper, so txIntegration.createXAResourceWrapper() is not called and the xar is not wrapped by a XAResourceWrapperStatImpl that is the code responsible to update XA stats. [1] https://github.com/jmesnil/wildfly/tree/WFLY-3636_pooled-connection-facto... [2] https://github.com/rh-messaging/artemis-wildfly-integration/blob/master/s... [3] https://github.com/ironjacamar/ironjacamar/blob/1.3/core/src/main/java/or... > XA Stats not updated when the provided XAResource already implements XAResourceWrapper > --------------------------------------------------------------------------------------- > > Key: JBJCA-1330 > URL: https://issues.jboss.org/browse/JBJCA-1330 > Project: IronJacamar > Issue Type: Feature Request > Affects Versions: WildFly/IronJacamar 1.3.4.Final > Reporter: Jeff Mesnil > Assignee: Stefano Maestri > > Use case: provide XA statistics to WildFly's messaging-activemq pooled-connection-factory leveraging org.jboss.as.connector.dynamicresource.StatisticsResourceDefinition. > I have a dev branch[1] for this and pool statistics (from org.jboss.jca.core.api.connectionmanager.pool.PoolStatistics) are updated as expected. > However xa stats (from org.jboss.jca.core.spi.transaction.XAResourceStatistics) are not updated. > The pooled-connection-factory uses a XAPool and its XAResource implementation extends org.jboss.jca.core.spi.transaction.xa.XAResourceWrapper[2]. > Doing some debugging, the code at [3] does not look correct. The provided xar extends XAResourceWrapper, so txIntegration.createXAResourceWrapper() is not called and the xar is not wrapped by a XAResourceWrapperStatImpl that is the code responsible to update XA stats. > [1] https://github.com/jmesnil/wildfly/tree/WFLY-3636_pooled-connection-facto... > [2] https://github.com/rh-messaging/artemis-wildfly-integration/blob/master/s... > [3] https://github.com/ironjacamar/ironjacamar/blob/1.3/core/src/main/java/or... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7092) Not possible to add Elytron subsystem after it was previously removed

by Jan Tymel (JIRA)

[ https://issues.jboss.org/browse/WFLY-7092?page=com.atlassian.jira.plugin.... ] Jan Tymel commented on WFLY-7092: --------------------------------- [~brian.stansberry] No, output of Elytron subsystem removal is just {noformat} {"outcome" => "success"} {noformat} > Not possible to add Elytron subsystem after it was previously removed > --------------------------------------------------------------------- > > Key: WFLY-7092 > URL: https://issues.jboss.org/browse/WFLY-7092 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Jan Tymel > Assignee: Darran Lofthouse > > It is not possible to add Elytron extension that was previously removed. Everything works fine if the server is reloaded between steps 5 and 6, hence I assume that there is either 'reload required' state missing or Elytron extension is not removed properly. > Actual result: > {code} > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.providers' is already registered in context 'global'.", > "rolled-back" => true > } > {code} > {code} > ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([("extension" => "org.wildfly.extension.elytron")]): java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.providers' is already registered in context 'global'. > at org.jboss.as.controller.CapabilityRegistry.lambda$registerPossibleCapability$0(CapabilityRegistry.java:518) > at java.util.concurrent.ConcurrentHashMap.computeIfPresent(ConcurrentHashMap.java:1769) > at org.jboss.as.controller.CapabilityRegistry.registerPossibleCapability(CapabilityRegistry.java:512) > at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerCapability(ConcreteResourceRegistration.java:669) > at org.jboss.as.controller.SimpleResourceDefinition.registerCapabilities(SimpleResourceDefinition.java:368) > at org.jboss.as.controller.registry.NodeSubregistry.registerChild(NodeSubregistry.java:108) > at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:226) > at org.wildfly.extension.elytron.ElytronDefinition.registerChildren(ElytronDefinition.java:83) > at org.jboss.as.controller.registry.NodeSubregistry.registerChild(NodeSubregistry.java:107) > at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:226) > at org.jboss.as.controller.extension.ExtensionRegistry$SubsystemRegistrationImpl.registerSubsystemModel(ExtensionRegistry.java:694) > at org.wildfly.extension.elytron.ElytronExtension.initialize(ElytronExtension.java:99) > at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:131) > at org.jboss.as.controller.extension.ExtensionAddHandler.execute(ExtensionAddHandler.java:83) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:951) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:694) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:389) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAs(Subject.java:422) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} > Expected result: > It is possible to add Elytron subsystem after its removal. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7092) Not possible to add Elytron subsystem after it was previously removed

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-7092?page=com.atlassian.jira.plugin.... ] Brian Stansberry commented on WFLY-7092: ---------------------------------------- [~dlofthouse] Agreed. Can you move this to WFCORE / Domain Management component if that's all you want done with it? I'm in Monday morning processing email mode and haven't looked into the details of this scenario at all. Looks like this is a problem with the extension, which is good; cleanup on extension remove was probably missed. I know there was work done with doing cleanup on remove of a resource that registers an actual capability, but the possible capability thing is different. OT -- re: Step 4: Remove Elytron subsystem /subsystem=elytron:remove() [~jtymel] Is that operation resulting in reload-required? > Not possible to add Elytron subsystem after it was previously removed > --------------------------------------------------------------------- > > Key: WFLY-7092 > URL: https://issues.jboss.org/browse/WFLY-7092 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Jan Tymel > Assignee: Darran Lofthouse > > It is not possible to add Elytron extension that was previously removed. Everything works fine if the server is reloaded between steps 5 and 6, hence I assume that there is either 'reload required' state missing or Elytron extension is not removed properly. > Actual result: > {code} > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.providers' is already registered in context 'global'.", > "rolled-back" => true > } > {code} > {code} > ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([("extension" => "org.wildfly.extension.elytron")]): java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.providers' is already registered in context 'global'. > at org.jboss.as.controller.CapabilityRegistry.lambda$registerPossibleCapability$0(CapabilityRegistry.java:518) > at java.util.concurrent.ConcurrentHashMap.computeIfPresent(ConcurrentHashMap.java:1769) > at org.jboss.as.controller.CapabilityRegistry.registerPossibleCapability(CapabilityRegistry.java:512) > at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerCapability(ConcreteResourceRegistration.java:669) > at org.jboss.as.controller.SimpleResourceDefinition.registerCapabilities(SimpleResourceDefinition.java:368) > at org.jboss.as.controller.registry.NodeSubregistry.registerChild(NodeSubregistry.java:108) > at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:226) > at org.wildfly.extension.elytron.ElytronDefinition.registerChildren(ElytronDefinition.java:83) > at org.jboss.as.controller.registry.NodeSubregistry.registerChild(NodeSubregistry.java:107) > at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:226) > at org.jboss.as.controller.extension.ExtensionRegistry$SubsystemRegistrationImpl.registerSubsystemModel(ExtensionRegistry.java:694) > at org.wildfly.extension.elytron.ElytronExtension.initialize(ElytronExtension.java:99) > at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:131) > at org.jboss.as.controller.extension.ExtensionAddHandler.execute(ExtensionAddHandler.java:83) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:951) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:694) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:389) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAs(Subject.java:422) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} > Expected result: > It is possible to add Elytron subsystem after its removal. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1784) AttachmentHandler does not use the right directory when saving more than 1 file

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1784?page=com.atlassian.jira.plugi... ] Jean-Francois Denise updated WFCORE-1784: ----------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1790 > AttachmentHandler does not use the right directory when saving more than 1 file > -------------------------------------------------------------------------------- > > Key: WFCORE-1784 > URL: https://issues.jboss.org/browse/WFCORE-1784 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > > By mistake, the default directory is used for files when the file to save is renamed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7092) Not possible to add Elytron subsystem after it was previously removed

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7092?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-7092: ---------------------------------------- [~brian.stansberry] Not sure if we are missing something or if this is a general capabilities and requirements issue. The bug report here is in terms of the error message on adding the subsystem back but I think the general issue should be that when an extension and subsystem are removed the capabilities it registered as possible capabilities should also be removed, that way admin clients are not going to get confused with possible impossible resources. > Not possible to add Elytron subsystem after it was previously removed > --------------------------------------------------------------------- > > Key: WFLY-7092 > URL: https://issues.jboss.org/browse/WFLY-7092 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Jan Tymel > Assignee: Darran Lofthouse > > It is not possible to add Elytron extension that was previously removed. Everything works fine if the server is reloaded between steps 5 and 6, hence I assume that there is either 'reload required' state missing or Elytron extension is not removed properly. > Actual result: > {code} > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.providers' is already registered in context 'global'.", > "rolled-back" => true > } > {code} > {code} > ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([("extension" => "org.wildfly.extension.elytron")]): java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.providers' is already registered in context 'global'. > at org.jboss.as.controller.CapabilityRegistry.lambda$registerPossibleCapability$0(CapabilityRegistry.java:518) > at java.util.concurrent.ConcurrentHashMap.computeIfPresent(ConcurrentHashMap.java:1769) > at org.jboss.as.controller.CapabilityRegistry.registerPossibleCapability(CapabilityRegistry.java:512) > at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerCapability(ConcreteResourceRegistration.java:669) > at org.jboss.as.controller.SimpleResourceDefinition.registerCapabilities(SimpleResourceDefinition.java:368) > at org.jboss.as.controller.registry.NodeSubregistry.registerChild(NodeSubregistry.java:108) > at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:226) > at org.wildfly.extension.elytron.ElytronDefinition.registerChildren(ElytronDefinition.java:83) > at org.jboss.as.controller.registry.NodeSubregistry.registerChild(NodeSubregistry.java:107) > at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:226) > at org.jboss.as.controller.extension.ExtensionRegistry$SubsystemRegistrationImpl.registerSubsystemModel(ExtensionRegistry.java:694) > at org.wildfly.extension.elytron.ElytronExtension.initialize(ElytronExtension.java:99) > at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:131) > at org.jboss.as.controller.extension.ExtensionAddHandler.execute(ExtensionAddHandler.java:83) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:951) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:694) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:389) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAs(Subject.java:422) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} > Expected result: > It is possible to add Elytron subsystem after its removal. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7092) Not possible to add Elytron subsystem after it was previously removed

by Jan Tymel (JIRA)

Jan Tymel created WFLY-7092: ------------------------------- Summary: Not possible to add Elytron subsystem after it was previously removed Key: WFLY-7092 URL: https://issues.jboss.org/browse/WFLY-7092 Project: WildFly Issue Type: Bug Components: Security Reporter: Jan Tymel Assignee: Darran Lofthouse It is not possible to add Elytron extension that was previously removed. Everything works fine if the server is reloaded between steps 5 and 6, hence I assume that there is either 'reload required' state missing or Elytron extension is not removed properly. Actual result: {code} { "outcome" => "failed", "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.providers' is already registered in context 'global'.", "rolled-back" => true } {code} {code} ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("add") failed - address: ([("extension" => "org.wildfly.extension.elytron")]): java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.security.providers' is already registered in context 'global'. at org.jboss.as.controller.CapabilityRegistry.lambda$registerPossibleCapability$0(CapabilityRegistry.java:518) at java.util.concurrent.ConcurrentHashMap.computeIfPresent(ConcurrentHashMap.java:1769) at org.jboss.as.controller.CapabilityRegistry.registerPossibleCapability(CapabilityRegistry.java:512) at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerCapability(ConcreteResourceRegistration.java:669) at org.jboss.as.controller.SimpleResourceDefinition.registerCapabilities(SimpleResourceDefinition.java:368) at org.jboss.as.controller.registry.NodeSubregistry.registerChild(NodeSubregistry.java:108) at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:226) at org.wildfly.extension.elytron.ElytronDefinition.registerChildren(ElytronDefinition.java:83) at org.jboss.as.controller.registry.NodeSubregistry.registerChild(NodeSubregistry.java:107) at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:226) at org.jboss.as.controller.extension.ExtensionRegistry$SubsystemRegistrationImpl.registerSubsystemModel(ExtensionRegistry.java:694) at org.wildfly.extension.elytron.ElytronExtension.initialize(ElytronExtension.java:99) at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:131) at org.jboss.as.controller.extension.ExtensionAddHandler.execute(ExtensionAddHandler.java:83) at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:951) at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:694) at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:389) at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363) at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410) at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:422) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) at org.jboss.threads.JBossThread.run(JBossThread.java:320) {code} Expected result: It is possible to add Elytron subsystem after its removal. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1783) CLI GUI throws exception when editing boolean attribute with expression

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1783?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1783: ------------------------------------------ If an attribute allows expressions (which is declared in the read-resource-description metadata describing the attribute), the widget to edit it should be a text box not a check box. > CLI GUI throws exception when editing boolean attribute with expression > ----------------------------------------------------------------------- > > Key: WFCORE-1783 > URL: https://issues.jboss.org/browse/WFCORE-1783 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: John Mazzitelli > Assignee: Alexey Loubyansky > Priority: Minor > > When in the CLI GUI, if you try to edit a boolean attribute whose current value is an expression then an exception is thrown and you can't edit it - the popup dialog is really small and blank. > See "Steps to Reproduce" for replication procedures. > Here's the exception: > java.lang.IllegalArgumentException > at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:66) > at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:262) > at org.jboss.as.cli.gui.OperationDialog$RequestProp.setInputComponentValue(OperationDialog.java:428) > at org.jboss.as.cli.gui.OperationDialog$RequestProp.<init>(OperationDialog.java:336) > at org.jboss.as.cli.gui.OperationDialog.setProps(OperationDialog.java:157) > at org.jboss.as.cli.gui.OperationDialog.<init>(OperationDialog.java:73) > at org.jboss.as.cli.gui.OperationMenu$OperationAction.actionPerformed(OperationMenu.java:152) > at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2022) > at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2348) > at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402) > at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259) > at javax.swing.AbstractButton.doClick(AbstractButton.java:376) > at javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:833) > at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:877) > at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:289) > at java.awt.Component.processMouseEvent(Component.java:6535) > at javax.swing.JComponent.processMouseEvent(JComponent.java:3324) > at java.awt.Component.processEvent(Component.java:6300) > at java.awt.Container.processEvent(Container.java:2236) > at java.awt.Component.dispatchEventImpl(Component.java:4891) > at java.awt.Container.dispatchEventImpl(Container.java:2294) > at java.awt.Component.dispatchEvent(Component.java:4713) > at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4888) > at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4525) > at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4466) > at java.awt.Container.dispatchEventImpl(Container.java:2280) > at java.awt.Window.dispatchEventImpl(Window.java:2750) > at java.awt.Component.dispatchEvent(Component.java:4713) > at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758) > at java.awt.EventQueue.access$500(EventQueue.java:97) > at java.awt.EventQueue$3.run(EventQueue.java:709) > at java.awt.EventQueue$3.run(EventQueue.java:703) > at java.security.AccessController.doPrivileged(Native Method) > at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76) > at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86) > at java.awt.EventQueue$4.run(EventQueue.java:731) > at java.awt.EventQueue$4.run(EventQueue.java:729) > at java.security.AccessController.doPrivileged(Native Method) > at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76) > at java.awt.EventQueue.dispatchEvent(EventQueue.java:728) > at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201) > at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) > at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) > at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1784) AttachmentHandler does not use the right directory when saving more than 1 file

by Jean-Francois Denise (JIRA)

Jean-Francois Denise created WFCORE-1784: -------------------------------------------- Summary: AttachmentHandler does not use the right directory when saving more than 1 file Key: WFCORE-1784 URL: https://issues.jboss.org/browse/WFCORE-1784 Project: WildFly Core Issue Type: Bug Components: CLI Reporter: Jean-Francois Denise Assignee: Jean-Francois Denise By mistake, the default directory is used for files when the file to save is renamed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1783) CLI GUI throws exception when editing boolean attribute with expression

by Ivo Hrádek (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1783?page=com.atlassian.jira.plugi... ] Ivo Hrádek edited comment on WFCORE-1783 at 9/12/16 8:16 AM: ------------------------------------------------------------- Hi, I've made simple PR [1] to fix this. Also note that boolean attributes, can be set only to true/false through modal dialog in GUI, however you can edit _cmd_ input in order to set it to some expression. btw: I think this should be in WFCORE. -- [1] https://github.com/wildfly/wildfly-core/pull/1789 was (Author: ihradek): Hi, I've made simple PR [1] to fix this. Also note that boolean attributes, can be set only to true/false through modal dialog in GUI, however you can edit *cmd* input in order to set it to some expression. btw: I think this should be in WFCORE. -- [1] https://github.com/wildfly/wildfly-core/pull/1789 > CLI GUI throws exception when editing boolean attribute with expression > ----------------------------------------------------------------------- > > Key: WFCORE-1783 > URL: https://issues.jboss.org/browse/WFCORE-1783 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: John Mazzitelli > Assignee: Alexey Loubyansky > Priority: Minor > > When in the CLI GUI, if you try to edit a boolean attribute whose current value is an expression then an exception is thrown and you can't edit it - the popup dialog is really small and blank. > See "Steps to Reproduce" for replication procedures. > Here's the exception: > java.lang.IllegalArgumentException > at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:66) > at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:262) > at org.jboss.as.cli.gui.OperationDialog$RequestProp.setInputComponentValue(OperationDialog.java:428) > at org.jboss.as.cli.gui.OperationDialog$RequestProp.<init>(OperationDialog.java:336) > at org.jboss.as.cli.gui.OperationDialog.setProps(OperationDialog.java:157) > at org.jboss.as.cli.gui.OperationDialog.<init>(OperationDialog.java:73) > at org.jboss.as.cli.gui.OperationMenu$OperationAction.actionPerformed(OperationMenu.java:152) > at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2022) > at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2348) > at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402) > at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259) > at javax.swing.AbstractButton.doClick(AbstractButton.java:376) > at javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:833) > at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:877) > at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:289) > at java.awt.Component.processMouseEvent(Component.java:6535) > at javax.swing.JComponent.processMouseEvent(JComponent.java:3324) > at java.awt.Component.processEvent(Component.java:6300) > at java.awt.Container.processEvent(Container.java:2236) > at java.awt.Component.dispatchEventImpl(Component.java:4891) > at java.awt.Container.dispatchEventImpl(Container.java:2294) > at java.awt.Component.dispatchEvent(Component.java:4713) > at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4888) > at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4525) > at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4466) > at java.awt.Container.dispatchEventImpl(Container.java:2280) > at java.awt.Window.dispatchEventImpl(Window.java:2750) > at java.awt.Component.dispatchEvent(Component.java:4713) > at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758) > at java.awt.EventQueue.access$500(EventQueue.java:97) > at java.awt.EventQueue$3.run(EventQueue.java:709) > at java.awt.EventQueue$3.run(EventQueue.java:703) > at java.security.AccessController.doPrivileged(Native Method) > at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76) > at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86) > at java.awt.EventQueue$4.run(EventQueue.java:731) > at java.awt.EventQueue$4.run(EventQueue.java:729) > at java.security.AccessController.doPrivileged(Native Method) > at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76) > at java.awt.EventQueue.dispatchEvent(EventQueue.java:728) > at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201) > at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) > at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) > at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1783) CLI GUI throws exception when editing boolean attribute with expression

by Ivo Hrádek (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1783?page=com.atlassian.jira.plugi... ] Ivo Hrádek moved WFLY-6739 to WFCORE-1783: ------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-1783 (was: WFLY-6739) Component/s: CLI (was: CLI) Affects Version/s: (was: 10.0.0.Final) > CLI GUI throws exception when editing boolean attribute with expression > ----------------------------------------------------------------------- > > Key: WFCORE-1783 > URL: https://issues.jboss.org/browse/WFCORE-1783 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: John Mazzitelli > Assignee: Alexey Loubyansky > Priority: Minor > > When in the CLI GUI, if you try to edit a boolean attribute whose current value is an expression then an exception is thrown and you can't edit it - the popup dialog is really small and blank. > See "Steps to Reproduce" for replication procedures. > Here's the exception: > java.lang.IllegalArgumentException > at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:66) > at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:262) > at org.jboss.as.cli.gui.OperationDialog$RequestProp.setInputComponentValue(OperationDialog.java:428) > at org.jboss.as.cli.gui.OperationDialog$RequestProp.<init>(OperationDialog.java:336) > at org.jboss.as.cli.gui.OperationDialog.setProps(OperationDialog.java:157) > at org.jboss.as.cli.gui.OperationDialog.<init>(OperationDialog.java:73) > at org.jboss.as.cli.gui.OperationMenu$OperationAction.actionPerformed(OperationMenu.java:152) > at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2022) > at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2348) > at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402) > at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259) > at javax.swing.AbstractButton.doClick(AbstractButton.java:376) > at javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:833) > at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:877) > at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:289) > at java.awt.Component.processMouseEvent(Component.java:6535) > at javax.swing.JComponent.processMouseEvent(JComponent.java:3324) > at java.awt.Component.processEvent(Component.java:6300) > at java.awt.Container.processEvent(Container.java:2236) > at java.awt.Component.dispatchEventImpl(Component.java:4891) > at java.awt.Container.dispatchEventImpl(Container.java:2294) > at java.awt.Component.dispatchEvent(Component.java:4713) > at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4888) > at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4525) > at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4466) > at java.awt.Container.dispatchEventImpl(Container.java:2280) > at java.awt.Window.dispatchEventImpl(Window.java:2750) > at java.awt.Component.dispatchEvent(Component.java:4713) > at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758) > at java.awt.EventQueue.access$500(EventQueue.java:97) > at java.awt.EventQueue$3.run(EventQueue.java:709) > at java.awt.EventQueue$3.run(EventQueue.java:703) > at java.security.AccessController.doPrivileged(Native Method) > at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76) > at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86) > at java.awt.EventQueue$4.run(EventQueue.java:731) > at java.awt.EventQueue$4.run(EventQueue.java:729) > at java.security.AccessController.doPrivileged(Native Method) > at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76) > at java.awt.EventQueue.dispatchEvent(EventQueue.java:728) > at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201) > at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) > at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) > at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6739) CLI GUI throws exception when editing boolean attribute with expression

by Ivo Hrádek (JIRA)

[ https://issues.jboss.org/browse/WFLY-6739?page=com.atlassian.jira.plugin.... ] Ivo Hrádek commented on WFLY-6739: ---------------------------------- Hi, I've made simple PR [1] to fix this. Also note that boolean attributes, can be set only to true/false through modal dialog in GUI, however you can edit *cmd* input in order to set it to some expression. btw: I think this should be in WFCORE. -- [1] https://github.com/wildfly/wildfly-core/pull/1789 > CLI GUI throws exception when editing boolean attribute with expression > ----------------------------------------------------------------------- > > Key: WFLY-6739 > URL: https://issues.jboss.org/browse/WFLY-6739 > Project: WildFly > Issue Type: Bug > Components: CLI > Affects Versions: 10.0.0.Final > Reporter: John Mazzitelli > Assignee: Alexey Loubyansky > Priority: Minor > > When in the CLI GUI, if you try to edit a boolean attribute whose current value is an expression then an exception is thrown and you can't edit it - the popup dialog is really small and blank. > See "Steps to Reproduce" for replication procedures. > Here's the exception: > java.lang.IllegalArgumentException > at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:66) > at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:262) > at org.jboss.as.cli.gui.OperationDialog$RequestProp.setInputComponentValue(OperationDialog.java:428) > at org.jboss.as.cli.gui.OperationDialog$RequestProp.<init>(OperationDialog.java:336) > at org.jboss.as.cli.gui.OperationDialog.setProps(OperationDialog.java:157) > at org.jboss.as.cli.gui.OperationDialog.<init>(OperationDialog.java:73) > at org.jboss.as.cli.gui.OperationMenu$OperationAction.actionPerformed(OperationMenu.java:152) > at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2022) > at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2348) > at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402) > at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259) > at javax.swing.AbstractButton.doClick(AbstractButton.java:376) > at javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:833) > at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:877) > at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:289) > at java.awt.Component.processMouseEvent(Component.java:6535) > at javax.swing.JComponent.processMouseEvent(JComponent.java:3324) > at java.awt.Component.processEvent(Component.java:6300) > at java.awt.Container.processEvent(Container.java:2236) > at java.awt.Component.dispatchEventImpl(Component.java:4891) > at java.awt.Container.dispatchEventImpl(Container.java:2294) > at java.awt.Component.dispatchEvent(Component.java:4713) > at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4888) > at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4525) > at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4466) > at java.awt.Container.dispatchEventImpl(Container.java:2280) > at java.awt.Window.dispatchEventImpl(Window.java:2750) > at java.awt.Component.dispatchEvent(Component.java:4713) > at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758) > at java.awt.EventQueue.access$500(EventQueue.java:97) > at java.awt.EventQueue$3.run(EventQueue.java:709) > at java.awt.EventQueue$3.run(EventQueue.java:703) > at java.security.AccessController.doPrivileged(Native Method) > at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76) > at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86) > at java.awt.EventQueue$4.run(EventQueue.java:731) > at java.awt.EventQueue$4.run(EventQueue.java:729) > at java.security.AccessController.doPrivileged(Native Method) > at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76) > at java.awt.EventQueue.dispatchEvent(EventQueue.java:728) > at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201) > at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) > at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) > at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7063) IdentityLoginModuleTestCase is incorrect

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-7063?page=com.atlassian.jira.plugin.... ] Kabir Khan updated WFLY-7063: ----------------------------- Fix Version/s: 11.0.0.Alpha1 > IdentityLoginModuleTestCase is incorrect > ---------------------------------------- > > Key: WFLY-7063 > URL: https://issues.jboss.org/browse/WFLY-7063 > Project: WildFly > Issue Type: Bug > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Fix For: 11.0.0.Alpha1 > > > This test assumes that the security path of '/' will be a wildcard match, while in reality it should only match the root url. This test only passed due to UNDERTOW-805 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2099) TP: one single thread pool

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2099?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2099: -------------------------------- Hmm... instead of spawning a new thread when the thread pool is full, perhaps an internal thread pool (no queue, min=0, max=4) that's not exposed to configuration would be better: internal requests received within the idle timeout would allow us to reuse the thread(s) spawned by the pool. This would not be more costly that spawning a new thread every time... A {{RejectedExecutionException}} could still be handled by spawning a new thread, but this should almost never occur. > TP: one single thread pool > -------------------------- > > Key: JGRP-2099 > URL: https://issues.jboss.org/browse/JGRP-2099 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > Currently, TP has 4 thread pools: > * OOB > * Regular > * Internal > * Timer (used by TimeScheduler3) > The reason for this was mainly to prevent certain types of tasks from getting dropped due to a full pool. However, this can be changed by (1) making the pool have no queue and (2) handling the RejectedExecutionException (e.g. by spawning a new thread, or upping the max-threads value) for (e.g.) INTERNAL messages and timer tasks. > This not only simplify configuration (1 config section rather than 4), but also reduces the size of TP (removal of accessors, attributes). Things might also become a bit faster as a result. > The new common pool would have the following characteristics: > * Default rejection policy of "abort" (so we can handle pool exhaustion) > * No queue ({{SynchronousQueue}}), so new threads up to max-threads are created if none of the existing ones are available. The queue config attribute will be removed > * Catch RejectedExecutionException for INTERNAL messages and timer tasks. A new thread will be spawned on a RejectedExecutionException. This will be used mainly by INTERNAL messages and timer tasks > * Alternatively, we could increase max-threads (if {{ergonomics==true}}) if we get a constant rate of these exceptions -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1774) Use core-service=capability-registry to provide tab completion suggestions for model reference attributes

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1774?page=com.atlassian.jira.plugi... ] Jean-Francois Denise commented on WFCORE-1774: ---------------------------------------------- [~brian.stansberry], I am wandering if looking at the last part of the name of a resource would allow to fully identify the capability. There is 2 * in the pattern, so the dynamic part of the capability should be composed of 2 items. For example: org.wildly.clustering.transport.diagnostics-socket-binding ==> /subsystem=jgroups/stack=*/transport=* We should propose: tcp.TCP, udp.UDP, ... I have been looking at the /core-service=capability-registry resource.capabilities list content. This list seems to contain all the registered capabilities. It seems that it contains enough information to complete capabilities. Am I right or does the resources tree contains more? A possible algorithm would be to: 1 Retrieve all capabilities from the registry 2 Expose all capabilities names that starts with the static part (retrieved in the capability-reference). static part being removed from the names exposed by completion. For the diagnostics-socket-binding example, the registry contains: org.wildfly.clustering.transport.diagnostics-socket-binding.tcp.TCP org.wildfly.clustering.transport.diagnostics-socket-binding.udp.UDP org.wildfly.clustering.transport.diagnostics-socket-binding.anothertcp.TCP The completion would propose: tcp.TCP udp.UDP anothertcp.TCP I have a question related to static capabilities. Does it makes sense to have an argument to reference one? What would be the value for a static one? Thanks. > Use core-service=capability-registry to provide tab completion suggestions for model reference attributes > --------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1774 > URL: https://issues.jboss.org/browse/WFCORE-1774 > Project: WildFly Core > Issue Type: Enhancement > Components: CLI > Reporter: Brian Stansberry > Assignee: Jean-Francois Denise > > A "model reference" attribute is one whose value points to some other aspect of the model, e.g. "socket-binding" => "http". With the capability and requirement function we are rolling out in the server[1] we have the ability for clients to understand what values are valid for the reference. This should be used in CLI tab completion. > [~claudio4j] has utitlized this for UI suggestions in HAL so he or Harald can be a resource for the exact algorithm that has worked best. Here's the basics though: > 1) This applies to attributes or operation params where the read-resource-description or read-operation-description includes a "capability-reference" field. The value of the field shows the static portion of the capability name. For example an attribute that's used for a socket binding name would show "org.wildfly.network.socket-binding". > 2) The [/host=*]/core-service=capability resource shows information about what capabilities are available on the system. This includes 2 attributes "capabilities" and "possible-capabilities". The former shows the specific capabilities that are actually present; i.e. the resources that provide the capability are part of the configuration. The latter shows capabilities that could be present, given the installed extensions, if the relevant resources were added. > That resource includes two operations "get-capability" and "get-provider-points" that can show more details about what resources provide a capability: > {code} > [standalone@embedded core-service=capability-registry] :get-provider-points(name=org.wildfly.network.socket-binding) > { > "outcome" => "success", > "result" => ["/socket-binding-group=*/socket-binding=*"] > } > {code} > That tells you that capabilities of type org.wildfly.network.socket-binding are registered by resources using address pattern /socket-binding-group=*/socket-binding=* > 3) With that information the CLI can see what resources actually exist on the system and use the value portion of the final element of their address as the suggestion list for tab completion. > HAL may be doing something slightly different from what I describe; they have concrete experience. > It may be possible for the API exposed by core-service=capability-registry to be enhanced to make this easier. If you want something, please don't hesitate to ask Tomaz Cerar or myself. > [1] https://docs.jboss.org/author/display/WFLY/Working+with+WildFly+Capabilities -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7091) Not able to configure list of key/trust managers on elytron ssl context.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7091?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-7091: ---------------------------------------- The references capability is of multiple key-managers and trust managers: - https://developer.jboss.org/wiki/WildFlySecurityElytron-CapabilitiesAndRe... Although the API is about having an array with multiple 'Managers' the reality is this always tends to be an array of length 1 containing just an X.509 manager. If aggregation is ever justified instead of supporting the list here I think I would add aggregate-key/trust-manager resources which is a similar pattern to how other components are currently aggregated, > Not able to configure list of key/trust managers on elytron ssl context. > ------------------------------------------------------------------------ > > Key: WFLY-7091 > URL: https://issues.jboss.org/browse/WFLY-7091 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Darran Lofthouse > > Base on xsd/model documentation key-managers and trust-managers attributes seems to be meant to hold list of managers. That also comply to SSLContext init() method [1]. Hovewer, in elytron subsystem, they are of type string and any my tries to set list (space/comma delimited list) failed. > XSD documentation > * key-managers - Reference to the KeyManagers to be used by this SSLContext. > * trust-managers - Reference to the TrustManagers to be used by this SSLContext. > Model description: > {noformat} > "key-managers" => { > "type" => STRING, > "description" => "Reference to the key managers to use within the SSLContext.", > "expressions-allowed" => false, > "nillable" => true, > "capability-reference" => "org.wildfly.security.key-managers", > "min-length" => 1L, > "max-length" => 2147483647L, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > "trust-managers" => { > "type" => STRING, > "description" => "Reference to the trust managers to use within the SSLContext.", > "expressions-allowed" => false, > "nillable" => true, > "capability-reference" => "org.wildfly.security.trust-managers", > "min-length" => 1L, > "max-length" => 2147483647L, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > {noformat} > [1] https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLContext.html#i... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7076) Elytron introduces SSL/TLS protocol constraints

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7076?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-7076: ---------------------------------------- For the subsystem yes we need to drop it to being String based, within Elytron start a discussion in HipChat when everyone around as we have the filtering mechanism there that makes use of the enum. > Elytron introduces SSL/TLS protocol constraints > ----------------------------------------------- > > Key: WFLY-7076 > URL: https://issues.jboss.org/browse/WFLY-7076 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Jan Kalina > > {noformat} > "protocols" => { > "type" => LIST, > "description" => "The enabled protocols.", > "expressions-allowed" => true, > "nillable" => false, > "allowed" => [ > "SSLv2", > "SSLv3", > "TLSv1", > "TLSv1_1", > "TLSv1_2", > "TLSv1_3" > ], > "value-type" => STRING, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > {noformat} > Why elytron on this place is going to validate user input and map standard java values [1] into proprietary values? > Whereas on other similar places (KeyManager algorithm, TrustManager algorithm, Keystore types) it leaves up to user to set proper value. > IMO, with such mapping another place, where bugs can raise was introduced. EAP will be here always one step back compared to java. > Note, IBM java already today defines little bit different protocols set [2] > I wonder, where is that mapping "TLSv1_2 -> TLSv1.2" acually performed? I couldn't find that place. > [1] https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardN... > [2] http://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.secu... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1782) Wildfly 10.1.0 blocks calls to Singleton EJBs in PostConstruct

by Dietrich Schmidt (JIRA)

Dietrich Schmidt created WFCORE-1782: ---------------------------------------- Summary: Wildfly 10.1.0 blocks calls to Singleton EJBs in PostConstruct Key: WFCORE-1782 URL: https://issues.jboss.org/browse/WFCORE-1782 Project: WildFly Core Issue Type: Bug Components: Server Affects Versions: 2.2.0.Final Environment: Wildfly 10.1.0 running under Windows 10 with Java 1.8.0_91 Reporter: Dietrich Schmidt Assignee: Jason Greene Fix For: 2.2.1.Final Attachments: Verklemmung.zip Wildfly 8.2.0 and 10.0.0 work fine with a Singleton Bean, which has a @Postconstruct method and in this method several threads are created with the ManagedExecutorService. These threads call a method in another Singleton EJB, which has been injected. This call is blocked in Wildfly 10.1.0 until the Prostconstruct thread has ended. I assume that the behaviour of Wildfly 8.2.0 + 10.0.0 is correct and the behaviour of Wildfly 10.1.0 is a bug. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6957) Deployed JSF application crashing with MyFaces 2.2.x due to unresolved dependency

by Dmitrii Tikhomirov (JIRA)

[ https://issues.jboss.org/browse/WFLY-6957?page=com.atlassian.jira.plugin.... ] Dmitrii Tikhomirov deleted WFLY-6957: ------------------------------------- > Deployed JSF application crashing with MyFaces 2.2.x due to unresolved dependency > --------------------------------------------------------------------------------- > > Key: WFLY-6957 > URL: https://issues.jboss.org/browse/WFLY-6957 > Project: WildFly > Issue Type: Bug > Reporter: Farah Juma > Assignee: Dmitrii Tikhomirov > Priority: Critical > > Deployed JSF application will crash with installed MyFaces 2.2.x, see attached log. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JASSIST-263) ClassPool cannot read generated classes

by Paul Pogonyshev (JIRA)

[ https://issues.jboss.org/browse/JASSIST-263?page=com.atlassian.jira.plugi... ] Paul Pogonyshev commented on JASSIST-263: ----------------------------------------- Is there maybe some way to give it access through findResource? > ClassPool cannot read generated classes > --------------------------------------- > > Key: JASSIST-263 > URL: https://issues.jboss.org/browse/JASSIST-263 > Project: Javassist > Issue Type: Bug > Affects Versions: 3.20.0-GA > Reporter: Paul Pogonyshev > Assignee: Shigeru Chiba > Attachments: JavassistBug.java > > > ClassPool.get() cannot retrieve classes that are in turn generated at runtime. For example, if I try to define at runtime two classes, one of which extends another, the base will not be found, even though it can be retrieved just fine from my class loader. See the attached example. > As far as I could trace it, the issue comes from ClassPoolTail.find() returning a null URL for the class. This is understandable, since class definition doesn't exist as a file --- it is generated at runtime. However, ClassPool.get() should still succeed for classes that have no URL, yet can be found through its ClassLoader. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6596) WrongClassException when using infinispan as remote-store for hibernate entity cache

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/WFLY-6596?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on WFLY-6596: ----------------------------------- [~sebersole] It is leading to shared cache region (for all entities) because with the mentioned configuration the entity caches are merely proxies to single cache located in different cluster. [~gvwolf3d] So I understand that your DB is so heavily used that adding one RPC to the remote cluster upon each read (which fails if the entity is missing) is still better than trying to read it from DB directly. Do you have any estimate of modifications vs. reads? We have considered implementing 2LC on top of Hot Rod protocol (Infinispan's native = most efficient way to talk to remote cluster) but the cost above always seemed to high. There was some hope that with near caching (keeping some entries on clients = exactly what you don't want to do) this could be viable, but later we've realized that we could not keep strict consistency guarantees with this near cache. However, your case supports the idea that 2LC on Hot Rod without near cache could be worthwhile as well. > WrongClassException when using infinispan as remote-store for hibernate entity cache > ------------------------------------------------------------------------------------ > > Key: WFLY-6596 > URL: https://issues.jboss.org/browse/WFLY-6596 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 10.0.0.Final, 10.1.0.Final > Environment: Java version: 1.8.0_45, vendor: Oracle Corporation > Java home: C:\Program Files\Java\jdk1.8.0_45\jre > Default locale: de_DE, platform encoding: Cp1252 > OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "dos" > Infifnspan 8.1.2 or 8.2.0 > Reporter: Gunther v. Wolffersdorff > Assignee: Scott Marlow > Labels: inifinispan-commons, org.hibernate.WrongClassException, remote-store > Attachments: ClassicalCacheKeysFactory.java, clustered.sample.xml, infinispan.zip, sample-10.1.0.Final-2.zip, sample-10.1.0.Final-fix.zip, sample-10.1.0.Final.zip, sample.zip, standalone.sample.ha-10.1.0.Final.xml, standalone.sample.ha.xml > > > Starting an application and then requesting a list of cachable JPA entitties ( configured cachable using a hibernate entity invalidation-cache with a remote-server as remote-store ) causes: > {code} > 13:00:52,541 MESZ ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /sample-web/rest/members/listAll: org.jboss.resteasy.spi.UnhandledException: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=100] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member > at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:77) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:220) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:418) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805) [undertow-core-1.4.0.Final.jar:1.4.0.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_66] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_66] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66] > Caused by: javax.persistence.PersistenceException: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member > at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1692) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1602) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:492) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.jpa.criteria.compile.CriteriaQueryTypeQueryAdapter.getResultList(CriteriaQueryTypeQueryAdapter.java:50) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final] > at org.jboss.as.jpa.container.TypedQueryNonTxInvocationDetacher.getResultList(TypedQueryNonTxInvocationDetacher.java:58) [wildfly-jpa-10.1.0.Final.jar:10.1.0.Final] > at de.alvara.ticket.sample.data.MemberRepository.findAllOrderedByName(MemberRepository.java:58) [sample-ejb.jar:] > at de.alvara.ticket.sample.data.MemberRepository$Proxy$_$$_WeldClientProxy.findAllOrderedByName(Unknown Source) [sample-ejb.jar:] > at de.alvara.ticket.sample.rest.MemberResourceRESTService.listAllMembers(MemberResourceRESTService.java:75) [classes:] > at de.alvara.ticket.sample.rest.MemberResourceRESTService$Proxy$_$$_WeldClientProxy.listAllMembers(Unknown Source) [classes:] > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_66] > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_66] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_66] > at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_66] > at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final] > ... 43 more > Caused by: org.hibernate.WrongClassException: Object [id=2] was not of the specified subclass [de.alvara.ticket.sample.model.Country] : loaded object was of wrong class class de.alvara.ticket.sample.model.Member > at org.hibernate.event.internal.DefaultLoadEventListener.processCachedEntry(DefaultLoadEventListener.java:631) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.loadFromSecondLevelCache(DefaultLoadEventListener.java:602) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:462) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:219) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:278) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.doOnLoad(DefaultLoadEventListener.java:121) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:89) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1129) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.internal.SessionImpl.internalLoad(SessionImpl.java:1022) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:632) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.type.EntityType.resolve(EntityType.java:424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:154) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:128) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:1133) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.processResultSet(Loader.java:992) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.doQuery(Loader.java:930) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:336) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.doList(Loader.java:2617) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.doList(Loader.java:2600) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2429) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.Loader.list(Loader.java:2424) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:501) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:371) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:216) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1326) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.internal.QueryImpl.list(QueryImpl.java:87) [hibernate-core-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.jpa.internal.QueryImpl.list(QueryImpl.java:606) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final] > at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:483) [hibernate-entitymanager-5.0.10.Final.jar:5.0.10.Final] > ... 58 more > {code} > Entity cache is configured like this: > {code:xml} > ... > <invalidation-cache name="entity" mode="SYNC"> > <eviction strategy="LRU" max-entries="1000"/> > <expiration lifespan="45000" max-idle="30000"/> > <remote-store cache="hibernateDistributed" socket-timeout="60000" tcp-no-delay="true" remote-servers="local-cache-server" fetch-state="false" passivation="false" preload="false" purge="true" shared="true"/> > </invalidation-cache> > ... > <outbound-socket-binding name="local-cache-server"> > <remote-destination host="${jboss.bind.address:127.0.0.1}" port="11322"/> > </outbound-socket-binding> > ... > {code} > see standalone.sample.ha-10.1.0.Final.xml . > *This constellation works fine using Wildfly 8.2.0 and Infinispan 7.2.5 .* -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2099) TP: one single thread pool

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2099?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-2099 at 9/12/16 3:54 AM: --------------------------------------------------------- OK, the FJP behaves like a ThreadPoolExecutor with {{min=max=parallelism}} (e.g. 8) and _unbounded queues_! The only diff is work stealing. Correction: worker queues are not unbounded, but each queue can hold 64M elements (which is more or less the same as unbounded)! was (Author: belaban): OK, the FJP behaves like a ThreadPoolExecutor with {{min=max=parallelism}} (e.g. 8) and _unbounded queues_! The only diff is work stealing. Correct: worker queues are not unbounded, but each queue can hold 64M elements! > TP: one single thread pool > -------------------------- > > Key: JGRP-2099 > URL: https://issues.jboss.org/browse/JGRP-2099 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > Currently, TP has 4 thread pools: > * OOB > * Regular > * Internal > * Timer (used by TimeScheduler3) > The reason for this was mainly to prevent certain types of tasks from getting dropped due to a full pool. However, this can be changed by (1) making the pool have no queue and (2) handling the RejectedExecutionException (e.g. by spawning a new thread, or upping the max-threads value) for (e.g.) INTERNAL messages and timer tasks. > This not only simplify configuration (1 config section rather than 4), but also reduces the size of TP (removal of accessors, attributes). Things might also become a bit faster as a result. > The new common pool would have the following characteristics: > * Default rejection policy of "abort" (so we can handle pool exhaustion) > * No queue ({{SynchronousQueue}}), so new threads up to max-threads are created if none of the existing ones are available. The queue config attribute will be removed > * Catch RejectedExecutionException for INTERNAL messages and timer tasks. A new thread will be spawned on a RejectedExecutionException. This will be used mainly by INTERNAL messages and timer tasks > * Alternatively, we could increase max-threads (if {{ergonomics==true}}) if we get a constant rate of these exceptions -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2099) TP: one single thread pool

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2099?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-2099 at 9/12/16 3:53 AM: --------------------------------------------------------- OK, the FJP behaves like a ThreadPoolExecutor with {{min=max=parallelism}} (e.g. 8) and _unbounded queues_! The only diff is work stealing. Correct: worker queues are not unbounded, but each queue can hold 64M elements! was (Author: belaban): OK, the FJP behaves like a ThreadPoolExecutor with {{min=max=parallelism}} (e.g. 8) and _unbounded queues_! The only diff is work stealing. > TP: one single thread pool > -------------------------- > > Key: JGRP-2099 > URL: https://issues.jboss.org/browse/JGRP-2099 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > Currently, TP has 4 thread pools: > * OOB > * Regular > * Internal > * Timer (used by TimeScheduler3) > The reason for this was mainly to prevent certain types of tasks from getting dropped due to a full pool. However, this can be changed by (1) making the pool have no queue and (2) handling the RejectedExecutionException (e.g. by spawning a new thread, or upping the max-threads value) for (e.g.) INTERNAL messages and timer tasks. > This not only simplify configuration (1 config section rather than 4), but also reduces the size of TP (removal of accessors, attributes). Things might also become a bit faster as a result. > The new common pool would have the following characteristics: > * Default rejection policy of "abort" (so we can handle pool exhaustion) > * No queue ({{SynchronousQueue}}), so new threads up to max-threads are created if none of the existing ones are available. The queue config attribute will be removed > * Catch RejectedExecutionException for INTERNAL messages and timer tasks. A new thread will be spawned on a RejectedExecutionException. This will be used mainly by INTERNAL messages and timer tasks > * Alternatively, we could increase max-threads (if {{ergonomics==true}}) if we get a constant rate of these exceptions -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2099) TP: one single thread pool

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2099?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2099: -------------------------------- OK, the FJP behaves like a ThreadPoolExecutor with {{min=max=parallelism}} (e.g. 8) and _unbounded queues_! The only diff is work stealing. > TP: one single thread pool > -------------------------- > > Key: JGRP-2099 > URL: https://issues.jboss.org/browse/JGRP-2099 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > Currently, TP has 4 thread pools: > * OOB > * Regular > * Internal > * Timer (used by TimeScheduler3) > The reason for this was mainly to prevent certain types of tasks from getting dropped due to a full pool. However, this can be changed by (1) making the pool have no queue and (2) handling the RejectedExecutionException (e.g. by spawning a new thread, or upping the max-threads value) for (e.g.) INTERNAL messages and timer tasks. > This not only simplify configuration (1 config section rather than 4), but also reduces the size of TP (removal of accessors, attributes). Things might also become a bit faster as a result. > The new common pool would have the following characteristics: > * Default rejection policy of "abort" (so we can handle pool exhaustion) > * No queue ({{SynchronousQueue}}), so new threads up to max-threads are created if none of the existing ones are available. The queue config attribute will be removed > * Catch RejectedExecutionException for INTERNAL messages and timer tasks. A new thread will be spawned on a RejectedExecutionException. This will be used mainly by INTERNAL messages and timer tasks > * Alternatively, we could increase max-threads (if {{ergonomics==true}}) if we get a constant rate of these exceptions -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2099) TP: one single thread pool

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2099?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2099: -------------------------------- Hmm, what happens when the FJP is _full_? 'Full ' meaning all threads allocated in the pool are blocked, e.g. trying to acquire a lock, and don't use the {{ManagedBlocker}} interface to make the pool allocate a new thread. Critical messages like heartbeats or credits cannot just be added to the work queue for a thread, as they need to be processed _immediately_! Need to experiment with * all threads sleeping for a while (mimicking non-managed blocking) * injecting a lot of work into the FJP * IIRC work queues are bounded at 65K, need to see what happens when we exceed that: {{RejectedExecutionException}}? > TP: one single thread pool > -------------------------- > > Key: JGRP-2099 > URL: https://issues.jboss.org/browse/JGRP-2099 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > Currently, TP has 4 thread pools: > * OOB > * Regular > * Internal > * Timer (used by TimeScheduler3) > The reason for this was mainly to prevent certain types of tasks from getting dropped due to a full pool. However, this can be changed by (1) making the pool have no queue and (2) handling the RejectedExecutionException (e.g. by spawning a new thread, or upping the max-threads value) for (e.g.) INTERNAL messages and timer tasks. > This not only simplify configuration (1 config section rather than 4), but also reduces the size of TP (removal of accessors, attributes). Things might also become a bit faster as a result. > The new common pool would have the following characteristics: > * Default rejection policy of "abort" (so we can handle pool exhaustion) > * No queue ({{SynchronousQueue}}), so new threads up to max-threads are created if none of the existing ones are available. The queue config attribute will be removed > * Catch RejectedExecutionException for INTERNAL messages and timer tasks. A new thread will be spawned on a RejectedExecutionException. This will be used mainly by INTERNAL messages and timer tasks > * Alternatively, we could increase max-threads (if {{ergonomics==true}}) if we get a constant rate of these exceptions -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7080) Creating ssl context with only required attribute cause NPE

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7080?page=com.atlassian.jira.plugin.... ] Jan Kalina commented on WFLY-7080: ---------------------------------- Linked. (commit "SSL client side - allow null keyManager") > Creating ssl context with only required attribute cause NPE > ----------------------------------------------------------- > > Key: WFLY-7080 > URL: https://issues.jboss.org/browse/WFLY-7080 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Critical > Fix For: 11.0.0.Alpha1 > > > {noformat} > [standalone@localhost:9990 /] /subsystem=elytron/server-ssl-context=server2:add(protocols=[TLSv1_2]) > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.server2" => "org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service > Caused by: java.lang.NullPointerException"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.ssl-context.server2"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > }, > "rolled-back" => true > } > {noformat} > In log of server there is exception: > {noformat} > 07:12:21,014 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service org.wildfly.security.ssl-context.server2: org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NullPointerException > at org.wildfly.security.ssl.SSLContextBuilder.lambda$build$0(SSLContextBuilder.java:275) > at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:45) > at org.wildfly.extension.elytron.SSLDefinitions$3.lambda$getValueSupplier$1(SSLDefinitions.java:411) > at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > ... 3 more > 07:12:21,016 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 6) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("server-ssl-context" => "server2") > ]) - failure description: { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.server2" => "org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service > Caused by: java.lang.NullPointerException"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.ssl-context.server2"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7080) Creating ssl context with only required attribute cause NPE

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7080?page=com.atlassian.jira.plugin.... ] Jan Kalina updated WFLY-7080: ----------------------------- Git Pull Request: https://github.com/wildfly-security/elytron-subsystem/pull/210, https://github.com/wildfly-security/wildfly-elytron/pull/490 (was: https://github.com/wildfly-security/elytron-subsystem/pull/210) > Creating ssl context with only required attribute cause NPE > ----------------------------------------------------------- > > Key: WFLY-7080 > URL: https://issues.jboss.org/browse/WFLY-7080 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Critical > Fix For: 11.0.0.Alpha1 > > > {noformat} > [standalone@localhost:9990 /] /subsystem=elytron/server-ssl-context=server2:add(protocols=[TLSv1_2]) > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.server2" => "org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service > Caused by: java.lang.NullPointerException"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.ssl-context.server2"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > }, > "rolled-back" => true > } > {noformat} > In log of server there is exception: > {noformat} > 07:12:21,014 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service org.wildfly.security.ssl-context.server2: org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NullPointerException > at org.wildfly.security.ssl.SSLContextBuilder.lambda$build$0(SSLContextBuilder.java:275) > at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:45) > at org.wildfly.extension.elytron.SSLDefinitions$3.lambda$getValueSupplier$1(SSLDefinitions.java:411) > at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > ... 3 more > 07:12:21,016 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 6) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("server-ssl-context" => "server2") > ]) - failure description: { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.server2" => "org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service > Caused by: java.lang.NullPointerException"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.ssl-context.server2"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7080) Creating ssl context with only required attribute cause NPE

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFLY-7080?page=com.atlassian.jira.plugin.... ] Martin Choma commented on WFLY-7080: ------------------------------------ Could you link elytron PR, as well? > Creating ssl context with only required attribute cause NPE > ----------------------------------------------------------- > > Key: WFLY-7080 > URL: https://issues.jboss.org/browse/WFLY-7080 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Critical > Fix For: 11.0.0.Alpha1 > > > {noformat} > [standalone@localhost:9990 /] /subsystem=elytron/server-ssl-context=server2:add(protocols=[TLSv1_2]) > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.server2" => "org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service > Caused by: java.lang.NullPointerException"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.ssl-context.server2"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > }, > "rolled-back" => true > } > {noformat} > In log of server there is exception: > {noformat} > 07:12:21,014 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service org.wildfly.security.ssl-context.server2: org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NullPointerException > at org.wildfly.security.ssl.SSLContextBuilder.lambda$build$0(SSLContextBuilder.java:275) > at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:45) > at org.wildfly.extension.elytron.SSLDefinitions$3.lambda$getValueSupplier$1(SSLDefinitions.java:411) > at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > ... 3 more > 07:12:21,016 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 6) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("server-ssl-context" => "server2") > ]) - failure description: { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.server2" => "org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server2: Failed to start service > Caused by: java.lang.NullPointerException"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.ssl-context.server2"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2016