[JBoss JIRA] (JBJCA-1334) Add DataSource to ManagementRepository only after deployed successfully
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1334?page=com.atlassian.jira.plugin... ]
Lin Gao commented on JBJCA-1334:
--------------------------------
This Jira is created by cloning the WFLY-7214.
The reason for the problem is that {{AbstractDsDeployer}} [added the DataSource into ManagementRepository|https://github.com/ironjacamar/ironjacamar/blob/1.3/...] before it knows that the DataSource deployment will succeed. Move the addition a little late will solve the problem.
> Add DataSource to ManagementRepository only after deployed successfully
> -----------------------------------------------------------------------
>
> Key: JBJCA-1334
> URL: https://issues.jboss.org/browse/JBJCA-1334
> Project: IronJacamar
> Issue Type: Bug
> Components: Deployer
> Reporter: Lin Gao
> Assignee: Jesper Pedersen
>
> When a data-source was failed to be added either because of missing connection-properties:
> {code:}
> /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, datasource-class=XXX,driver-name=h2)
> {code}
> or missing of connection-url:
> {code:}
> /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, driver-name=h2)
> {code}
> , it can be added by correcting the information, like:
> {code:}
> [standalone@localhost:9990 /] /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, driver-name=h2,connection-url="jdbc:h2:test")
> {"outcome" => "success"}
> {code}
> But the {{test-connection-in-pool()}} operation failed with {{IllegalStateException}} of the new created data-source.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JBJCA-1334) Add DataSource to ManagementRepository only after deployed successfully
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1334?page=com.atlassian.jira.plugin... ]
Lin Gao moved WFLY-7237 to JBJCA-1334:
--------------------------------------
Project: IronJacamar (was: WildFly)
Key: JBJCA-1334 (was: WFLY-7237)
Workflow: classic default workflow (was: GIT Pull Request workflow )
Component/s: Deployer
(was: JCA)
> Add DataSource to ManagementRepository only after deployed successfully
> -----------------------------------------------------------------------
>
> Key: JBJCA-1334
> URL: https://issues.jboss.org/browse/JBJCA-1334
> Project: IronJacamar
> Issue Type: Bug
> Components: Deployer
> Reporter: Lin Gao
> Assignee: Jesper Pedersen
>
> When a data-source was failed to be added either because of missing connection-properties:
> {code:}
> /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, datasource-class=XXX,driver-name=h2)
> {code}
> or missing of connection-url:
> {code:}
> /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, driver-name=h2)
> {code}
> , it can be added by correcting the information, like:
> {code:}
> [standalone@localhost:9990 /] /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, driver-name=h2,connection-url="jdbc:h2:test")
> {"outcome" => "success"}
> {code}
> But the {{test-connection-in-pool()}} operation failed with {{IllegalStateException}} of the new created data-source.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7237) Add DataSource to ManagementRepository only after deployed successfully
by Lin Gao (JIRA)
Lin Gao created WFLY-7237:
-----------------------------
Summary: Add DataSource to ManagementRepository only after deployed successfully
Key: WFLY-7237
URL: https://issues.jboss.org/browse/WFLY-7237
Project: WildFly
Issue Type: Bug
Components: JCA
Reporter: Lin Gao
Assignee: Jesper Pedersen
When a data-source was failed to be added either because of missing connection-properties:
{code:}
/subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, datasource-class=XXX,driver-name=h2)
{code}
or missing of connection-url:
{code:}
/subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, driver-name=h2)
{code}
, it can be added by correcting the information, like:
{code:}
[standalone@localhost:9990 /] /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, driver-name=h2,connection-url="jdbc:h2:test")
{"outcome" => "success"}
{code}
But the {{test-connection-in-pool()}} operation failed with {{IllegalStateException}} of the new created data-source.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7236) DatasourceNonCcmTestCase fails with security manager
by Jan Tymel (JIRA)
Jan Tymel created WFLY-7236:
-------------------------------
Summary: DatasourceNonCcmTestCase fails with security manager
Key: WFLY-7236
URL: https://issues.jboss.org/browse/WFLY-7236
Project: WildFly
Issue Type: Bug
Components: Test Suite
Reporter: Jan Tymel
Assignee: Jan Tymel
*org.jboss.as.test.integration.jca.datasource.DatasourceNonCcmTestCase#testJTADS*
*org.jboss.as.test.integration.jca.datasource.DatasourceNonCcmTestCase#testNonJTADS*
{{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=org.jboss.as.test.integration.jca.datasource.DatasourceNonCcmTestCase -Dsecurity.manager}}
{code}
Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("org.jboss.remoting3.security.RemotingPermission" "createEndpoint")" in code source "(vfs:/content/dummy.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.dummy.jar:main" from Service Module Loader")
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
at org.jboss.remoting3.Remoting.createEndpoint(Remoting.java:85)
at org.jboss.remoting3.Remoting.createEndpoint(Remoting.java:112)
at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:120)
at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:64)
at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:139)
at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:114)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147)
... 146 more
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7235) InfinispanResourceRefTestCase fails with security manager
by Jan Tymel (JIRA)
Jan Tymel created WFLY-7235:
-------------------------------
Summary: InfinispanResourceRefTestCase fails with security manager
Key: WFLY-7235
URL: https://issues.jboss.org/browse/WFLY-7235
Project: WildFly
Issue Type: Bug
Components: Test Suite
Reporter: Jan Tymel
Assignee: Jan Tymel
*org.jboss.as.test.integration.ee.injection.resource.infinispan.InfinispanResourceRefTestCase#test*
{{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=org.jboss.as.test.integration.ee.injection.resource.infinispan.InfinispanResourceRefTestCase -Dsecurity.manager}}
{code}
Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/infinispan-resource-ref.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.infinispan-resource-ref.war:main" from Service Module Loader")
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1528)
at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1442)
at org.infinispan.commons.util.Util.getClassLoaders(Util.java:127)
at org.infinispan.commons.util.Util.loadClassStrict(Util.java:163)
at org.infinispan.commons.util.ReflectionUtil.getClassForName(ReflectionUtil.java:319)
at org.infinispan.commons.util.ReflectionUtil.toClassArray(ReflectionUtil.java:313)
at org.infinispan.factories.AbstractComponentRegistry$Component.buildInjectionMethodsList(AbstractComponentRegistry.java:810)
at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:213)
at org.infinispan.factories.ComponentRegistry.registerComponentInternal(ComponentRegistry.java:193)
at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:171)
at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:163)
at org.infinispan.factories.ComponentRegistry.<init>(ComponentRegistry.java:79)
... 210 more
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7226) Missing realm-map attribute for mapped-regex-realm-mapper throws IllegalArgumentException to server log
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7226?page=com.atlassian.jira.plugin.... ]
Ondrej Lukas commented on WFLY-7226:
------------------------------------
Hi [~ivassile],
realm-map for mapped-regex-realm-mapper is an Object attribute. It can be set in CLI command like this:
{code}
/subsystem=elytron/mapped-regex-realm-mapper=someName:add(pattern="(.?)",realm-map={a=b,c=d})
{code}
However the point of this issue is to provide users some understandable log for cases when realm-map attribute is missing (see CLI command in Steps to Reproduce). Currently it only throws mentioned above exception.
Try to use following command:
{code}
/subsystem=elytron/mapped-regex-realm-mapper=someName:add(realm-map={a=b,c=d})
{code}
it will result to exception with clear failure-description that pattern may not be null:
{code}
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0155: pattern may not be null",
"rolled-back" => true
}
{code}
The same should happen for missing required realm-map attribute.
> Missing realm-map attribute for mapped-regex-realm-mapper throws IllegalArgumentException to server log
> -------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7226
> URL: https://issues.jboss.org/browse/WFLY-7226
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
>
> In case when mapped-regex-realm-mapper is added through CLI and realm-map attribute is not used then IllegalArgumentException is thrown to server log instead of some CLI failure message like "realm-map may not be null".
> Expcetion in server log:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("mapped-regex-realm-mapper" => "MappedRealmMapper")
> ]): java.lang.IllegalArgumentException
> at org.jboss.dmr.ModelValue.getKeys(ModelValue.java:139)
> at org.jboss.dmr.ModelNode.keys(ModelNode.java:1378)
> at org.wildfly.extension.elytron.RealmMapperDefinitions$MappedRegexRealmMapperAddHandler.performRuntime(RealmMapperDefinitions.java:221)
> at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337)
> at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> 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}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7224) Missing validation check for simple-regex-realm-mapper and mapped-regex-realm-mapper in Elytron subsystem
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/WFLY-7224?page=com.atlassian.jira.plugin.... ]
Ilia Vassilev edited comment on WFLY-7224 at 9/29/16 12:18 AM:
---------------------------------------------------------------
Hi [~honza889]. I'm proposing the following fix [1] for this issue. Please check if the fix is correct and let me know what needs to be modified in order to complete it and submit PR. This change will also resolve https://issues.jboss.org/browse/WFLY-7225.
[1] https://github.com/ivassile/elytron-subsystem/commit/e911c17126b33614b408...
was (Author: ivassile):
Hi [~honza889]. I'm proposing the following fix [1] for this issue. Please check if the fix is correct and let me know what needs to be modified in order to complete it and submit PR. This change will also resolve https://issues.jboss.org/browse/WFLY-7225.
[1] https://github.com/ivassile/elytron-subsystem/commit/798829eec0a636b0e6e8...
> Missing validation check for simple-regex-realm-mapper and mapped-regex-realm-mapper in Elytron subsystem
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7224
> URL: https://issues.jboss.org/browse/WFLY-7224
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
>
> Elytron subsystem allows to add realm mapper (e.g. simple-regex-realm-mapper) with pattern which does not include a capture group. In case when this realm mapper is used in add operation for security domain through CLI then operation fails with incomprehensible log:
> {code}
> {
> "outcome" => "failed",
> "failure-description" => {"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined},
> "rolled-back" => true
> }
> {code}
> Exception in server log:
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.security.realm-mapper.SomeRealmMapper: org.jboss.msc.service.StartException in service org.wildfly.security.realm-mapper.SomeRealmMapper: 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.IllegalArgumentException: ELY01065: Pattern requires a capture group
> at org.wildfly.security.auth.util.SimpleRegexRealmMapper.<init>(SimpleRegexRealmMapper.java:64)
> at org.wildfly.security.auth.util.SimpleRegexRealmMapper.<init>(SimpleRegexRealmMapper.java:49)
> at org.wildfly.extension.elytron.RealmMapperDefinitions$SimpleRegexRealmMapperAddHandler.lambda$performRuntime$0(RealmMapperDefinitions.java:157)
> 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}
> The same happens for mapped-regex-realm-mapper.
> Point here is that we allow to successfully add wrong realm mapper (without capture group) but we check whether it is wrong later in security domain. This check should be done during adding wrong realm mapper to avoid following incomprehensible CLI log and exception in server log.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7224) Missing validation check for simple-regex-realm-mapper and mapped-regex-realm-mapper in Elytron subsystem
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/WFLY-7224?page=com.atlassian.jira.plugin.... ]
Ilia Vassilev edited comment on WFLY-7224 at 9/29/16 12:17 AM:
---------------------------------------------------------------
[~honza889] Sent PR [1] which is easier to review.
[1] https://github.com/wildfly-security/elytron-subsystem/pull/244
was (Author: ivassile):
[~honza889] Sent PR [1] which is easier to review.
[1] https://github.com/wildfly-security/elytron-subsystem/pull/243
> Missing validation check for simple-regex-realm-mapper and mapped-regex-realm-mapper in Elytron subsystem
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7224
> URL: https://issues.jboss.org/browse/WFLY-7224
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
>
> Elytron subsystem allows to add realm mapper (e.g. simple-regex-realm-mapper) with pattern which does not include a capture group. In case when this realm mapper is used in add operation for security domain through CLI then operation fails with incomprehensible log:
> {code}
> {
> "outcome" => "failed",
> "failure-description" => {"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined},
> "rolled-back" => true
> }
> {code}
> Exception in server log:
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.security.realm-mapper.SomeRealmMapper: org.jboss.msc.service.StartException in service org.wildfly.security.realm-mapper.SomeRealmMapper: 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.IllegalArgumentException: ELY01065: Pattern requires a capture group
> at org.wildfly.security.auth.util.SimpleRegexRealmMapper.<init>(SimpleRegexRealmMapper.java:64)
> at org.wildfly.security.auth.util.SimpleRegexRealmMapper.<init>(SimpleRegexRealmMapper.java:49)
> at org.wildfly.extension.elytron.RealmMapperDefinitions$SimpleRegexRealmMapperAddHandler.lambda$performRuntime$0(RealmMapperDefinitions.java:157)
> 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}
> The same happens for mapped-regex-realm-mapper.
> Point here is that we allow to successfully add wrong realm mapper (without capture group) but we check whether it is wrong later in security domain. This check should be done during adding wrong realm mapper to avoid following incomprehensible CLI log and exception in server log.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JGRP-2102) bind_interface="eth0" and bind_addr="LINK_LOCAL" config are conflict
by 俐佳 张 (JIRA)
[ https://issues.jboss.org/browse/JGRP-2102?page=com.atlassian.jira.plugin.... ]
俐佳 张 edited comment on JGRP-2102 at 9/28/16 11:31 PM:
------------------------------------------------------
but bind_interface is http://www.jgroups.org/schema/jgroups-4.0.xsd. I checked the code 4.0 beta, there's no fix for the issue. I can see the fixed version is 3.6.12 in the ticket do you mean that issue is fixed from this version.
was (Author: kathzhan):
but bind_interface is http://www.jgroups.org/schema/jgroups-4.0.xsd. I checked the code 4.0 beta, there's the fix for the issue. I can see the fixed version is 3.6.12 in the ticket do you mean that issue is fixed from this version.
> bind_interface="eth0" and bind_addr="LINK_LOCAL" config are conflict
> --------------------------------------------------------------------
>
> Key: JGRP-2102
> URL: https://issues.jboss.org/browse/JGRP-2102
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.1
> Environment: [root@wtc2k01v27 ~] CLONE # ip a
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> inet6 2606:ae00:e200:3f::83/128 scope global
> valid_lft forever preferred_lft forever
> inet6 ::1/128 scope host
> valid_lft forever preferred_lft forever
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
> link/ether 00:50:56:ab:2a:ea brd ff:ff:ff:ff:ff:ff
> inet 107.250.167.28/25 brd 107.250.167.127 scope global eth0
> inet6 2606:ae00:e200:3f::28/64 scope global
> valid_lft forever preferred_lft forever
> inet6 fe80::250:56ff:feab:2aea/64 scope link
> valid_lft forever preferred_lft forever
> 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
> link/ether 00:50:56:ab:d6:12 brd ff:ff:ff:ff:ff:ff
> inet 192.168.0.59/24 brd 192.168.0.255 scope global eth1
> inet6 fe80::250:56ff:feab:d612/64 scope link
> valid_lft forever preferred_lft forever
> There're eth0 and eth1 exists in the environment
> Reporter: 俐佳 张
> Assignee: Bela Ban
> Fix For: 3.6.12
>
> Attachments: jgroups-udp.xml
>
>
> Error happens while
> Caused by: org.infinispan.commons.CacheConfigurationException: ISPN000085: Error while trying to create a channel using the specified configuration file: /opt/oss/NSN-icf_notification_dispatcher/conf/jgroups-udp.xml
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:406)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannel(JGroupsTransport.java:307)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannelAndRPCDispatcher(JGroupsTransport.java:351)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:188)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:56)
> at java.lang.reflect.Method.invoke(Method.java:620)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
> at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:226)
> ... 26 more
> Caused by: java.lang.Exception: Property assignment of bind_interface in UDP with original property value eth0 and converted to null could not be assigned
> at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1153)
> at org.jgroups.stack.Configurator.createLayer(Configurator.java:444)
> at org.jgroups.stack.Configurator.createProtocols(Configurator.java:398)
> at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:90)
> at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:57)
> at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:477)
> at org.jgroups.JChannel.init(JChannel.java:854)
> at org.jgroups.JChannel.<init>(JChannel.java:159)
> at org.jgroups.JChannel.<init>(JChannel.java:129)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:404)
> ... 39 more
> Caused by: java.lang.Exception: Conversion of bind_interface in UDP with original property value eth0 failed
> at org.jgroups.conf.PropertyHelper.getConvertedValue(PropertyHelper.java:84)
> at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1147)
> ... 48 more
> Caused by: java.lang.mail(a)example.comIllegalArgumentException: network interface eth0 does not contain address fe80:0:0:0:250:56ff:feab:d612%3
> at org.jgroups.util.Util.validateBindAddressFromInterface(Util.java:3132)
> bind_interface="eth0" and bind_addr="LINK_LOCAL" config are config at the same time
> but it couldn't get the eth0 link local address but return eth1 link local address
> This code return the first address that match, it should return with eth0
> jgroups-3.6.1.Final-sources\org\jgroups\util\Util.java
> public static InetAddress getAddress(AddressScope scope) ----> scope is LINK_LOCAL
> throws SocketException
> {
> InetAddress address = null;
> Enumeration intfs = NetworkInterface.getNetworkInterfaces();
> while (intfs.hasMoreElements()) {
> NetworkInterface intf = (NetworkInterface)intfs.nextElement();
> try {
> if (intf.isUp()) {
> address = getAddress(intf, scope); -------> It will return the first LINK_LOCAL address from NICs list
> if (address != null)
> return address;
> }
> }
> catch (SocketException e) {
> }
> }
> return null;
> }
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JGRP-2102) bind_interface="eth0" and bind_addr="LINK_LOCAL" config are conflict
by 俐佳 张 (JIRA)
[ https://issues.jboss.org/browse/JGRP-2102?page=com.atlassian.jira.plugin.... ]
俐佳 张 commented on JGRP-2102:
----------------------------
sorry I double check the code of 4.0 Beta, there's no fix still. but I really think that is the bug in jgroup side.
> bind_interface="eth0" and bind_addr="LINK_LOCAL" config are conflict
> --------------------------------------------------------------------
>
> Key: JGRP-2102
> URL: https://issues.jboss.org/browse/JGRP-2102
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.1
> Environment: [root@wtc2k01v27 ~] CLONE # ip a
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> inet6 2606:ae00:e200:3f::83/128 scope global
> valid_lft forever preferred_lft forever
> inet6 ::1/128 scope host
> valid_lft forever preferred_lft forever
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
> link/ether 00:50:56:ab:2a:ea brd ff:ff:ff:ff:ff:ff
> inet 107.250.167.28/25 brd 107.250.167.127 scope global eth0
> inet6 2606:ae00:e200:3f::28/64 scope global
> valid_lft forever preferred_lft forever
> inet6 fe80::250:56ff:feab:2aea/64 scope link
> valid_lft forever preferred_lft forever
> 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
> link/ether 00:50:56:ab:d6:12 brd ff:ff:ff:ff:ff:ff
> inet 192.168.0.59/24 brd 192.168.0.255 scope global eth1
> inet6 fe80::250:56ff:feab:d612/64 scope link
> valid_lft forever preferred_lft forever
> There're eth0 and eth1 exists in the environment
> Reporter: 俐佳 张
> Assignee: Bela Ban
> Fix For: 3.6.12
>
> Attachments: jgroups-udp.xml
>
>
> Error happens while
> Caused by: org.infinispan.commons.CacheConfigurationException: ISPN000085: Error while trying to create a channel using the specified configuration file: /opt/oss/NSN-icf_notification_dispatcher/conf/jgroups-udp.xml
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:406)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannel(JGroupsTransport.java:307)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannelAndRPCDispatcher(JGroupsTransport.java:351)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:188)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:56)
> at java.lang.reflect.Method.invoke(Method.java:620)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
> at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:226)
> ... 26 more
> Caused by: java.lang.Exception: Property assignment of bind_interface in UDP with original property value eth0 and converted to null could not be assigned
> at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1153)
> at org.jgroups.stack.Configurator.createLayer(Configurator.java:444)
> at org.jgroups.stack.Configurator.createProtocols(Configurator.java:398)
> at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:90)
> at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:57)
> at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:477)
> at org.jgroups.JChannel.init(JChannel.java:854)
> at org.jgroups.JChannel.<init>(JChannel.java:159)
> at org.jgroups.JChannel.<init>(JChannel.java:129)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:404)
> ... 39 more
> Caused by: java.lang.Exception: Conversion of bind_interface in UDP with original property value eth0 failed
> at org.jgroups.conf.PropertyHelper.getConvertedValue(PropertyHelper.java:84)
> at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1147)
> ... 48 more
> Caused by: java.lang.mail(a)example.comIllegalArgumentException: network interface eth0 does not contain address fe80:0:0:0:250:56ff:feab:d612%3
> at org.jgroups.util.Util.validateBindAddressFromInterface(Util.java:3132)
> bind_interface="eth0" and bind_addr="LINK_LOCAL" config are config at the same time
> but it couldn't get the eth0 link local address but return eth1 link local address
> This code return the first address that match, it should return with eth0
> jgroups-3.6.1.Final-sources\org\jgroups\util\Util.java
> public static InetAddress getAddress(AddressScope scope) ----> scope is LINK_LOCAL
> throws SocketException
> {
> InetAddress address = null;
> Enumeration intfs = NetworkInterface.getNetworkInterfaces();
> while (intfs.hasMoreElements()) {
> NetworkInterface intf = (NetworkInterface)intfs.nextElement();
> try {
> if (intf.isUp()) {
> address = getAddress(intf, scope); -------> It will return the first LINK_LOCAL address from NICs list
> if (address != null)
> return address;
> }
> }
> catch (SocketException e) {
> }
> }
> return null;
> }
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7226) Missing realm-map attribute for mapped-regex-realm-mapper throws IllegalArgumentException to server log
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/WFLY-7226?page=com.atlassian.jira.plugin.... ]
Ilia Vassilev commented on WFLY-7226:
-------------------------------------
[~olukas] How to set "realm-map" attribute for mapped-regex-realm-mapper? Configuration [1] is valid for mapped-regex-realm-mapper. Is the exception because "realm-mapping" is not used?
[1]
{code}
<mapped-regex-realm-mapper name="MappedOne" pattern="(.?)" delegate-realm-mapper="SimpleOne">
<realm-mapping from="a" to="b" />
<realm-mapping from="c" to="d" />
</mapped-regex-realm-mapper>
{code}
> Missing realm-map attribute for mapped-regex-realm-mapper throws IllegalArgumentException to server log
> -------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7226
> URL: https://issues.jboss.org/browse/WFLY-7226
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
>
> In case when mapped-regex-realm-mapper is added through CLI and realm-map attribute is not used then IllegalArgumentException is thrown to server log instead of some CLI failure message like "realm-map may not be null".
> Expcetion in server log:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("mapped-regex-realm-mapper" => "MappedRealmMapper")
> ]): java.lang.IllegalArgumentException
> at org.jboss.dmr.ModelValue.getKeys(ModelValue.java:139)
> at org.jboss.dmr.ModelNode.keys(ModelNode.java:1378)
> at org.wildfly.extension.elytron.RealmMapperDefinitions$MappedRegexRealmMapperAddHandler.performRuntime(RealmMapperDefinitions.java:221)
> at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337)
> at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> 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}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JGRP-2102) bind_interface="eth0" and bind_addr="LINK_LOCAL" config are conflict
by 俐佳 张 (JIRA)
[ https://issues.jboss.org/browse/JGRP-2102?page=com.atlassian.jira.plugin.... ]
俐佳 张 commented on JGRP-2102:
----------------------------
Bela Ban
In fact we're using infinispan and it is bind to jgroup, we couldn't choose jgroup version free. Could you kindly let me know the earliest version which include the fix.
> bind_interface="eth0" and bind_addr="LINK_LOCAL" config are conflict
> --------------------------------------------------------------------
>
> Key: JGRP-2102
> URL: https://issues.jboss.org/browse/JGRP-2102
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.1
> Environment: [root@wtc2k01v27 ~] CLONE # ip a
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> inet6 2606:ae00:e200:3f::83/128 scope global
> valid_lft forever preferred_lft forever
> inet6 ::1/128 scope host
> valid_lft forever preferred_lft forever
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
> link/ether 00:50:56:ab:2a:ea brd ff:ff:ff:ff:ff:ff
> inet 107.250.167.28/25 brd 107.250.167.127 scope global eth0
> inet6 2606:ae00:e200:3f::28/64 scope global
> valid_lft forever preferred_lft forever
> inet6 fe80::250:56ff:feab:2aea/64 scope link
> valid_lft forever preferred_lft forever
> 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
> link/ether 00:50:56:ab:d6:12 brd ff:ff:ff:ff:ff:ff
> inet 192.168.0.59/24 brd 192.168.0.255 scope global eth1
> inet6 fe80::250:56ff:feab:d612/64 scope link
> valid_lft forever preferred_lft forever
> There're eth0 and eth1 exists in the environment
> Reporter: 俐佳 张
> Assignee: Bela Ban
> Fix For: 3.6.12
>
> Attachments: jgroups-udp.xml
>
>
> Error happens while
> Caused by: org.infinispan.commons.CacheConfigurationException: ISPN000085: Error while trying to create a channel using the specified configuration file: /opt/oss/NSN-icf_notification_dispatcher/conf/jgroups-udp.xml
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:406)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannel(JGroupsTransport.java:307)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannelAndRPCDispatcher(JGroupsTransport.java:351)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:188)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:56)
> at java.lang.reflect.Method.invoke(Method.java:620)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
> at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:226)
> ... 26 more
> Caused by: java.lang.Exception: Property assignment of bind_interface in UDP with original property value eth0 and converted to null could not be assigned
> at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1153)
> at org.jgroups.stack.Configurator.createLayer(Configurator.java:444)
> at org.jgroups.stack.Configurator.createProtocols(Configurator.java:398)
> at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:90)
> at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:57)
> at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:477)
> at org.jgroups.JChannel.init(JChannel.java:854)
> at org.jgroups.JChannel.<init>(JChannel.java:159)
> at org.jgroups.JChannel.<init>(JChannel.java:129)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:404)
> ... 39 more
> Caused by: java.lang.Exception: Conversion of bind_interface in UDP with original property value eth0 failed
> at org.jgroups.conf.PropertyHelper.getConvertedValue(PropertyHelper.java:84)
> at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1147)
> ... 48 more
> Caused by: java.lang.mail(a)example.comIllegalArgumentException: network interface eth0 does not contain address fe80:0:0:0:250:56ff:feab:d612%3
> at org.jgroups.util.Util.validateBindAddressFromInterface(Util.java:3132)
> bind_interface="eth0" and bind_addr="LINK_LOCAL" config are config at the same time
> but it couldn't get the eth0 link local address but return eth1 link local address
> This code return the first address that match, it should return with eth0
> jgroups-3.6.1.Final-sources\org\jgroups\util\Util.java
> public static InetAddress getAddress(AddressScope scope) ----> scope is LINK_LOCAL
> throws SocketException
> {
> InetAddress address = null;
> Enumeration intfs = NetworkInterface.getNetworkInterfaces();
> while (intfs.hasMoreElements()) {
> NetworkInterface intf = (NetworkInterface)intfs.nextElement();
> try {
> if (intf.isUp()) {
> address = getAddress(intf, scope); -------> It will return the first LINK_LOCAL address from NICs list
> if (address != null)
> return address;
> }
> }
> catch (SocketException e) {
> }
> }
> return null;
> }
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JGRP-2102) bind_interface="eth0" and bind_addr="LINK_LOCAL" config are conflict
by 俐佳 张 (JIRA)
[ https://issues.jboss.org/browse/JGRP-2102?page=com.atlassian.jira.plugin.... ]
俐佳 张 commented on JGRP-2102:
----------------------------
but bind_interface is http://www.jgroups.org/schema/jgroups-4.0.xsd. I checked the code 4.0 beta, there's the fix for the issue. I can see the fixed version is 3.6.12 in the ticket do you mean that issue is fixed from this version.
> bind_interface="eth0" and bind_addr="LINK_LOCAL" config are conflict
> --------------------------------------------------------------------
>
> Key: JGRP-2102
> URL: https://issues.jboss.org/browse/JGRP-2102
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.1
> Environment: [root@wtc2k01v27 ~] CLONE # ip a
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> inet6 2606:ae00:e200:3f::83/128 scope global
> valid_lft forever preferred_lft forever
> inet6 ::1/128 scope host
> valid_lft forever preferred_lft forever
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
> link/ether 00:50:56:ab:2a:ea brd ff:ff:ff:ff:ff:ff
> inet 107.250.167.28/25 brd 107.250.167.127 scope global eth0
> inet6 2606:ae00:e200:3f::28/64 scope global
> valid_lft forever preferred_lft forever
> inet6 fe80::250:56ff:feab:2aea/64 scope link
> valid_lft forever preferred_lft forever
> 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
> link/ether 00:50:56:ab:d6:12 brd ff:ff:ff:ff:ff:ff
> inet 192.168.0.59/24 brd 192.168.0.255 scope global eth1
> inet6 fe80::250:56ff:feab:d612/64 scope link
> valid_lft forever preferred_lft forever
> There're eth0 and eth1 exists in the environment
> Reporter: 俐佳 张
> Assignee: Bela Ban
> Fix For: 3.6.12
>
> Attachments: jgroups-udp.xml
>
>
> Error happens while
> Caused by: org.infinispan.commons.CacheConfigurationException: ISPN000085: Error while trying to create a channel using the specified configuration file: /opt/oss/NSN-icf_notification_dispatcher/conf/jgroups-udp.xml
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:406)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannel(JGroupsTransport.java:307)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannelAndRPCDispatcher(JGroupsTransport.java:351)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:188)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:56)
> at java.lang.reflect.Method.invoke(Method.java:620)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
> at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:226)
> ... 26 more
> Caused by: java.lang.Exception: Property assignment of bind_interface in UDP with original property value eth0 and converted to null could not be assigned
> at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1153)
> at org.jgroups.stack.Configurator.createLayer(Configurator.java:444)
> at org.jgroups.stack.Configurator.createProtocols(Configurator.java:398)
> at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:90)
> at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:57)
> at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:477)
> at org.jgroups.JChannel.init(JChannel.java:854)
> at org.jgroups.JChannel.<init>(JChannel.java:159)
> at org.jgroups.JChannel.<init>(JChannel.java:129)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:404)
> ... 39 more
> Caused by: java.lang.Exception: Conversion of bind_interface in UDP with original property value eth0 failed
> at org.jgroups.conf.PropertyHelper.getConvertedValue(PropertyHelper.java:84)
> at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1147)
> ... 48 more
> Caused by: java.lang.mail(a)example.comIllegalArgumentException: network interface eth0 does not contain address fe80:0:0:0:250:56ff:feab:d612%3
> at org.jgroups.util.Util.validateBindAddressFromInterface(Util.java:3132)
> bind_interface="eth0" and bind_addr="LINK_LOCAL" config are config at the same time
> but it couldn't get the eth0 link local address but return eth1 link local address
> This code return the first address that match, it should return with eth0
> jgroups-3.6.1.Final-sources\org\jgroups\util\Util.java
> public static InetAddress getAddress(AddressScope scope) ----> scope is LINK_LOCAL
> throws SocketException
> {
> InetAddress address = null;
> Enumeration intfs = NetworkInterface.getNetworkInterfaces();
> while (intfs.hasMoreElements()) {
> NetworkInterface intf = (NetworkInterface)intfs.nextElement();
> try {
> if (intf.isUp()) {
> address = getAddress(intf, scope); -------> It will return the first LINK_LOCAL address from NICs list
> if (address != null)
> return address;
> }
> }
> catch (SocketException e) {
> }
> }
> return null;
> }
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (DROOLS-1279) [GSS] compilation of spreadsheet fails with specific condition
by Hiroko Miura (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1279?page=com.atlassian.jira.plugi... ]
Hiroko Miura edited comment on DROOLS-1279 at 9/28/16 8:32 PM:
---------------------------------------------------------------
This issue happens as double quotation is removed from contents ("AAA") in C11 by LhsBuilder.fixValue(). Because FieldType.SINGLE_FIELD was set to LhsBuilder.fieldType while handling cell D9 ( "status" ). If column D is removed, FieldType.NORMAL_FIELD is set to LhsBuilder.fieldType while handling cell C8 ( "checktest in($param)" ) and issue does not happen.
Or in cell D9 "status" is modified like "status == $param" (i.e. using placeholder ), FieldType.NORMAL_FIELD is kept in LhsBuilder.fieldType and issue does not happen.
> [GSS] compilation of spreadsheet fails with specific condition
> --------------------------------------------------------------
>
> Key: DROOLS-1279
> URL: https://issues.jboss.org/browse/DROOLS-1279
> Project: Drools
> Issue Type: Bug
> Components: build, decision tables
> Affects Versions: 6.4.0.Final
> Reporter: Hiroko Miura
> Assignee: Michael Anstis
> Priority: Critical
> Labels: support
> Fix For: 6.5.0.Final
>
> Attachments: reproducer.zip
>
>
> Reproducer is attached.with problematic spredsheet named SampleNG.xml.
> Compilation of this fails with the following error.
> java.lang.RuntimeException: Error while creating KieBase[Message [id=1, level=ERROR, path=dtables/SampleNG.xls, line=8, column=0
> text=Unable to Analyse Expression checktest == AAA:
> [Error: unable to resolve method using strict-mode: com.sample.DecisionTableTest$Message.AAA()]
> [Near : {... checktest == AAA ....}]
> because the following DRL is generated.
> rule "HelloWorld_12"
> when
> m:Message(checktest in (AAA), status == "Message.HELLO")
> ...
> i.e. double quotation of value ("AAA") specified in the cell is removed.
>
> If D column does not exist like Sample.xml(also included in reproducer) or rule template of D column is modified like "status == $param " (see SampleOK.xml), this does not happen.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7229) WFLYCLWEBUT0001 for server-side invalidated sessions
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7229?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-7229:
--------------------------------------
This looks more like a clustering issue than an undertow one. Note that with this setup there is always the possibility of a race condition if the invalidation happens in one thread while another thread is also using the session.
> WFLYCLWEBUT0001 for server-side invalidated sessions
> ----------------------------------------------------
>
> Key: WFLY-7229
> URL: https://issues.jboss.org/browse/WFLY-7229
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Affects Versions: 10.1.0.Final
> Environment: Happens whenever <distributable/> is used in web.xml, both in standalone and domain modes.
> Reporter: Michał Nowakowski
> Assignee: Paul Ferraro
> Attachments: stacktrace_01.txt, stacktrace_02.txt, stacktrace_03.txt, testPortlet.tar.gz
>
>
> Attached is a simple webapp (pardon the name) with a single servlet "/main", that does the following:
> - a session is assigned (or created, if none existed before)
> - its details are printed and the browser is told to refresh after 20 seconds
> - before the browser refreshes, the session is invalidated server-side by separate thread.
> Expected behaviour is, that WF should give the user a new session. That's indeed how it works in standalone mode and without <distributable/> in web.xml. But in domain mode, OR with <distributable/> added (and, possibly, full-ha profile chosen), I get errors:
> - The first stacktrace happens when the thread invalidates the session.
> - The second stacktrace happens, when the browser refreshes. The user sees "Error 500".
> - Then, after a minute or so, I get the last one. It then repeats periodically.
> We can't upgrade from 10.0 because of this - and we know we need an upgrade because of fixes in Infinispan.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7229) WFLYCLWEBUT0001 for server-side invalidated sessions
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7229?page=com.atlassian.jira.plugin.... ]
Stuart Douglas updated WFLY-7229:
---------------------------------
Component/s: Clustering
> WFLYCLWEBUT0001 for server-side invalidated sessions
> ----------------------------------------------------
>
> Key: WFLY-7229
> URL: https://issues.jboss.org/browse/WFLY-7229
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Affects Versions: 10.1.0.Final
> Environment: Happens whenever <distributable/> is used in web.xml, both in standalone and domain modes.
> Reporter: Michał Nowakowski
> Assignee: Stuart Douglas
> Attachments: stacktrace_01.txt, stacktrace_02.txt, stacktrace_03.txt, testPortlet.tar.gz
>
>
> Attached is a simple webapp (pardon the name) with a single servlet "/main", that does the following:
> - a session is assigned (or created, if none existed before)
> - its details are printed and the browser is told to refresh after 20 seconds
> - before the browser refreshes, the session is invalidated server-side by separate thread.
> Expected behaviour is, that WF should give the user a new session. That's indeed how it works in standalone mode and without <distributable/> in web.xml. But in domain mode, OR with <distributable/> added (and, possibly, full-ha profile chosen), I get errors:
> - The first stacktrace happens when the thread invalidates the session.
> - The second stacktrace happens, when the browser refreshes. The user sees "Error 500".
> - Then, after a minute or so, I get the last one. It then repeats periodically.
> We can't upgrade from 10.0 because of this - and we know we need an upgrade because of fixes in Infinispan.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7229) WFLYCLWEBUT0001 for server-side invalidated sessions
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7229?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-7229:
------------------------------------
Assignee: Paul Ferraro (was: Stuart Douglas)
> WFLYCLWEBUT0001 for server-side invalidated sessions
> ----------------------------------------------------
>
> Key: WFLY-7229
> URL: https://issues.jboss.org/browse/WFLY-7229
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Affects Versions: 10.1.0.Final
> Environment: Happens whenever <distributable/> is used in web.xml, both in standalone and domain modes.
> Reporter: Michał Nowakowski
> Assignee: Paul Ferraro
> Attachments: stacktrace_01.txt, stacktrace_02.txt, stacktrace_03.txt, testPortlet.tar.gz
>
>
> Attached is a simple webapp (pardon the name) with a single servlet "/main", that does the following:
> - a session is assigned (or created, if none existed before)
> - its details are printed and the browser is told to refresh after 20 seconds
> - before the browser refreshes, the session is invalidated server-side by separate thread.
> Expected behaviour is, that WF should give the user a new session. That's indeed how it works in standalone mode and without <distributable/> in web.xml. But in domain mode, OR with <distributable/> added (and, possibly, full-ha profile chosen), I get errors:
> - The first stacktrace happens when the thread invalidates the session.
> - The second stacktrace happens, when the browser refreshes. The user sees "Error 500".
> - Then, after a minute or so, I get the last one. It then repeats periodically.
> We can't upgrade from 10.0 because of this - and we know we need an upgrade because of fixes in Infinispan.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7224) Missing validation check for simple-regex-realm-mapper and mapped-regex-realm-mapper in Elytron subsystem
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/WFLY-7224?page=com.atlassian.jira.plugin.... ]
Ilia Vassilev commented on WFLY-7224:
-------------------------------------
[~honza889] Sent PR [1] which is easier to review.
[1] https://github.com/wildfly-security/elytron-subsystem/pull/243
> Missing validation check for simple-regex-realm-mapper and mapped-regex-realm-mapper in Elytron subsystem
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7224
> URL: https://issues.jboss.org/browse/WFLY-7224
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
>
> Elytron subsystem allows to add realm mapper (e.g. simple-regex-realm-mapper) with pattern which does not include a capture group. In case when this realm mapper is used in add operation for security domain through CLI then operation fails with incomprehensible log:
> {code}
> {
> "outcome" => "failed",
> "failure-description" => {"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined},
> "rolled-back" => true
> }
> {code}
> Exception in server log:
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.security.realm-mapper.SomeRealmMapper: org.jboss.msc.service.StartException in service org.wildfly.security.realm-mapper.SomeRealmMapper: 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.IllegalArgumentException: ELY01065: Pattern requires a capture group
> at org.wildfly.security.auth.util.SimpleRegexRealmMapper.<init>(SimpleRegexRealmMapper.java:64)
> at org.wildfly.security.auth.util.SimpleRegexRealmMapper.<init>(SimpleRegexRealmMapper.java:49)
> at org.wildfly.extension.elytron.RealmMapperDefinitions$SimpleRegexRealmMapperAddHandler.lambda$performRuntime$0(RealmMapperDefinitions.java:157)
> 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}
> The same happens for mapped-regex-realm-mapper.
> Point here is that we allow to successfully add wrong realm mapper (without capture group) but we check whether it is wrong later in security domain. This check should be done during adding wrong realm mapper to avoid following incomprehensible CLI log and exception in server log.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7212) Cannot use BMT in @Schedule service
by Karl Nicholas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7212?page=com.atlassian.jira.plugin.... ]
Karl Nicholas edited comment on WFLY-7212 at 9/28/16 5:22 PM:
--------------------------------------------------------------
Okay, that seems to have been the problem. I didn't think through the fact that I was also starting up a CMT, though in hindsight it should have been obvious, especially since I didn't make the first bean a BMT because of other @scheduled events that I wanted to be CMT. Now I can choose which way I want it to be and even use pure Java EE if that's important. Thanks once again.
was (Author: karlnicholas):
Okay, that seems to have been the problem. I didn't think through the fact that I was also starting up a CMT, though in hindsight it should have been obvious, especially since I didn't make the first bean a BMT because of other @scheduled events that I wanted to be CMT. Thanks once again.
> Cannot use BMT in @Schedule service
> -----------------------------------
>
> Key: WFLY-7212
> URL: https://issues.jboss.org/browse/WFLY-7212
> Project: WildFly
> Issue Type: Feature Request
> Components: EE, EJB, Transactions
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Environment: Wildfly 10.1.0-Final. Windows 10. MySql 5.5.
> Reporter: Karl Nicholas
> Labels: arjuna, ejb, scheduled, scheduled_tasks, transaction
>
> When injecting a `@Resource private UserTransaction tx;`, a `TransactionReaper` terminates kills my `UserTransaction` after 5 minutes no matter what. Since it's a batch update, I need more than 5 minutes.
> Here is a simple piece of code that doesn't work:
> {code:java}
> @EJB private TestFiveMinuteBatch testFiveMinuteBatch;
> @Schedule(second="0", minute="8", hour="10", persistent=false) // 03:30 am (12:30 am CA ) every day
> public void updateTest() {
> testFiveMinuteBatch.test();
> }
> @Stateless
> @TransactionManagement(TransactionManagementType.BEAN)
> public class TestFiveMinuteBatch {
> @Resource private UserTransaction tx;
> public void test() {
> for ( int i=0; i < 6; ++i ) {
> System.out.println("Minute: " + i);
> try {
> Thread.sleep(60000);
> } catch (InterruptedException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
> }
> }
> }
> {code}
> After 5 minutes I get this warning:
> {noformat}
> 10:13:00,034 WARN [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffffac1f6209:-595568e4:57e80419:e in state RUN
> 10:13:00,039 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012121: TransactionReaper::doCancellations worker Thread[Transaction Reaper Worker 0,5,main] successfully canceled TX 0:ffffac1f6209:-595568e4:57e80419:e
> 10:13:00,130 INFO [stdout] (EJB default - 1) Minute: 5
> {noformat}
> After service terminates I get this error:
> {noformat}
> 10:14:00,131 WARN [com.arjuna.ats.arjuna] (EJB default - 1) ARJUNA012077: Abort called on already aborted atomic action 0:ffffac1f6209:-595568e4:57e80419:e
> 10:14:00,163 ERROR [org.jboss.as.ejb3.timer] (EJB default - 1) WFLYEJB0020: Error invoking timeout for timer: [id=8a8f4546-28d0-491e-85a6-f668f58ab5dc timedObjectId=opca-ear.opca-ejb.ScheduledService auto-timer?:true persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@31fe8c3e initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Mon Sep 26 10:08:00 PDT 2016 timerState=IN_TIMEOUT info=null]: javax.ejb.EJBTransactionRolledbackException: Transaction rolled back
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleEndTransactionException(CMTTxInterceptor.java:137)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:117)
> at org.jboss.as.ejb3.tx.TimerCMTTxInterceptor.endTransaction(TimerCMTTxInterceptor.java:67)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:279)
> 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.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:110)
> 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.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.ejb3.timerservice.TimedObjectInvokerImpl.callTimeout(TimedObjectInvokerImpl.java:99)
> at org.jboss.as.ejb3.timerservice.CalendarTimerTask.invokeBeanMethod(CalendarTimerTask.java:64)
> at org.jboss.as.ejb3.timerservice.CalendarTimerTask.callTimeout(CalendarTimerTask.java:53)
> at org.jboss.as.ejb3.timerservice.TimerTask.run(TimerTask.java:157)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl$Task$1.run(TimerServiceImpl.java:1215)
> at org.wildfly.extension.requestcontroller.RequestController$QueuedTask$1.run(RequestController.java:497)
> 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)
> Caused by: javax.transaction.RollbackException: WFLYEJB0447: Transaction 'TransactionImple < ac, BasicAction: 0:ffffac1f6209:-595568e4:57e80419:e status: ActionStatus.ABORTED >' was already rolled back
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:98)
> ... 38 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7212) Cannot use BMT in @Schedule service
by Karl Nicholas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7212?page=com.atlassian.jira.plugin.... ]
Karl Nicholas commented on WFLY-7212:
-------------------------------------
Okay, that seems to have been the problem. I didn't think through the fact that I was also starting up a CMT, though in hindsight it should have been obvious, especially since I didn't make the first bean a BMT because of other @scheduled events that I wanted to be CMT. Thanks once again.
> Cannot use BMT in @Schedule service
> -----------------------------------
>
> Key: WFLY-7212
> URL: https://issues.jboss.org/browse/WFLY-7212
> Project: WildFly
> Issue Type: Feature Request
> Components: EE, EJB, Transactions
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Environment: Wildfly 10.1.0-Final. Windows 10. MySql 5.5.
> Reporter: Karl Nicholas
> Labels: arjuna, ejb, scheduled, scheduled_tasks, transaction
>
> When injecting a `@Resource private UserTransaction tx;`, a `TransactionReaper` terminates kills my `UserTransaction` after 5 minutes no matter what. Since it's a batch update, I need more than 5 minutes.
> Here is a simple piece of code that doesn't work:
> {code:java}
> @EJB private TestFiveMinuteBatch testFiveMinuteBatch;
> @Schedule(second="0", minute="8", hour="10", persistent=false) // 03:30 am (12:30 am CA ) every day
> public void updateTest() {
> testFiveMinuteBatch.test();
> }
> @Stateless
> @TransactionManagement(TransactionManagementType.BEAN)
> public class TestFiveMinuteBatch {
> @Resource private UserTransaction tx;
> public void test() {
> for ( int i=0; i < 6; ++i ) {
> System.out.println("Minute: " + i);
> try {
> Thread.sleep(60000);
> } catch (InterruptedException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
> }
> }
> }
> {code}
> After 5 minutes I get this warning:
> {noformat}
> 10:13:00,034 WARN [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffffac1f6209:-595568e4:57e80419:e in state RUN
> 10:13:00,039 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012121: TransactionReaper::doCancellations worker Thread[Transaction Reaper Worker 0,5,main] successfully canceled TX 0:ffffac1f6209:-595568e4:57e80419:e
> 10:13:00,130 INFO [stdout] (EJB default - 1) Minute: 5
> {noformat}
> After service terminates I get this error:
> {noformat}
> 10:14:00,131 WARN [com.arjuna.ats.arjuna] (EJB default - 1) ARJUNA012077: Abort called on already aborted atomic action 0:ffffac1f6209:-595568e4:57e80419:e
> 10:14:00,163 ERROR [org.jboss.as.ejb3.timer] (EJB default - 1) WFLYEJB0020: Error invoking timeout for timer: [id=8a8f4546-28d0-491e-85a6-f668f58ab5dc timedObjectId=opca-ear.opca-ejb.ScheduledService auto-timer?:true persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@31fe8c3e initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Mon Sep 26 10:08:00 PDT 2016 timerState=IN_TIMEOUT info=null]: javax.ejb.EJBTransactionRolledbackException: Transaction rolled back
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleEndTransactionException(CMTTxInterceptor.java:137)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:117)
> at org.jboss.as.ejb3.tx.TimerCMTTxInterceptor.endTransaction(TimerCMTTxInterceptor.java:67)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:279)
> 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.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:110)
> 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.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.ejb3.timerservice.TimedObjectInvokerImpl.callTimeout(TimedObjectInvokerImpl.java:99)
> at org.jboss.as.ejb3.timerservice.CalendarTimerTask.invokeBeanMethod(CalendarTimerTask.java:64)
> at org.jboss.as.ejb3.timerservice.CalendarTimerTask.callTimeout(CalendarTimerTask.java:53)
> at org.jboss.as.ejb3.timerservice.TimerTask.run(TimerTask.java:157)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl$Task$1.run(TimerServiceImpl.java:1215)
> at org.wildfly.extension.requestcontroller.RequestController$QueuedTask$1.run(RequestController.java:497)
> 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)
> Caused by: javax.transaction.RollbackException: WFLYEJB0447: Transaction 'TransactionImple < ac, BasicAction: 0:ffffac1f6209:-595568e4:57e80419:e status: ActionStatus.ABORTED >' was already rolled back
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:98)
> ... 38 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (ELY-647) MechanismDatabase create SSL_ aliases incompletely
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-647?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina updated ELY-647:
---------------------------
Steps to Reproduce: {code:java}CipherSuiteSelector.fromString("SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA");{code} (was: # Use standalone.xml from attachment
# update path to keystore (server-cert-key-rsa.jks)
# update path to trust store (ca-cert.jks)
)
> MechanismDatabase create SSL_ aliases incompletely
> --------------------------------------------------
>
> Key: ELY-647
> URL: https://issues.jboss.org/browse/ELY-647
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
>
> SSL MechanismDatabase should create alias for every TLS_* from SSL_*. It create them only for direct entries, not for other aliases.
> MechanismDatabase.properties contains for example:
> {code:java}
> TLS_RSA_FIPS_WITH_3DES_EDE_CBC_SHA = alias:TLS_RSA_WITH_3DES_EDE_CBC_SHA
> {code}
> The *TLS_RSA_FIPS_WITH_3DES_EDE_CBC_SHA* works ok, but *SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA* doesnt exist.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (ELY-647) MechanismDatabase create SSL_ aliases incompletely
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-647?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina updated ELY-647:
---------------------------
Description:
SSL MechanismDatabase should create alias for every TLS_* from SSL_*. It create them only for direct entries, not for other aliases.
MechanismDatabase.properties contains for example:
{code:java}
TLS_RSA_FIPS_WITH_3DES_EDE_CBC_SHA = alias:TLS_RSA_WITH_3DES_EDE_CBC_SHA
{code}
The *TLS_RSA_FIPS_WITH_3DES_EDE_CBC_SHA* works ok, but *SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA* doesnt exist.
was:
SSL MechanismDatabase should create alias for every TLS_* from SSL_*. It create them only for direct entries, not for other aliases.
MechanismDatabase.properties contains for example:
{code:java}
TLS_RSA_FIPS_WITH_3DES_EDE_CBC_SHA = alias:TLS_RSA_WITH_3DES_EDE_CBC_SHA
{code}
The *TLS_RSA_FIPS_WITH_3DES_EDE_CBC_SHA* works ok, but *SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA* doesnt.
> MechanismDatabase create SSL_ aliases incompletely
> --------------------------------------------------
>
> Key: ELY-647
> URL: https://issues.jboss.org/browse/ELY-647
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
>
> SSL MechanismDatabase should create alias for every TLS_* from SSL_*. It create them only for direct entries, not for other aliases.
> MechanismDatabase.properties contains for example:
> {code:java}
> TLS_RSA_FIPS_WITH_3DES_EDE_CBC_SHA = alias:TLS_RSA_WITH_3DES_EDE_CBC_SHA
> {code}
> The *TLS_RSA_FIPS_WITH_3DES_EDE_CBC_SHA* works ok, but *SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA* doesnt exist.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (ELY-647) MechanismDatabase create SSL_ aliases incompletely
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-647?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina updated ELY-647:
---------------------------
Description:
SSL MechanismDatabase should create alias for every TLS_* from SSL_*. It create them only for direct entries, not for other aliases.
MechanismDatabase.properties contains for example:
{code:java}
TLS_RSA_FIPS_WITH_3DES_EDE_CBC_SHA = alias:TLS_RSA_WITH_3DES_EDE_CBC_SHA
{code}
The *TLS_RSA_FIPS_WITH_3DES_EDE_CBC_SHA* works ok, but *SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA* doesnt.
was:
SSL MechanismDatabase should create alias for every TLS_* from SSL_*. It create them only for direct entries, not for other aliases.
MechanismDatabase.properties contains for example:
{code:java}
TLS_RSA_FIPS_WITH_3DES_EDE_CBC_SHA = alias:TLS_RSA_WITH_3DES_EDE_CBC_SHA
{code}
The TLS_RSA_FIPS_WITH_3DES_EDE_CBC_SHA works ok, but SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA doesnt.
> MechanismDatabase create SSL_ aliases incompletely
> --------------------------------------------------
>
> Key: ELY-647
> URL: https://issues.jboss.org/browse/ELY-647
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
>
> SSL MechanismDatabase should create alias for every TLS_* from SSL_*. It create them only for direct entries, not for other aliases.
> MechanismDatabase.properties contains for example:
> {code:java}
> TLS_RSA_FIPS_WITH_3DES_EDE_CBC_SHA = alias:TLS_RSA_WITH_3DES_EDE_CBC_SHA
> {code}
> The *TLS_RSA_FIPS_WITH_3DES_EDE_CBC_SHA* works ok, but *SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA* doesnt.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (ELY-647) MechanismDatabase create SSL_ aliases incompletely
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-647?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina updated ELY-647:
---------------------------
Description:
SSL MechanismDatabase should create alias for every TLS_* from SSL_*. It create them only for direct entries, not for other aliases.
MechanismDatabase.properties contains for example:
{code:java}
TLS_RSA_FIPS_WITH_3DES_EDE_CBC_SHA = alias:TLS_RSA_WITH_3DES_EDE_CBC_SHA
{code}
The TLS_RSA_FIPS_WITH_3DES_EDE_CBC_SHA works ok, but SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA doesnt.
was:
There is not possibility to use alternative JSSE Cipher Suite Names for IBM JDK8
Interchange TLS prefix to SSL and vice versa is not supported.
Here is list of standard JSSE Cipher Suite Names
http://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNa...
In my opinion this file is mapping file for our purpose. It is?
https://github.com/wildfly-security/wildfly-elytron/blob/master/src/main/...
For IBM JDK are different JSSE Cipher Suite Names (different prefix).
Most items from this list are missing in MechanismDatabase.properties mentioned above.
http://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.secu...
For example:
JSSE Cipher Suite Name *SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA* is only defined for IBM JDK.
It is *TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA* for Oracle JDK.
If I try start server with JSSE Cipher Suite Name *SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA* I will get this error:
{code}
16:55:25,594 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.undertow.listener.https: org.jboss.msc.service.StartException in service jboss.undertow.listener.https: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.lang.Thread.run(Thread.java:785)
Caused by: java.lang.IllegalArgumentException: ELY05017: Token "SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA" not allowed at offset 33 of mechanism selection string "SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA"
at org.wildfly.security.ssl.CipherSuiteSelector.fromString(CipherSuiteSelector.java:399)
at org.wildfly.extension.undertow.HttpsListenerService.startListening(HttpsListenerService.java:125)
at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:138)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
... 3 more
16:55:25,598 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "undertow"),
("server" => "default-server"),
("https-listener" => "https")
]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.undertow.listener.https" => "org.jboss.msc.service.StartException in service jboss.undertow.listener.https: Failed to start service
Caused by: java.lang.IllegalArgumentException: ELY05017: Token \"SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA\" not allowed at offset 33 of mechanism selection string \"SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA\""}}
{code}
> MechanismDatabase create SSL_ aliases incompletely
> --------------------------------------------------
>
> Key: ELY-647
> URL: https://issues.jboss.org/browse/ELY-647
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
>
> SSL MechanismDatabase should create alias for every TLS_* from SSL_*. It create them only for direct entries, not for other aliases.
> MechanismDatabase.properties contains for example:
> {code:java}
> TLS_RSA_FIPS_WITH_3DES_EDE_CBC_SHA = alias:TLS_RSA_WITH_3DES_EDE_CBC_SHA
> {code}
> The TLS_RSA_FIPS_WITH_3DES_EDE_CBC_SHA works ok, but SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA doesnt.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (ELY-647) MechanismDatabase create SSL_ aliases incompletely
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-647?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina moved JBEAP-6237 to ELY-647:
---------------------------------------
Project: WildFly Elytron (was: JBoss Enterprise Application Platform)
Key: ELY-647 (was: JBEAP-6237)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: SSL
(was: Security)
Affects Version/s: (was: 7.0.0.ER6)
Affects Testing: (was: Regression)
> MechanismDatabase create SSL_ aliases incompletely
> --------------------------------------------------
>
> Key: ELY-647
> URL: https://issues.jboss.org/browse/ELY-647
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
>
> There is not possibility to use alternative JSSE Cipher Suite Names for IBM JDK8
> Interchange TLS prefix to SSL and vice versa is not supported.
> Here is list of standard JSSE Cipher Suite Names
> http://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNa...
> In my opinion this file is mapping file for our purpose. It is?
> https://github.com/wildfly-security/wildfly-elytron/blob/master/src/main/...
> For IBM JDK are different JSSE Cipher Suite Names (different prefix).
> Most items from this list are missing in MechanismDatabase.properties mentioned above.
> http://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.secu...
> For example:
> JSSE Cipher Suite Name *SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA* is only defined for IBM JDK.
> It is *TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA* for Oracle JDK.
> If I try start server with JSSE Cipher Suite Name *SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA* I will get this error:
> {code}
> 16:55:25,594 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.undertow.listener.https: org.jboss.msc.service.StartException in service jboss.undertow.listener.https: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(Thread.java:785)
> Caused by: java.lang.IllegalArgumentException: ELY05017: Token "SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA" not allowed at offset 33 of mechanism selection string "SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA"
> at org.wildfly.security.ssl.CipherSuiteSelector.fromString(CipherSuiteSelector.java:399)
> at org.wildfly.extension.undertow.HttpsListenerService.startListening(HttpsListenerService.java:125)
> at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:138)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> ... 3 more
> 16:55:25,598 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "undertow"),
> ("server" => "default-server"),
> ("https-listener" => "https")
> ]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.undertow.listener.https" => "org.jboss.msc.service.StartException in service jboss.undertow.listener.https: Failed to start service
> Caused by: java.lang.IllegalArgumentException: ELY05017: Token \"SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA\" not allowed at offset 33 of mechanism selection string \"SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA\""}}
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6700) MBeanServer.isRegistered() fails when the security manager is enabled
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-6700?page=com.atlassian.jira.plugin.... ]
Brian Stansberry resolved WFLY-6700.
------------------------------------
Resolution: Rejected
RunAsRolePermission does not use *.
If this does not work, please re-open.
{code}
<permission>
<class-name>org.jboss.as.controller.access.rbac.RunAsRolePermission</class-name>
<name>SUPERUSER</name>
</permission>
{code}
> MBeanServer.isRegistered() fails when the security manager is enabled
> ---------------------------------------------------------------------
>
> Key: WFLY-6700
> URL: https://issues.jboss.org/browse/WFLY-6700
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Final
> Reporter: Derek Horton
> Assignee: Brian Stansberry
>
> Calling MBeanServer.isRegistered() in a servlet fails with the following error when the security manager is enabled:
> :WFSM000001: Permission check failed (permission "("org.jboss.as.controller.access.rbac.RunAsRolePermission" "org.jboss.as.controller.access.rbac.RunAsRolePermission.SUPERUSER")" in code source "(vfs:/content/SimpleWar.war/WEB-INF/classes <no signer certificates>)" of "null")
> The code looks like the following:
> final MBeanServer server = ManagementFactory.getPlatformMBeanServer();
> final ObjectName mbeanName = new ObjectName("ima.test:type=imaTest");
> System.out.println("*** calling MBeanServer.isRegistered() - "+server.isRegistered(mbeanName));
> The META-INF/jboss-permissions.xml looks like the following:
> <?xml version="1.0" encoding="UTF-8"?>
> <permissions xmlns="http://xmlns.jcp.org/xml/ns/javaee" version="7">
> <permission>
> <class-name>javax.management.MBeanServerPermission</class-name>
> <name>createMBeanServer</name>
> </permission>
> <permission>
> <class-name>org.jboss.as.controller.access.rbac.RunAsRolePermission</class-name>
> <name>*</name>
> </permission>
> </permissions>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1836) Rejection-style transformer tests assume each operation generated by parser has distinct PathAddress
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1836?page=com.atlassian.jira.plugi... ]
Kabir Khan commented on WFCORE-1836:
------------------------------------
[~pferraro] Does FailedOperationTransformationConfig.ChainedConfig help at all? There should be a few usages of that scattered around the subsystem tests. I'm afraid I don't remember off the top of my head if it will work for exactly this situation since it has been a while, but it was done to work around situations like this (at least vaguely similar situations!).
> Rejection-style transformer tests assume each operation generated by parser has distinct PathAddress
> ----------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1836
> URL: https://issues.jboss.org/browse/WFCORE-1836
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Reporter: Paul Ferraro
> Assignee: Brian Stansberry
>
> For rejection-style transformer tests, the subsystem test framework stores expected rejected operations in a map keyed by PathAddress. This is fine when the subsystem's parser only generates add operations. However, if the parser generates an add operation as well as a a write-attribute operation, these 2 operations will have the same path address. If we expect one of these operations to be rejected, but not the other, we end up with an unexpected rejection - and the test fails.
> This is a little hard to explain in the abstract, so let me know if any of the above doesn't make sense.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1836) Rejection-style transformer tests assume each operation generated by parser has distinct PathAddress
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1836?page=com.atlassian.jira.plugi... ]
Paul Ferraro commented on WFCORE-1836:
--------------------------------------
[~kabirkhan] I'm talking about the FailedOperationTransformationConfig.PathAddressRegistryConfig.
> Rejection-style transformer tests assume each operation generated by parser has distinct PathAddress
> ----------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1836
> URL: https://issues.jboss.org/browse/WFCORE-1836
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Reporter: Paul Ferraro
> Assignee: Brian Stansberry
>
> For rejection-style transformer tests, the subsystem test framework stores expected rejected operations in a map keyed by PathAddress. This is fine when the subsystem's parser only generates add operations. However, if the parser generates an add operation as well as a a write-attribute operation, these 2 operations will have the same path address. If we expect one of these operations to be rejected, but not the other, we end up with an unexpected rejection - and the test fails.
> This is a little hard to explain in the abstract, so let me know if any of the above doesn't make sense.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1836) Rejection-style transformer tests assume each operation generated by parser has distinct PathAddress
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1836?page=com.atlassian.jira.plugi... ]
Paul Ferraro edited comment on WFCORE-1836 at 9/28/16 12:25 PM:
----------------------------------------------------------------
[~kabirkhan] I'm talking about the FailedOperationTransformationConfig.PathAddressConfigRegistry.
was (Author: pferraro):
[~kabirkhan] I'm talking about the FailedOperationTransformationConfig.PathAddressRegistryConfig.
> Rejection-style transformer tests assume each operation generated by parser has distinct PathAddress
> ----------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1836
> URL: https://issues.jboss.org/browse/WFCORE-1836
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Reporter: Paul Ferraro
> Assignee: Brian Stansberry
>
> For rejection-style transformer tests, the subsystem test framework stores expected rejected operations in a map keyed by PathAddress. This is fine when the subsystem's parser only generates add operations. However, if the parser generates an add operation as well as a a write-attribute operation, these 2 operations will have the same path address. If we expect one of these operations to be rejected, but not the other, we end up with an unexpected rejection - and the test fails.
> This is a little hard to explain in the abstract, so let me know if any of the above doesn't make sense.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (ELY-646) Unable to setup CLIENT_CERT authentication with elytron.
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-646?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina edited comment on ELY-646 at 9/28/16 12:07 PM:
----------------------------------------------------------
The certificate is not required, because setWantClientAuth(true) call resets needClientAuth to false. Needs be fixed in wildfly-elytron.
was (Author: honza889):
The certificate is not required, because setting setWantClientAuth(true) resets needClientAuth to false.
> Unable to setup CLIENT_CERT authentication with elytron.
> --------------------------------------------------------
>
> Key: ELY-646
> URL: https://issues.jboss.org/browse/ELY-646
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Blocker
>
> Following Zach's notes on [How to setup 2 way TLS|https://gitlab.cee.redhat.com/zrhoads/kbase/blob/master/eap71.elytron...] I am unable to setup it properly. User is not requested by browser for specifying client certificate and get access to application without certificate.
> In log you there is:
> 1. Server send request for certificate
> {code}
> ^[[0m^[[0m13:55:33,309 INFO [stdout] (default task-1) *** CertificateRequest
> ^[[0m^[[0m13:55:33,309 INFO [stdout] (default task-1) Cert Types: RSA, DSS, ECDSA
> ^[[0m^[[0m13:55:33,309 INFO [stdout] (default task-1) Cert Authorities:
> ^[[0m^[[0m13:55:33,310 INFO [stdout] (default task-1) <CN=client>
> {code}
> 2. And client responds with empty certificate chain. Without asking for certificate
> {code}
> ^[[0m^[[0m13:55:33,432 INFO [stdout] (default task-2) *** Certificate chain
> ^[[0m^[[0m13:55:33,432 INFO [stdout] (default task-2) <Empty>
> ^[[0m^[[0m13:55:33,432 INFO [stdout] (default task-2) ***
> {code}
> I am attaching:
> * server.log - server log with -Djavax.net.debug=all turn on.
> * 2wayTLS.pcap - wireshark recording of port 8443
> * secured-app - tested application
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (ELY-646) Unable to setup CLIENT_CERT authentication with elytron.
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-646?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina moved WFLY-7218 to ELY-646:
--------------------------------------
Project: WildFly Elytron (was: WildFly)
Key: ELY-646 (was: WFLY-7218)
Component/s: SSL
(was: Security)
Affects Version/s: (was: 11.0.0.Alpha1)
> Unable to setup CLIENT_CERT authentication with elytron.
> --------------------------------------------------------
>
> Key: ELY-646
> URL: https://issues.jboss.org/browse/ELY-646
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Blocker
>
> Following Zach's notes on [How to setup 2 way TLS|https://gitlab.cee.redhat.com/zrhoads/kbase/blob/master/eap71.elytron...] I am unable to setup it properly. User is not requested by browser for specifying client certificate and get access to application without certificate.
> In log you there is:
> 1. Server send request for certificate
> {code}
> ^[[0m^[[0m13:55:33,309 INFO [stdout] (default task-1) *** CertificateRequest
> ^[[0m^[[0m13:55:33,309 INFO [stdout] (default task-1) Cert Types: RSA, DSS, ECDSA
> ^[[0m^[[0m13:55:33,309 INFO [stdout] (default task-1) Cert Authorities:
> ^[[0m^[[0m13:55:33,310 INFO [stdout] (default task-1) <CN=client>
> {code}
> 2. And client responds with empty certificate chain. Without asking for certificate
> {code}
> ^[[0m^[[0m13:55:33,432 INFO [stdout] (default task-2) *** Certificate chain
> ^[[0m^[[0m13:55:33,432 INFO [stdout] (default task-2) <Empty>
> ^[[0m^[[0m13:55:33,432 INFO [stdout] (default task-2) ***
> {code}
> I am attaching:
> * server.log - server log with -Djavax.net.debug=all turn on.
> * 2wayTLS.pcap - wireshark recording of port 8443
> * secured-app - tested application
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7218) Unable to setup CLIENT_CERT authentication with elytron.
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7218?page=com.atlassian.jira.plugin.... ]
Jan Kalina commented on WFLY-7218:
----------------------------------
The certificate is not required, because setting setWantClientAuth(true) resets needClientAuth to false.
> Unable to setup CLIENT_CERT authentication with elytron.
> --------------------------------------------------------
>
> Key: WFLY-7218
> URL: https://issues.jboss.org/browse/WFLY-7218
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Blocker
>
> Following Zach's notes on [How to setup 2 way TLS|https://gitlab.cee.redhat.com/zrhoads/kbase/blob/master/eap71.elytron...] I am unable to setup it properly. User is not requested by browser for specifying client certificate and get access to application without certificate.
> In log you there is:
> 1. Server send request for certificate
> {code}
> ^[[0m^[[0m13:55:33,309 INFO [stdout] (default task-1) *** CertificateRequest
> ^[[0m^[[0m13:55:33,309 INFO [stdout] (default task-1) Cert Types: RSA, DSS, ECDSA
> ^[[0m^[[0m13:55:33,309 INFO [stdout] (default task-1) Cert Authorities:
> ^[[0m^[[0m13:55:33,310 INFO [stdout] (default task-1) <CN=client>
> {code}
> 2. And client responds with empty certificate chain. Without asking for certificate
> {code}
> ^[[0m^[[0m13:55:33,432 INFO [stdout] (default task-2) *** Certificate chain
> ^[[0m^[[0m13:55:33,432 INFO [stdout] (default task-2) <Empty>
> ^[[0m^[[0m13:55:33,432 INFO [stdout] (default task-2) ***
> {code}
> I am attaching:
> * server.log - server log with -Djavax.net.debug=all turn on.
> * 2wayTLS.pcap - wireshark recording of port 8443
> * secured-app - tested application
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JASSIST-261) Issue with javassist on jdk 9b112
by Andrei Ivanov (JIRA)
[ https://issues.jboss.org/browse/JASSIST-261?page=com.atlassian.jira.plugi... ]
Andrei Ivanov commented on JASSIST-261:
---------------------------------------
But 3.21 also has fixes for other issues not related to Java 9 support.
I would suggest releasing 3.21.0 for them and perhaps have a different release for Java 9.
> Issue with javassist on jdk 9b112
> ---------------------------------
>
> Key: JASSIST-261
> URL: https://issues.jboss.org/browse/JASSIST-261
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.20.0-GA
> Environment: Javassist with jdk 9b112
> Reporter: Hoang Chuong Tran
> Assignee: Shigeru Chiba
>
> I am migrating a project to java 9, which also uses javassist to generate runtime code.
> One test of mine fails on jdk 9b112 while it passes on jdk 8u77.
> {noformat}
> import static javassist.CtClass.voidType;
> import java.lang.reflect.Method;
> import java.lang.reflect.Modifier;
> import java.util.HashMap;
> import java.util.Map;
> import org.junit.Test;
> import javassist.ClassClassPath;
> import javassist.ClassPool;
> import javassist.CtClass;
> import javassist.CtField;
> import javassist.CtMethod;
> import javassist.CtNewMethod;
> public class MyTests {
> public static class MyObject {
> protected Object field;
> Object getField() {return field;}
> public void setField(Object field) {}
> }
> @Test
> public void test() throws InstantiationException, IllegalAccessException {
> Class<? extends MyObject> clazz = compile(MyObject.class);
> clazz.newInstance().setField(null);
> }
> /** Compile a transfer class */
> public static synchronized Class<? extends MyObject> compile(Class<?> targetClass) {
> // Determine class setters
> Map<String, Method> setters = extractSetters(targetClass);
> ClassPool classPool = ClassPool.getDefault();
> classPool.insertClassPath(new ClassClassPath(targetClass));
> try {
> // Compile a new transfer class on the fly
> CtClass baseClass = classPool.get(MyObject.class.getName());
> CtClass proxyClass = classPool.makeClass(targetClass.getName() + "_Modified", baseClass);
> for(Method originalSetter : setters.values()) {
> // Create a field to hold the attribute
> Class<?> fieldClass = originalSetter.getParameterTypes()[0];
> CtClass fieldType = classPool.get(fieldClass.getName());
> String fieldName = originalSetter.getName().substring(3);
> CtField field = new CtField(fieldType, fieldName, proxyClass);
> proxyClass.addField(field);
> // Create a setter method to set that field
> CtClass[] parameters = new CtClass[] { fieldType };
> String setterBody = "{ System.out.println(\"Hello World\"); }";
> CtMethod setter = CtNewMethod.make(voidType, originalSetter.getName(), parameters, new CtClass[0], setterBody, proxyClass);
> proxyClass.addMethod(setter);
> }
> Class<? extends MyObject> javaClass = proxyClass.toClass(targetClass.getClassLoader(), targetClass.getProtectionDomain());
> return javaClass;
> } catch(Exception e) {
> throw new RuntimeException("Failure during transfer compilation for " + targetClass, e);
> }
> }
> /** Extract setter methods from a class */
> public static Map<String, Method> extractSetters(Class<?> cls) {
> Map<String, Method> setters = new HashMap<String, Method>();
> for(Method method : cls.getMethods()) {
> // Lookup setter methods
> if(method.getName().startsWith("set")) {
> // Only public setters
> int modifiers = method.getModifiers();
> if(Modifier.isPublic(modifiers)) {
> Class<?>[] exceptions = method.getExceptionTypes();
> Class<?>[] parameters = method.getParameterTypes();
> Class<?> returnType = method.getReturnType();
> if(exceptions.length <= 0 && parameters.length == 1 && "void".equals(returnType.getName())) {
> setters.put(method.getName(), method);
> }
> }
> }
> }
> return setters;
> }
> }
> {noformat}
> On jdk 8u77, the {{compile()}} function returns with success and "Hello world" is printed to the console.
> On jdk 9b112, I got the following exception
> {noformat}
> java.lang.RuntimeException: Failure during transfer compilation for class MyTests$MyObject
> at MyTests.compile(MyTests.java:68)
> at MyTests.test(MyTests.java:29)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:670)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: javassist.NotFoundException: java.lang.Object
> at javassist.ClassPool.get(ClassPool.java:450)
> at MyTests.compile(MyTests.java:51)
> ... 24 more
> {noformat}
> I suspect that is due to the jigsaw integration into the jdk.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1836) Rejection-style transformer tests assume each operation generated by parser has distinct PathAddress
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1836?page=com.atlassian.jira.plugi... ]
Kabir Khan commented on WFCORE-1836:
------------------------------------
[~pferraro] Are you talking about the recursive loop in checkFailedTransformedBootOperations, or in the FailedOperationTransformationConfig?
> Rejection-style transformer tests assume each operation generated by parser has distinct PathAddress
> ----------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1836
> URL: https://issues.jboss.org/browse/WFCORE-1836
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Reporter: Paul Ferraro
> Assignee: Brian Stansberry
>
> For rejection-style transformer tests, the subsystem test framework stores expected rejected operations in a map keyed by PathAddress. This is fine when the subsystem's parser only generates add operations. However, if the parser generates an add operation as well as a a write-attribute operation, these 2 operations will have the same path address. If we expect one of these operations to be rejected, but not the other, we end up with an unexpected rejection - and the test fails.
> This is a little hard to explain in the abstract, so let me know if any of the above doesn't make sense.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JASSIST-261) Issue with javassist on jdk 9b112
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/JASSIST-261?page=com.atlassian.jira.plugi... ]
Scott Marlow commented on JASSIST-261:
--------------------------------------
+1 for the idea of releasing a 3.21.0.CR1 for now and later adjusting for coming Java 9 updates (if needed) prior to 3.21.0.GA/Final.
> Issue with javassist on jdk 9b112
> ---------------------------------
>
> Key: JASSIST-261
> URL: https://issues.jboss.org/browse/JASSIST-261
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.20.0-GA
> Environment: Javassist with jdk 9b112
> Reporter: Hoang Chuong Tran
> Assignee: Shigeru Chiba
>
> I am migrating a project to java 9, which also uses javassist to generate runtime code.
> One test of mine fails on jdk 9b112 while it passes on jdk 8u77.
> {noformat}
> import static javassist.CtClass.voidType;
> import java.lang.reflect.Method;
> import java.lang.reflect.Modifier;
> import java.util.HashMap;
> import java.util.Map;
> import org.junit.Test;
> import javassist.ClassClassPath;
> import javassist.ClassPool;
> import javassist.CtClass;
> import javassist.CtField;
> import javassist.CtMethod;
> import javassist.CtNewMethod;
> public class MyTests {
> public static class MyObject {
> protected Object field;
> Object getField() {return field;}
> public void setField(Object field) {}
> }
> @Test
> public void test() throws InstantiationException, IllegalAccessException {
> Class<? extends MyObject> clazz = compile(MyObject.class);
> clazz.newInstance().setField(null);
> }
> /** Compile a transfer class */
> public static synchronized Class<? extends MyObject> compile(Class<?> targetClass) {
> // Determine class setters
> Map<String, Method> setters = extractSetters(targetClass);
> ClassPool classPool = ClassPool.getDefault();
> classPool.insertClassPath(new ClassClassPath(targetClass));
> try {
> // Compile a new transfer class on the fly
> CtClass baseClass = classPool.get(MyObject.class.getName());
> CtClass proxyClass = classPool.makeClass(targetClass.getName() + "_Modified", baseClass);
> for(Method originalSetter : setters.values()) {
> // Create a field to hold the attribute
> Class<?> fieldClass = originalSetter.getParameterTypes()[0];
> CtClass fieldType = classPool.get(fieldClass.getName());
> String fieldName = originalSetter.getName().substring(3);
> CtField field = new CtField(fieldType, fieldName, proxyClass);
> proxyClass.addField(field);
> // Create a setter method to set that field
> CtClass[] parameters = new CtClass[] { fieldType };
> String setterBody = "{ System.out.println(\"Hello World\"); }";
> CtMethod setter = CtNewMethod.make(voidType, originalSetter.getName(), parameters, new CtClass[0], setterBody, proxyClass);
> proxyClass.addMethod(setter);
> }
> Class<? extends MyObject> javaClass = proxyClass.toClass(targetClass.getClassLoader(), targetClass.getProtectionDomain());
> return javaClass;
> } catch(Exception e) {
> throw new RuntimeException("Failure during transfer compilation for " + targetClass, e);
> }
> }
> /** Extract setter methods from a class */
> public static Map<String, Method> extractSetters(Class<?> cls) {
> Map<String, Method> setters = new HashMap<String, Method>();
> for(Method method : cls.getMethods()) {
> // Lookup setter methods
> if(method.getName().startsWith("set")) {
> // Only public setters
> int modifiers = method.getModifiers();
> if(Modifier.isPublic(modifiers)) {
> Class<?>[] exceptions = method.getExceptionTypes();
> Class<?>[] parameters = method.getParameterTypes();
> Class<?> returnType = method.getReturnType();
> if(exceptions.length <= 0 && parameters.length == 1 && "void".equals(returnType.getName())) {
> setters.put(method.getName(), method);
> }
> }
> }
> }
> return setters;
> }
> }
> {noformat}
> On jdk 8u77, the {{compile()}} function returns with success and "Hello world" is printed to the console.
> On jdk 9b112, I got the following exception
> {noformat}
> java.lang.RuntimeException: Failure during transfer compilation for class MyTests$MyObject
> at MyTests.compile(MyTests.java:68)
> at MyTests.test(MyTests.java:29)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:670)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: javassist.NotFoundException: java.lang.Object
> at javassist.ClassPool.get(ClassPool.java:450)
> at MyTests.compile(MyTests.java:51)
> ... 24 more
> {noformat}
> I suspect that is due to the jigsaw integration into the jdk.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JGRP-2103) GroupRequest times out when the only recipient leaves too soon
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/JGRP-2103?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on JGRP-2103:
------------------------------------
> The point of passing the listener as arg to the call itself, rather than setting it later, is exactly to prevent the scenario you hit.
I don't agree, as long as it's part of the API it should work :)
Adding the listener later made it possible for me to use a single instance as the request listener and as the timeout task, both having access to `GroupRequest.getResults()`. I'm pretty sure I can get it to work with the listener created beforehand, it will just be a little uglier.
> I assume this doesn't happen in 4.0?
Indeed, 4.0 is fine.
> GroupRequest times out when the only recipient leaves too soon
> --------------------------------------------------------------
>
> Key: JGRP-2103
> URL: https://issues.jboss.org/browse/JGRP-2103
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.10
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Fix For: 3.6.12
>
>
> There is a concurrency issue when a user calls {{messageDispatcher.cast(dests, msg, options, block_for_results, null)}} and adds a listener later with {{req.setListener(listener)}}.
> If the node installs a new view between {{cast()}} and {{setListener()}} that removes all the {{dests}} nodes, the listener is never called. This test fails:
> {code}
> public void testCastToMissingNode() throws Exception {
> d1.setRequestHandler(new MyHandler(new byte[10]));
> b = createChannel(a);
> b.setName("B");
> final CountDownLatch targetLatch = new CountDownLatch(1);
> d2 = new MessageDispatcher(b, null, null, new RequestHandler() {
> @Override
> public Object handle(Message msg) throws Exception {
> targetLatch.await();
> return null;
> }
> });
> b.connect("MessageDispatcherUnitTest");
> Assert.assertEquals(2, b.getView().size());
> final CountDownLatch futureLatch = new CountDownLatch(1);
> FutureListener listener = new FutureListener() {
> @Override
> public void futureDone(Future future) {
> futureLatch.countDown();
> }
> };
> List<Address> dests = Collections.singletonList(b.getAddress());
> byte[] buf = new byte[1];
> Message msg = new Message();
> msg.setBuffer(buf);
> NotifyingFuture<RspList<Object>> future = d1.castMessageWithFuture(dests, msg, RequestOptions.SYNC(), null);
> b.disconnect();
> Thread.sleep(100);
> future.setListener(listener);
> assertTrue(futureLatch.await(10, TimeUnit.SECONDS));
> targetLatch.countDown();
> }
> {code}
> If I change the {{d1.castMessageWithFuture(dests, msg, RequestOptions.SYNC(), null)}} with {{d1.castMessageWithFuture(dests, msg, RequestOptions.SYNC(), listener)}} and comment out the {{future.setListener(listener)}} line, the test passes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1834) Unexpected attribute error message doesn't list 'name' attribute.
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1834?page=com.atlassian.jira.plugi... ]
Tomaz Cerar commented on WFCORE-1834:
-------------------------------------
Name isn't technically an attribute, but name/anchor for resource.
But yes we should report that in error messages.
> Unexpected attribute error message doesn't list 'name' attribute.
> -----------------------------------------------------------------
>
> Key: WFCORE-1834
> URL: https://issues.jboss.org/browse/WFCORE-1834
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Darran Lofthouse
> Assignee: Tomaz Cerar
> Fix For: 3.0.0.Alpha9
>
>
> I have recently updated one of our resource definitions and missed updating one of the subsystem templates so currently have the following error reported: -
> {noformat}
> Message: WFLYCTL0376: Unexpected attribute 'security-domain' encountered. Valid attributes are: 'http-authentication-factory, override-deployment-config'
> [Host Controller] at org.jboss.as.controller.parsing.ParseUtils.unexpectedAttribute(ParseUtils.java:128)
> {noformat}
> Previously my resource has been using the 'security-domain' attribute for it's name but now has been reverted to using 'name' for the name - in the above error message 'name' should have been listed as one of the valid attributes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (ELY-644) Creating LDAP security realm fails with cryptic error message
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-644?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse reassigned ELY-644:
------------------------------------
Assignee: Jan Kalina (was: Darran Lofthouse)
> Creating LDAP security realm fails with cryptic error message
> -------------------------------------------------------------
>
> Key: ELY-644
> URL: https://issues.jboss.org/browse/ELY-644
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Zach Rhoads
> Assignee: Jan Kalina
>
> When creating an LDAP security realm via CLI, setup fails with cryptic error message.
> For example, creating a dir-context works fine:
> /subsystem=elytron/dir-context=exampleDC:add(url="ldap://127.0.0.1:10389",principal="uid=admin,ou=system",credential="secret")
> But when creating an ldap-realm:
> /subsystem=elytron/ldap-realm=exampleLR:add(dir-context=exampleDC,identity-mapping={search-base-dn="ou=Users,dc=jboss,dc=org",rdn-identifier="uid",user-password-mapper={from="userPassword"}})
> It fails:
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException",
> "rolled-back" => true
> }
> Full log in wildfly:
> 14:11:03,368 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("ldap-realm" => "exampleLR")
> ]): java.lang.IllegalArgumentException
> at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:69)
> at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:267)
> at org.wildfly.extension.elytron.LdapRealmDefinition$UserPasswordCredentialMappingObjectDefinition.configure(LdapRealmDefinition.java:163)
> at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.configureIdentityMapping(LdapRealmDefinition.java:420)
> at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.performRuntime(LdapRealmDefinition.java:375)
> at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337)
> at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> 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)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JGRP-2103) GroupRequest times out when the only recipient leaves too soon
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2103?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2103:
--------------------------------
The point of passing the listener as arg to the call itself, rather than setting it later, is exactly to prevent the scenario you hit.
> GroupRequest times out when the only recipient leaves too soon
> --------------------------------------------------------------
>
> Key: JGRP-2103
> URL: https://issues.jboss.org/browse/JGRP-2103
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.10
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Fix For: 3.6.12
>
>
> There is a concurrency issue when a user calls {{messageDispatcher.cast(dests, msg, options, block_for_results, null)}} and adds a listener later with {{req.setListener(listener)}}.
> If the node installs a new view between {{cast()}} and {{setListener()}} that removes all the {{dests}} nodes, the listener is never called. This test fails:
> {code}
> public void testCastToMissingNode() throws Exception {
> d1.setRequestHandler(new MyHandler(new byte[10]));
> b = createChannel(a);
> b.setName("B");
> final CountDownLatch targetLatch = new CountDownLatch(1);
> d2 = new MessageDispatcher(b, null, null, new RequestHandler() {
> @Override
> public Object handle(Message msg) throws Exception {
> targetLatch.await();
> return null;
> }
> });
> b.connect("MessageDispatcherUnitTest");
> Assert.assertEquals(2, b.getView().size());
> final CountDownLatch futureLatch = new CountDownLatch(1);
> FutureListener listener = new FutureListener() {
> @Override
> public void futureDone(Future future) {
> futureLatch.countDown();
> }
> };
> List<Address> dests = Collections.singletonList(b.getAddress());
> byte[] buf = new byte[1];
> Message msg = new Message();
> msg.setBuffer(buf);
> NotifyingFuture<RspList<Object>> future = d1.castMessageWithFuture(dests, msg, RequestOptions.SYNC(), null);
> b.disconnect();
> Thread.sleep(100);
> future.setListener(listener);
> assertTrue(futureLatch.await(10, TimeUnit.SECONDS));
> targetLatch.countDown();
> }
> {code}
> If I change the {{d1.castMessageWithFuture(dests, msg, RequestOptions.SYNC(), null)}} with {{d1.castMessageWithFuture(dests, msg, RequestOptions.SYNC(), listener)}} and comment out the {{future.setListener(listener)}} line, the test passes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JGRP-2103) GroupRequest times out when the only recipient leaves too soon
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2103?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2103:
---------------------------
Fix Version/s: 3.6.12
> GroupRequest times out when the only recipient leaves too soon
> --------------------------------------------------------------
>
> Key: JGRP-2103
> URL: https://issues.jboss.org/browse/JGRP-2103
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.10
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Fix For: 3.6.12
>
>
> There is a concurrency issue when a user calls {{messageDispatcher.cast(dests, msg, options, block_for_results, null)}} and adds a listener later with {{req.setListener(listener)}}.
> If the node installs a new view between {{cast()}} and {{setListener()}} that removes all the {{dests}} nodes, the listener is never called. This test fails:
> {code}
> public void testCastToMissingNode() throws Exception {
> d1.setRequestHandler(new MyHandler(new byte[10]));
> b = createChannel(a);
> b.setName("B");
> final CountDownLatch targetLatch = new CountDownLatch(1);
> d2 = new MessageDispatcher(b, null, null, new RequestHandler() {
> @Override
> public Object handle(Message msg) throws Exception {
> targetLatch.await();
> return null;
> }
> });
> b.connect("MessageDispatcherUnitTest");
> Assert.assertEquals(2, b.getView().size());
> final CountDownLatch futureLatch = new CountDownLatch(1);
> FutureListener listener = new FutureListener() {
> @Override
> public void futureDone(Future future) {
> futureLatch.countDown();
> }
> };
> List<Address> dests = Collections.singletonList(b.getAddress());
> byte[] buf = new byte[1];
> Message msg = new Message();
> msg.setBuffer(buf);
> NotifyingFuture<RspList<Object>> future = d1.castMessageWithFuture(dests, msg, RequestOptions.SYNC(), null);
> b.disconnect();
> Thread.sleep(100);
> future.setListener(listener);
> assertTrue(futureLatch.await(10, TimeUnit.SECONDS));
> targetLatch.countDown();
> }
> {code}
> If I change the {{d1.castMessageWithFuture(dests, msg, RequestOptions.SYNC(), null)}} with {{d1.castMessageWithFuture(dests, msg, RequestOptions.SYNC(), listener)}} and comment out the {{future.setListener(listener)}} line, the test passes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JGRP-2103) GroupRequest times out when the only recipient leaves too soon
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2103?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2103:
--------------------------------
I'll take a look. I assume this doesn't happen in 4.0?
> GroupRequest times out when the only recipient leaves too soon
> --------------------------------------------------------------
>
> Key: JGRP-2103
> URL: https://issues.jboss.org/browse/JGRP-2103
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.10
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Fix For: 3.6.12
>
>
> There is a concurrency issue when a user calls {{messageDispatcher.cast(dests, msg, options, block_for_results, null)}} and adds a listener later with {{req.setListener(listener)}}.
> If the node installs a new view between {{cast()}} and {{setListener()}} that removes all the {{dests}} nodes, the listener is never called. This test fails:
> {code}
> public void testCastToMissingNode() throws Exception {
> d1.setRequestHandler(new MyHandler(new byte[10]));
> b = createChannel(a);
> b.setName("B");
> final CountDownLatch targetLatch = new CountDownLatch(1);
> d2 = new MessageDispatcher(b, null, null, new RequestHandler() {
> @Override
> public Object handle(Message msg) throws Exception {
> targetLatch.await();
> return null;
> }
> });
> b.connect("MessageDispatcherUnitTest");
> Assert.assertEquals(2, b.getView().size());
> final CountDownLatch futureLatch = new CountDownLatch(1);
> FutureListener listener = new FutureListener() {
> @Override
> public void futureDone(Future future) {
> futureLatch.countDown();
> }
> };
> List<Address> dests = Collections.singletonList(b.getAddress());
> byte[] buf = new byte[1];
> Message msg = new Message();
> msg.setBuffer(buf);
> NotifyingFuture<RspList<Object>> future = d1.castMessageWithFuture(dests, msg, RequestOptions.SYNC(), null);
> b.disconnect();
> Thread.sleep(100);
> future.setListener(listener);
> assertTrue(futureLatch.await(10, TimeUnit.SECONDS));
> targetLatch.countDown();
> }
> {code}
> If I change the {{d1.castMessageWithFuture(dests, msg, RequestOptions.SYNC(), null)}} with {{d1.castMessageWithFuture(dests, msg, RequestOptions.SYNC(), listener)}} and comment out the {{future.setListener(listener)}} line, the test passes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JGRP-2103) GroupRequest times out when the only recipient leaves too soon
by Dan Berindei (JIRA)
Dan Berindei created JGRP-2103:
----------------------------------
Summary: GroupRequest times out when the only recipient leaves too soon
Key: JGRP-2103
URL: https://issues.jboss.org/browse/JGRP-2103
Project: JGroups
Issue Type: Bug
Reporter: Dan Berindei
Assignee: Bela Ban
There is a concurrency issue when a user calls {{messageDispatcher.cast(dests, msg, options, block_for_results, null)}} and adds a listener later with {{req.setListener(listener)}}.
If the node installs a new view between {{cast()}} and {{setListener()}} that removes all the {{dests}} nodes, the listener is never called. This test fails:
{code}
public void testCastToMissingNode() throws Exception {
d1.setRequestHandler(new MyHandler(new byte[10]));
b = createChannel(a);
b.setName("B");
final CountDownLatch targetLatch = new CountDownLatch(1);
d2 = new MessageDispatcher(b, null, null, new RequestHandler() {
@Override
public Object handle(Message msg) throws Exception {
targetLatch.await();
return null;
}
});
b.connect("MessageDispatcherUnitTest");
Assert.assertEquals(2, b.getView().size());
final CountDownLatch futureLatch = new CountDownLatch(1);
FutureListener listener = new FutureListener() {
@Override
public void futureDone(Future future) {
futureLatch.countDown();
}
};
List<Address> dests = Collections.singletonList(b.getAddress());
byte[] buf = new byte[1];
Message msg = new Message();
msg.setBuffer(buf);
NotifyingFuture<RspList<Object>> future = d1.castMessageWithFuture(dests, msg, RequestOptions.SYNC(), null);
b.disconnect();
Thread.sleep(100);
future.setListener(listener);
assertTrue(futureLatch.await(10, TimeUnit.SECONDS));
targetLatch.countDown();
}
{code}
If I change the {{d1.castMessageWithFuture(dests, msg, RequestOptions.SYNC(), null)}} with {{d1.castMessageWithFuture(dests, msg, RequestOptions.SYNC(), listener)}} and comment out the {{future.setListener(listener)}} line, the test passes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JGRP-2103) GroupRequest times out when the only recipient leaves too soon
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/JGRP-2103?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated JGRP-2103:
-------------------------------
Affects Version/s: 3.6.10
> GroupRequest times out when the only recipient leaves too soon
> --------------------------------------------------------------
>
> Key: JGRP-2103
> URL: https://issues.jboss.org/browse/JGRP-2103
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.10
> Reporter: Dan Berindei
> Assignee: Bela Ban
>
> There is a concurrency issue when a user calls {{messageDispatcher.cast(dests, msg, options, block_for_results, null)}} and adds a listener later with {{req.setListener(listener)}}.
> If the node installs a new view between {{cast()}} and {{setListener()}} that removes all the {{dests}} nodes, the listener is never called. This test fails:
> {code}
> public void testCastToMissingNode() throws Exception {
> d1.setRequestHandler(new MyHandler(new byte[10]));
> b = createChannel(a);
> b.setName("B");
> final CountDownLatch targetLatch = new CountDownLatch(1);
> d2 = new MessageDispatcher(b, null, null, new RequestHandler() {
> @Override
> public Object handle(Message msg) throws Exception {
> targetLatch.await();
> return null;
> }
> });
> b.connect("MessageDispatcherUnitTest");
> Assert.assertEquals(2, b.getView().size());
> final CountDownLatch futureLatch = new CountDownLatch(1);
> FutureListener listener = new FutureListener() {
> @Override
> public void futureDone(Future future) {
> futureLatch.countDown();
> }
> };
> List<Address> dests = Collections.singletonList(b.getAddress());
> byte[] buf = new byte[1];
> Message msg = new Message();
> msg.setBuffer(buf);
> NotifyingFuture<RspList<Object>> future = d1.castMessageWithFuture(dests, msg, RequestOptions.SYNC(), null);
> b.disconnect();
> Thread.sleep(100);
> future.setListener(listener);
> assertTrue(futureLatch.await(10, TimeUnit.SECONDS));
> targetLatch.countDown();
> }
> {code}
> If I change the {{d1.castMessageWithFuture(dests, msg, RequestOptions.SYNC(), null)}} with {{d1.castMessageWithFuture(dests, msg, RequestOptions.SYNC(), listener)}} and comment out the {{future.setListener(listener)}} line, the test passes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7234) Ability to identify primary singleton provider node
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-7234:
----------------------------------
Summary: Ability to identify primary singleton provider node
Key: WFLY-7234
URL: https://issues.jboss.org/browse/WFLY-7234
Project: WildFly
Issue Type: Feature Request
Components: Clustering
Affects Versions: 10.1.0.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
The current Singleton interface only allow a user to tell whether or not the current node is the singleton provider. Most backup services will proxy the service of the primary node, and thus will need to be able to identify which node is the current primary provider.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JGRP-2102) bind_interface="eth0" and bind_addr="LINK_LOCAL" config are conflict
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2102?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2102:
---------------------------
Fix Version/s: (was: 4.0)
{{bind_interface}} is not present in 4.0 anymore
> bind_interface="eth0" and bind_addr="LINK_LOCAL" config are conflict
> --------------------------------------------------------------------
>
> Key: JGRP-2102
> URL: https://issues.jboss.org/browse/JGRP-2102
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.1
> Environment: [root@wtc2k01v27 ~] CLONE # ip a
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> inet6 2606:ae00:e200:3f::83/128 scope global
> valid_lft forever preferred_lft forever
> inet6 ::1/128 scope host
> valid_lft forever preferred_lft forever
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
> link/ether 00:50:56:ab:2a:ea brd ff:ff:ff:ff:ff:ff
> inet 107.250.167.28/25 brd 107.250.167.127 scope global eth0
> inet6 2606:ae00:e200:3f::28/64 scope global
> valid_lft forever preferred_lft forever
> inet6 fe80::250:56ff:feab:2aea/64 scope link
> valid_lft forever preferred_lft forever
> 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
> link/ether 00:50:56:ab:d6:12 brd ff:ff:ff:ff:ff:ff
> inet 192.168.0.59/24 brd 192.168.0.255 scope global eth1
> inet6 fe80::250:56ff:feab:d612/64 scope link
> valid_lft forever preferred_lft forever
> There're eth0 and eth1 exists in the environment
> Reporter: 俐佳 张
> Assignee: Bela Ban
> Fix For: 3.6.12
>
> Attachments: jgroups-udp.xml
>
>
> Error happens while
> Caused by: org.infinispan.commons.CacheConfigurationException: ISPN000085: Error while trying to create a channel using the specified configuration file: /opt/oss/NSN-icf_notification_dispatcher/conf/jgroups-udp.xml
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:406)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannel(JGroupsTransport.java:307)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannelAndRPCDispatcher(JGroupsTransport.java:351)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:188)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:56)
> at java.lang.reflect.Method.invoke(Method.java:620)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
> at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:226)
> ... 26 more
> Caused by: java.lang.Exception: Property assignment of bind_interface in UDP with original property value eth0 and converted to null could not be assigned
> at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1153)
> at org.jgroups.stack.Configurator.createLayer(Configurator.java:444)
> at org.jgroups.stack.Configurator.createProtocols(Configurator.java:398)
> at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:90)
> at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:57)
> at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:477)
> at org.jgroups.JChannel.init(JChannel.java:854)
> at org.jgroups.JChannel.<init>(JChannel.java:159)
> at org.jgroups.JChannel.<init>(JChannel.java:129)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:404)
> ... 39 more
> Caused by: java.lang.Exception: Conversion of bind_interface in UDP with original property value eth0 failed
> at org.jgroups.conf.PropertyHelper.getConvertedValue(PropertyHelper.java:84)
> at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1147)
> ... 48 more
> Caused by: java.lang.mail(a)example.comIllegalArgumentException: network interface eth0 does not contain address fe80:0:0:0:250:56ff:feab:d612%3
> at org.jgroups.util.Util.validateBindAddressFromInterface(Util.java:3132)
> bind_interface="eth0" and bind_addr="LINK_LOCAL" config are config at the same time
> but it couldn't get the eth0 link local address but return eth1 link local address
> This code return the first address that match, it should return with eth0
> jgroups-3.6.1.Final-sources\org\jgroups\util\Util.java
> public static InetAddress getAddress(AddressScope scope) ----> scope is LINK_LOCAL
> throws SocketException
> {
> InetAddress address = null;
> Enumeration intfs = NetworkInterface.getNetworkInterfaces();
> while (intfs.hasMoreElements()) {
> NetworkInterface intf = (NetworkInterface)intfs.nextElement();
> try {
> if (intf.isUp()) {
> address = getAddress(intf, scope); -------> It will return the first LINK_LOCAL address from NICs list
> if (address != null)
> return address;
> }
> }
> catch (SocketException e) {
> }
> }
> return null;
> }
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7226) Missing realm-map attribute for mapped-regex-realm-mapper throws IllegalArgumentException to server log
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/WFLY-7226?page=com.atlassian.jira.plugin.... ]
Ilia Vassilev commented on WFLY-7226:
-------------------------------------
Hi [~honza889], do you mind if I work on this one?
> Missing realm-map attribute for mapped-regex-realm-mapper throws IllegalArgumentException to server log
> -------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7226
> URL: https://issues.jboss.org/browse/WFLY-7226
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
>
> In case when mapped-regex-realm-mapper is added through CLI and realm-map attribute is not used then IllegalArgumentException is thrown to server log instead of some CLI failure message like "realm-map may not be null".
> Expcetion in server log:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("mapped-regex-realm-mapper" => "MappedRealmMapper")
> ]): java.lang.IllegalArgumentException
> at org.jboss.dmr.ModelValue.getKeys(ModelValue.java:139)
> at org.jboss.dmr.ModelNode.keys(ModelNode.java:1378)
> at org.wildfly.extension.elytron.RealmMapperDefinitions$MappedRegexRealmMapperAddHandler.performRuntime(RealmMapperDefinitions.java:221)
> at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337)
> at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> 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}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JASSIST-261) Issue with javassist on jdk 9b112
by Steve Ebersole (JIRA)
[ https://issues.jboss.org/browse/JASSIST-261?page=com.atlassian.jira.plugi... ]
Steve Ebersole edited comment on JASSIST-261 at 9/28/16 9:02 AM:
-----------------------------------------------------------------
Initially I had incorrectly run the Hibernate tests with this Javassist SNAPSHOT using JDK 8 and all the tests passed. The changes also got those tests previously failing due to Javassist in Java 9 to pass when running with JDK 9. So it would seem to me (limited to Hibernate's usage) that your changes leave Javassist simultaneously compatible with Java 8 and Java 9. Therefore I'd personally not worry about Java 9 still being ea. However Java 9 is still evolving, and as Scott pointed out, one of the current change proposals specifically targets better operability with reflective libraries (such as Javassist) so I'd anticipate having to at least verify this all works with later Java 9 releases.
If you want to start "Java 9 support" with a new version increment (3.20 -> 3.21) then I'd suggest a 3.21.0.CR1 for now. That gives Hibernate and others a named Javassist release to target, but still gives you the flexibility to adjust for later changes made in coming Java 9 updates prior to a 3.21 GA/Final
was (Author: sebersole):
Did you had to make code changes in Javassist to make it Java 9 compatible? And if so, did those changes make it incompatible with Java 8?
Initially I had incorrectly run the Hibernate tests with this Javassist SNAPSHOT using JDK 8 and all the tests passed. The changes also got those tests previously failing due to Javassist in Java 9 to pass. So it would seem to me (limited to Hibernate's usage) that your changes leave Javassist simultaneously compatible with Java 8 and Java 9. Therefore I'd personally not worry about Java 9 still being ea. However Java 9 is still evolving, and as Scott pointed out, one of the current change proposals specifically targets better operability with reflective libraries (such as Javassist) so I'd anticipate having to at least verify this all works with later Java 9 releases.
If you want to start "Java 9 support" with a new version increment (3.20 -> 3.21) then I'd suggest a 3.21.0.CR1 for now. That gives Hibernate and others a named Javassist release to target, but still gives you the flexibility to adjust for later changes made in coming Java 9 updates prior to a 3.21 GA/Final
> Issue with javassist on jdk 9b112
> ---------------------------------
>
> Key: JASSIST-261
> URL: https://issues.jboss.org/browse/JASSIST-261
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.20.0-GA
> Environment: Javassist with jdk 9b112
> Reporter: Hoang Chuong Tran
> Assignee: Shigeru Chiba
>
> I am migrating a project to java 9, which also uses javassist to generate runtime code.
> One test of mine fails on jdk 9b112 while it passes on jdk 8u77.
> {noformat}
> import static javassist.CtClass.voidType;
> import java.lang.reflect.Method;
> import java.lang.reflect.Modifier;
> import java.util.HashMap;
> import java.util.Map;
> import org.junit.Test;
> import javassist.ClassClassPath;
> import javassist.ClassPool;
> import javassist.CtClass;
> import javassist.CtField;
> import javassist.CtMethod;
> import javassist.CtNewMethod;
> public class MyTests {
> public static class MyObject {
> protected Object field;
> Object getField() {return field;}
> public void setField(Object field) {}
> }
> @Test
> public void test() throws InstantiationException, IllegalAccessException {
> Class<? extends MyObject> clazz = compile(MyObject.class);
> clazz.newInstance().setField(null);
> }
> /** Compile a transfer class */
> public static synchronized Class<? extends MyObject> compile(Class<?> targetClass) {
> // Determine class setters
> Map<String, Method> setters = extractSetters(targetClass);
> ClassPool classPool = ClassPool.getDefault();
> classPool.insertClassPath(new ClassClassPath(targetClass));
> try {
> // Compile a new transfer class on the fly
> CtClass baseClass = classPool.get(MyObject.class.getName());
> CtClass proxyClass = classPool.makeClass(targetClass.getName() + "_Modified", baseClass);
> for(Method originalSetter : setters.values()) {
> // Create a field to hold the attribute
> Class<?> fieldClass = originalSetter.getParameterTypes()[0];
> CtClass fieldType = classPool.get(fieldClass.getName());
> String fieldName = originalSetter.getName().substring(3);
> CtField field = new CtField(fieldType, fieldName, proxyClass);
> proxyClass.addField(field);
> // Create a setter method to set that field
> CtClass[] parameters = new CtClass[] { fieldType };
> String setterBody = "{ System.out.println(\"Hello World\"); }";
> CtMethod setter = CtNewMethod.make(voidType, originalSetter.getName(), parameters, new CtClass[0], setterBody, proxyClass);
> proxyClass.addMethod(setter);
> }
> Class<? extends MyObject> javaClass = proxyClass.toClass(targetClass.getClassLoader(), targetClass.getProtectionDomain());
> return javaClass;
> } catch(Exception e) {
> throw new RuntimeException("Failure during transfer compilation for " + targetClass, e);
> }
> }
> /** Extract setter methods from a class */
> public static Map<String, Method> extractSetters(Class<?> cls) {
> Map<String, Method> setters = new HashMap<String, Method>();
> for(Method method : cls.getMethods()) {
> // Lookup setter methods
> if(method.getName().startsWith("set")) {
> // Only public setters
> int modifiers = method.getModifiers();
> if(Modifier.isPublic(modifiers)) {
> Class<?>[] exceptions = method.getExceptionTypes();
> Class<?>[] parameters = method.getParameterTypes();
> Class<?> returnType = method.getReturnType();
> if(exceptions.length <= 0 && parameters.length == 1 && "void".equals(returnType.getName())) {
> setters.put(method.getName(), method);
> }
> }
> }
> }
> return setters;
> }
> }
> {noformat}
> On jdk 8u77, the {{compile()}} function returns with success and "Hello world" is printed to the console.
> On jdk 9b112, I got the following exception
> {noformat}
> java.lang.RuntimeException: Failure during transfer compilation for class MyTests$MyObject
> at MyTests.compile(MyTests.java:68)
> at MyTests.test(MyTests.java:29)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:670)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: javassist.NotFoundException: java.lang.Object
> at javassist.ClassPool.get(ClassPool.java:450)
> at MyTests.compile(MyTests.java:51)
> ... 24 more
> {noformat}
> I suspect that is due to the jigsaw integration into the jdk.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JASSIST-261) Issue with javassist on jdk 9b112
by Steve Ebersole (JIRA)
[ https://issues.jboss.org/browse/JASSIST-261?page=com.atlassian.jira.plugi... ]
Steve Ebersole commented on JASSIST-261:
----------------------------------------
Did you had to make code changes in Javassist to make it Java 9 compatible? And if so, did those changes make it incompatible with Java 8?
Initially I had incorrectly run the Hibernate tests with this Javassist SNAPSHOT using JDK 8 and all the tests passed. The changes also got those tests previously failing due to Javassist in Java 9 to pass. So it would seem to me (limited to Hibernate's usage) that your changes leave Javassist simultaneously compatible with Java 8 and Java 9. Therefore I'd personally not worry about Java 9 still being ea. However Java 9 is still evolving, and as Scott pointed out, one of the current change proposals specifically targets better operability with reflective libraries (such as Javassist) so I'd anticipate having to at least verify this all works with later Java 9 releases.
If you want to start "Java 9 support" with a new version increment (3.20 -> 3.21) then I'd suggest a 3.21.0.CR1 for now. That gives Hibernate and others a named Javassist release to target, but still gives you the flexibility to adjust for later changes made in coming Java 9 updates prior to a 3.21 GA/Final
> Issue with javassist on jdk 9b112
> ---------------------------------
>
> Key: JASSIST-261
> URL: https://issues.jboss.org/browse/JASSIST-261
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.20.0-GA
> Environment: Javassist with jdk 9b112
> Reporter: Hoang Chuong Tran
> Assignee: Shigeru Chiba
>
> I am migrating a project to java 9, which also uses javassist to generate runtime code.
> One test of mine fails on jdk 9b112 while it passes on jdk 8u77.
> {noformat}
> import static javassist.CtClass.voidType;
> import java.lang.reflect.Method;
> import java.lang.reflect.Modifier;
> import java.util.HashMap;
> import java.util.Map;
> import org.junit.Test;
> import javassist.ClassClassPath;
> import javassist.ClassPool;
> import javassist.CtClass;
> import javassist.CtField;
> import javassist.CtMethod;
> import javassist.CtNewMethod;
> public class MyTests {
> public static class MyObject {
> protected Object field;
> Object getField() {return field;}
> public void setField(Object field) {}
> }
> @Test
> public void test() throws InstantiationException, IllegalAccessException {
> Class<? extends MyObject> clazz = compile(MyObject.class);
> clazz.newInstance().setField(null);
> }
> /** Compile a transfer class */
> public static synchronized Class<? extends MyObject> compile(Class<?> targetClass) {
> // Determine class setters
> Map<String, Method> setters = extractSetters(targetClass);
> ClassPool classPool = ClassPool.getDefault();
> classPool.insertClassPath(new ClassClassPath(targetClass));
> try {
> // Compile a new transfer class on the fly
> CtClass baseClass = classPool.get(MyObject.class.getName());
> CtClass proxyClass = classPool.makeClass(targetClass.getName() + "_Modified", baseClass);
> for(Method originalSetter : setters.values()) {
> // Create a field to hold the attribute
> Class<?> fieldClass = originalSetter.getParameterTypes()[0];
> CtClass fieldType = classPool.get(fieldClass.getName());
> String fieldName = originalSetter.getName().substring(3);
> CtField field = new CtField(fieldType, fieldName, proxyClass);
> proxyClass.addField(field);
> // Create a setter method to set that field
> CtClass[] parameters = new CtClass[] { fieldType };
> String setterBody = "{ System.out.println(\"Hello World\"); }";
> CtMethod setter = CtNewMethod.make(voidType, originalSetter.getName(), parameters, new CtClass[0], setterBody, proxyClass);
> proxyClass.addMethod(setter);
> }
> Class<? extends MyObject> javaClass = proxyClass.toClass(targetClass.getClassLoader(), targetClass.getProtectionDomain());
> return javaClass;
> } catch(Exception e) {
> throw new RuntimeException("Failure during transfer compilation for " + targetClass, e);
> }
> }
> /** Extract setter methods from a class */
> public static Map<String, Method> extractSetters(Class<?> cls) {
> Map<String, Method> setters = new HashMap<String, Method>();
> for(Method method : cls.getMethods()) {
> // Lookup setter methods
> if(method.getName().startsWith("set")) {
> // Only public setters
> int modifiers = method.getModifiers();
> if(Modifier.isPublic(modifiers)) {
> Class<?>[] exceptions = method.getExceptionTypes();
> Class<?>[] parameters = method.getParameterTypes();
> Class<?> returnType = method.getReturnType();
> if(exceptions.length <= 0 && parameters.length == 1 && "void".equals(returnType.getName())) {
> setters.put(method.getName(), method);
> }
> }
> }
> }
> return setters;
> }
> }
> {noformat}
> On jdk 8u77, the {{compile()}} function returns with success and "Hello world" is printed to the console.
> On jdk 9b112, I got the following exception
> {noformat}
> java.lang.RuntimeException: Failure during transfer compilation for class MyTests$MyObject
> at MyTests.compile(MyTests.java:68)
> at MyTests.test(MyTests.java:29)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:670)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: javassist.NotFoundException: java.lang.Object
> at javassist.ClassPool.get(ClassPool.java:450)
> at MyTests.compile(MyTests.java:51)
> ... 24 more
> {noformat}
> I suspect that is due to the jigsaw integration into the jdk.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JGRP-2102) bind_interface="eth0" and bind_addr="LINK_LOCAL" config are conflict
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2102?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2102:
---------------------------
Fix Version/s: 3.6.12
4.0
> bind_interface="eth0" and bind_addr="LINK_LOCAL" config are conflict
> --------------------------------------------------------------------
>
> Key: JGRP-2102
> URL: https://issues.jboss.org/browse/JGRP-2102
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.1
> Environment: [root@wtc2k01v27 ~] CLONE # ip a
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> inet6 2606:ae00:e200:3f::83/128 scope global
> valid_lft forever preferred_lft forever
> inet6 ::1/128 scope host
> valid_lft forever preferred_lft forever
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
> link/ether 00:50:56:ab:2a:ea brd ff:ff:ff:ff:ff:ff
> inet 107.250.167.28/25 brd 107.250.167.127 scope global eth0
> inet6 2606:ae00:e200:3f::28/64 scope global
> valid_lft forever preferred_lft forever
> inet6 fe80::250:56ff:feab:2aea/64 scope link
> valid_lft forever preferred_lft forever
> 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
> link/ether 00:50:56:ab:d6:12 brd ff:ff:ff:ff:ff:ff
> inet 192.168.0.59/24 brd 192.168.0.255 scope global eth1
> inet6 fe80::250:56ff:feab:d612/64 scope link
> valid_lft forever preferred_lft forever
> There're eth0 and eth1 exists in the environment
> Reporter: 俐佳 张
> Assignee: Bela Ban
> Fix For: 3.6.12, 4.0
>
> Attachments: jgroups-udp.xml
>
>
> Error happens while
> Caused by: org.infinispan.commons.CacheConfigurationException: ISPN000085: Error while trying to create a channel using the specified configuration file: /opt/oss/NSN-icf_notification_dispatcher/conf/jgroups-udp.xml
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:406)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannel(JGroupsTransport.java:307)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannelAndRPCDispatcher(JGroupsTransport.java:351)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:188)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:56)
> at java.lang.reflect.Method.invoke(Method.java:620)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
> at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:226)
> ... 26 more
> Caused by: java.lang.Exception: Property assignment of bind_interface in UDP with original property value eth0 and converted to null could not be assigned
> at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1153)
> at org.jgroups.stack.Configurator.createLayer(Configurator.java:444)
> at org.jgroups.stack.Configurator.createProtocols(Configurator.java:398)
> at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:90)
> at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:57)
> at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:477)
> at org.jgroups.JChannel.init(JChannel.java:854)
> at org.jgroups.JChannel.<init>(JChannel.java:159)
> at org.jgroups.JChannel.<init>(JChannel.java:129)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:404)
> ... 39 more
> Caused by: java.lang.Exception: Conversion of bind_interface in UDP with original property value eth0 failed
> at org.jgroups.conf.PropertyHelper.getConvertedValue(PropertyHelper.java:84)
> at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1147)
> ... 48 more
> Caused by: java.lang.mail(a)example.comIllegalArgumentException: network interface eth0 does not contain address fe80:0:0:0:250:56ff:feab:d612%3
> at org.jgroups.util.Util.validateBindAddressFromInterface(Util.java:3132)
> bind_interface="eth0" and bind_addr="LINK_LOCAL" config are config at the same time
> but it couldn't get the eth0 link local address but return eth1 link local address
> This code return the first address that match, it should return with eth0
> jgroups-3.6.1.Final-sources\org\jgroups\util\Util.java
> public static InetAddress getAddress(AddressScope scope) ----> scope is LINK_LOCAL
> throws SocketException
> {
> InetAddress address = null;
> Enumeration intfs = NetworkInterface.getNetworkInterfaces();
> while (intfs.hasMoreElements()) {
> NetworkInterface intf = (NetworkInterface)intfs.nextElement();
> try {
> if (intf.isUp()) {
> address = getAddress(intf, scope); -------> It will return the first LINK_LOCAL address from NICs list
> if (address != null)
> return address;
> }
> }
> catch (SocketException e) {
> }
> }
> return null;
> }
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (ELY-645) Unable to remove elytron subsystem with defined properties-realm
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/ELY-645?page=com.atlassian.jira.plugin.sy... ]
Bartosz Baranowski commented on ELY-645:
----------------------------------------
Got it. Will do.
> Unable to remove elytron subsystem with defined properties-realm
> ----------------------------------------------------------------
>
> Key: ELY-645
> URL: https://issues.jboss.org/browse/ELY-645
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Bartosz Baranowski
> Assignee: Bartosz Baranowski
>
> When having elytron subsystem with only defined property-realm and calling remove on the subsystem, it fails due unsatisfied dependencies [1]. The subsystem is created from scratch with no dependencies outside of the subsystem => it shouldn't fail to remove.
> [1]
> [standalone@localhost:9990 /] /subsystem=elytron:remove
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies:
> Service elytron.security-properties was depended upon by service org.wildfly.security.security-realm.elytron-security
> Service elytron.core-service was depended upon by service org.wildfly.security.security-realm.elytron-security",
> "rolled-back" => true
> }
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JGRP-2102) bind_interface="eth0" and bind_addr="LINK_LOCAL" config are conflict
by 俐佳 张 (JIRA)
[ https://issues.jboss.org/browse/JGRP-2102?page=com.atlassian.jira.plugin.... ]
俐佳 张 updated JGRP-2102:
-----------------------
Description:
Error happens while
Caused by: org.infinispan.commons.CacheConfigurationException: ISPN000085: Error while trying to create a channel using the specified configuration file: /opt/oss/NSN-icf_notification_dispatcher/conf/jgroups-udp.xml
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:406)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannel(JGroupsTransport.java:307)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannelAndRPCDispatcher(JGroupsTransport.java:351)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:188)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:56)
at java.lang.reflect.Method.invoke(Method.java:620)
at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:226)
... 26 more
Caused by: java.lang.Exception: Property assignment of bind_interface in UDP with original property value eth0 and converted to null could not be assigned
at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1153)
at org.jgroups.stack.Configurator.createLayer(Configurator.java:444)
at org.jgroups.stack.Configurator.createProtocols(Configurator.java:398)
at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:90)
at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:57)
at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:477)
at org.jgroups.JChannel.init(JChannel.java:854)
at org.jgroups.JChannel.<init>(JChannel.java:159)
at org.jgroups.JChannel.<init>(JChannel.java:129)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:404)
... 39 more
Caused by: java.lang.Exception: Conversion of bind_interface in UDP with original property value eth0 failed
at org.jgroups.conf.PropertyHelper.getConvertedValue(PropertyHelper.java:84)
at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1147)
... 48 more
Caused by: java.lang.mail(a)example.comIllegalArgumentException: network interface eth0 does not contain address fe80:0:0:0:250:56ff:feab:d612%3
at org.jgroups.util.Util.validateBindAddressFromInterface(Util.java:3132)
bind_interface="eth0" and bind_addr="LINK_LOCAL" config are config at the same time
but it couldn't get the eth0 link local address but return eth1 link local address
This code return the first address that match, it should return with eth0
jgroups-3.6.1.Final-sources\org\jgroups\util\Util.java
public static InetAddress getAddress(AddressScope scope) ----> scope is LINK_LOCAL
throws SocketException
{
InetAddress address = null;
Enumeration intfs = NetworkInterface.getNetworkInterfaces();
while (intfs.hasMoreElements()) {
NetworkInterface intf = (NetworkInterface)intfs.nextElement();
try {
if (intf.isUp()) {
address = getAddress(intf, scope); -------> It will return the first LINK_LOCAL address from NICs list
if (address != null)
return address;
}
}
catch (SocketException e) {
}
}
return null;
}
was:
Error happens while
Caused by: org.infinispan.commons.CacheConfigurationException: ISPN000085: Error while trying to create a channel using the specified configuration file: /opt/oss/NSN-icf_notification_dispatcher/conf/jgroups-udp.xml
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:406)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannel(JGroupsTransport.java:307)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannelAndRPCDispatcher(JGroupsTransport.java:351)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:188)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:56)
at java.lang.reflect.Method.invoke(Method.java:620)
at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:226)
... 26 more
Caused by: java.lang.Exception: Property assignment of bind_interface in UDP with original property value eth0 and converted to null could not be assigned
at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1153)
at org.jgroups.stack.Configurator.createLayer(Configurator.java:444)
at org.jgroups.stack.Configurator.createProtocols(Configurator.java:398)
at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:90)
at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:57)
at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:477)
at org.jgroups.JChannel.init(JChannel.java:854)
at org.jgroups.JChannel.<init>(JChannel.java:159)
at org.jgroups.JChannel.<init>(JChannel.java:129)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:404)
... 39 more
Caused by: java.lang.Exception: Conversion of bind_interface in UDP with original property value eth0 failed
at org.jgroups.conf.PropertyHelper.getConvertedValue(PropertyHelper.java:84)
at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1147)
... 48 more
Caused by: java.lang.mail(a)example.comIllegalArgumentException: network interface eth0 does not contain address fe80:0:0:0:250:56ff:feab:d612%3
at org.jgroups.util.Util.validateBindAddressFromInterface(Util.java:3132)
bind_interface="eth0" and bind_addr="LINK_LOCAL" config are config at the same time
but it couldn't get the eth0 link local address but return eth1 link local address
This code return the first address that match
jgroups-3.6.1.Final-sources\org\jgroups\util\Util.java
public static InetAddress getAddress(AddressScope scope) ----> scope is LINK_LOCAL
throws SocketException
{
InetAddress address = null;
Enumeration intfs = NetworkInterface.getNetworkInterfaces();
while (intfs.hasMoreElements()) {
NetworkInterface intf = (NetworkInterface)intfs.nextElement();
try {
if (intf.isUp()) {
address = getAddress(intf, scope); -------> It will return the first LINK_LOCAL address from NICs list
if (address != null)
return address;
}
}
catch (SocketException e) {
}
}
return null;
}
> bind_interface="eth0" and bind_addr="LINK_LOCAL" config are conflict
> --------------------------------------------------------------------
>
> Key: JGRP-2102
> URL: https://issues.jboss.org/browse/JGRP-2102
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.1
> Environment: [root@wtc2k01v27 ~] CLONE # ip a
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> inet6 2606:ae00:e200:3f::83/128 scope global
> valid_lft forever preferred_lft forever
> inet6 ::1/128 scope host
> valid_lft forever preferred_lft forever
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
> link/ether 00:50:56:ab:2a:ea brd ff:ff:ff:ff:ff:ff
> inet 107.250.167.28/25 brd 107.250.167.127 scope global eth0
> inet6 2606:ae00:e200:3f::28/64 scope global
> valid_lft forever preferred_lft forever
> inet6 fe80::250:56ff:feab:2aea/64 scope link
> valid_lft forever preferred_lft forever
> 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
> link/ether 00:50:56:ab:d6:12 brd ff:ff:ff:ff:ff:ff
> inet 192.168.0.59/24 brd 192.168.0.255 scope global eth1
> inet6 fe80::250:56ff:feab:d612/64 scope link
> valid_lft forever preferred_lft forever
> There're eth0 and eth1 exists in the environment
> Reporter: 俐佳 张
> Assignee: Bela Ban
> Attachments: jgroups-udp.xml
>
>
> Error happens while
> Caused by: org.infinispan.commons.CacheConfigurationException: ISPN000085: Error while trying to create a channel using the specified configuration file: /opt/oss/NSN-icf_notification_dispatcher/conf/jgroups-udp.xml
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:406)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannel(JGroupsTransport.java:307)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannelAndRPCDispatcher(JGroupsTransport.java:351)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:188)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:56)
> at java.lang.reflect.Method.invoke(Method.java:620)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
> at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:226)
> ... 26 more
> Caused by: java.lang.Exception: Property assignment of bind_interface in UDP with original property value eth0 and converted to null could not be assigned
> at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1153)
> at org.jgroups.stack.Configurator.createLayer(Configurator.java:444)
> at org.jgroups.stack.Configurator.createProtocols(Configurator.java:398)
> at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:90)
> at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:57)
> at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:477)
> at org.jgroups.JChannel.init(JChannel.java:854)
> at org.jgroups.JChannel.<init>(JChannel.java:159)
> at org.jgroups.JChannel.<init>(JChannel.java:129)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:404)
> ... 39 more
> Caused by: java.lang.Exception: Conversion of bind_interface in UDP with original property value eth0 failed
> at org.jgroups.conf.PropertyHelper.getConvertedValue(PropertyHelper.java:84)
> at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1147)
> ... 48 more
> Caused by: java.lang.mail(a)example.comIllegalArgumentException: network interface eth0 does not contain address fe80:0:0:0:250:56ff:feab:d612%3
> at org.jgroups.util.Util.validateBindAddressFromInterface(Util.java:3132)
> bind_interface="eth0" and bind_addr="LINK_LOCAL" config are config at the same time
> but it couldn't get the eth0 link local address but return eth1 link local address
> This code return the first address that match, it should return with eth0
> jgroups-3.6.1.Final-sources\org\jgroups\util\Util.java
> public static InetAddress getAddress(AddressScope scope) ----> scope is LINK_LOCAL
> throws SocketException
> {
> InetAddress address = null;
> Enumeration intfs = NetworkInterface.getNetworkInterfaces();
> while (intfs.hasMoreElements()) {
> NetworkInterface intf = (NetworkInterface)intfs.nextElement();
> try {
> if (intf.isUp()) {
> address = getAddress(intf, scope); -------> It will return the first LINK_LOCAL address from NICs list
> if (address != null)
> return address;
> }
> }
> catch (SocketException e) {
> }
> }
> return null;
> }
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (ELY-645) Unable to remove elytron subsystem with defined properties-realm
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-645?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse commented on ELY-645:
--------------------------------------
Please just stick with the WFLY issue, the ELY project is for the core Elytron component not the subsystem. If you do want a subsystem issue one can be created in GitHub in the subsystem repository.
> Unable to remove elytron subsystem with defined properties-realm
> ----------------------------------------------------------------
>
> Key: ELY-645
> URL: https://issues.jboss.org/browse/ELY-645
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Bartosz Baranowski
> Assignee: Bartosz Baranowski
>
> When having elytron subsystem with only defined property-realm and calling remove on the subsystem, it fails due unsatisfied dependencies [1]. The subsystem is created from scratch with no dependencies outside of the subsystem => it shouldn't fail to remove.
> [1]
> [standalone@localhost:9990 /] /subsystem=elytron:remove
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies:
> Service elytron.security-properties was depended upon by service org.wildfly.security.security-realm.elytron-security
> Service elytron.core-service was depended upon by service org.wildfly.security.security-realm.elytron-security",
> "rolled-back" => true
> }
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (ELY-645) Unable to remove elytron subsystem with defined properties-realm
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/ELY-645?page=com.atlassian.jira.plugin.sy... ]
Bartosz Baranowski reassigned ELY-645:
--------------------------------------
Assignee: Bartosz Baranowski (was: Darran Lofthouse)
> Unable to remove elytron subsystem with defined properties-realm
> ----------------------------------------------------------------
>
> Key: ELY-645
> URL: https://issues.jboss.org/browse/ELY-645
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Bartosz Baranowski
> Assignee: Bartosz Baranowski
>
> When having elytron subsystem with only defined property-realm and calling remove on the subsystem, it fails due unsatisfied dependencies [1]. The subsystem is created from scratch with no dependencies outside of the subsystem => it shouldn't fail to remove.
> [1]
> [standalone@localhost:9990 /] /subsystem=elytron:remove
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies:
> Service elytron.security-properties was depended upon by service org.wildfly.security.security-realm.elytron-security
> Service elytron.core-service was depended upon by service org.wildfly.security.security-realm.elytron-security",
> "rolled-back" => true
> }
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (ELY-645) Unable to remove elytron subsystem with defined properties-realm
by Bartosz Baranowski (JIRA)
Bartosz Baranowski created ELY-645:
--------------------------------------
Summary: Unable to remove elytron subsystem with defined properties-realm
Key: ELY-645
URL: https://issues.jboss.org/browse/ELY-645
Project: WildFly Elytron
Issue Type: Bug
Reporter: Bartosz Baranowski
Assignee: Darran Lofthouse
When having elytron subsystem with only defined property-realm and calling remove on the subsystem, it fails due unsatisfied dependencies [1]. The subsystem is created from scratch with no dependencies outside of the subsystem => it shouldn't fail to remove.
[1]
[standalone@localhost:9990 /] /subsystem=elytron:remove
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies:
Service elytron.security-properties was depended upon by service org.wildfly.security.security-realm.elytron-security
Service elytron.core-service was depended upon by service org.wildfly.security.security-realm.elytron-security",
"rolled-back" => true
}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JGRP-2102) bind_interface="eth0" and bind_addr="LINK_LOCAL" config are conflict
by 俐佳 张 (JIRA)
俐佳 张 created JGRP-2102:
--------------------------
Summary: bind_interface="eth0" and bind_addr="LINK_LOCAL" config are conflict
Key: JGRP-2102
URL: https://issues.jboss.org/browse/JGRP-2102
Project: JGroups
Issue Type: Bug
Affects Versions: 3.6.1
Environment: [root@wtc2k01v27 ~] CLONE # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 2606:ae00:e200:3f::83/128 scope global
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether 00:50:56:ab:2a:ea brd ff:ff:ff:ff:ff:ff
inet 107.250.167.28/25 brd 107.250.167.127 scope global eth0
inet6 2606:ae00:e200:3f::28/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::250:56ff:feab:2aea/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether 00:50:56:ab:d6:12 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.59/24 brd 192.168.0.255 scope global eth1
inet6 fe80::250:56ff:feab:d612/64 scope link
valid_lft forever preferred_lft forever
There're eth0 and eth1 exists in the environment
Reporter: 俐佳 张
Assignee: Bela Ban
Attachments: jgroups-udp.xml
Error happens while
Caused by: org.infinispan.commons.CacheConfigurationException: ISPN000085: Error while trying to create a channel using the specified configuration file: /opt/oss/NSN-icf_notification_dispatcher/conf/jgroups-udp.xml
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:406)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannel(JGroupsTransport.java:307)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannelAndRPCDispatcher(JGroupsTransport.java:351)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:188)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:56)
at java.lang.reflect.Method.invoke(Method.java:620)
at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:226)
... 26 more
Caused by: java.lang.Exception: Property assignment of bind_interface in UDP with original property value eth0 and converted to null could not be assigned
at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1153)
at org.jgroups.stack.Configurator.createLayer(Configurator.java:444)
at org.jgroups.stack.Configurator.createProtocols(Configurator.java:398)
at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:90)
at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:57)
at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:477)
at org.jgroups.JChannel.init(JChannel.java:854)
at org.jgroups.JChannel.<init>(JChannel.java:159)
at org.jgroups.JChannel.<init>(JChannel.java:129)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:404)
... 39 more
Caused by: java.lang.Exception: Conversion of bind_interface in UDP with original property value eth0 failed
at org.jgroups.conf.PropertyHelper.getConvertedValue(PropertyHelper.java:84)
at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1147)
... 48 more
Caused by: java.lang.mail(a)example.comIllegalArgumentException: network interface eth0 does not contain address fe80:0:0:0:250:56ff:feab:d612%3
at org.jgroups.util.Util.validateBindAddressFromInterface(Util.java:3132)
bind_interface="eth0" and bind_addr="LINK_LOCAL" config are config at the same time
but it couldn't get the eth0 link local address but return eth1 link local address
This code return the first address that match
jgroups-3.6.1.Final-sources\org\jgroups\util\Util.java
public static InetAddress getAddress(AddressScope scope) ----> scope is LINK_LOCAL
throws SocketException
{
InetAddress address = null;
Enumeration intfs = NetworkInterface.getNetworkInterfaces();
while (intfs.hasMoreElements()) {
NetworkInterface intf = (NetworkInterface)intfs.nextElement();
try {
if (intf.isUp()) {
address = getAddress(intf, scope); -------> It will return the first LINK_LOCAL address from NICs list
if (address != null)
return address;
}
}
catch (SocketException e) {
}
}
return null;
}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7233) Add ExtendedJBossXATerminator service to the transactions subsystem
by Gytis Trikleris (JIRA)
Gytis Trikleris created WFLY-7233:
-------------------------------------
Summary: Add ExtendedJBossXATerminator service to the transactions subsystem
Key: WFLY-7233
URL: https://issues.jboss.org/browse/WFLY-7233
Project: WildFly
Issue Type: Enhancement
Components: Transactions
Reporter: Gytis Trikleris
Assignee: Gytis Trikleris
Fix For: 11.0.0.Alpha1
ExtendedJBossXATerminator from Narayana SPI is not currently injectable as a service. However, it is needed to check if the specific transaction is available in the server.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7212) Cannot use BMT in @Schedule service
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7212?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-7212:
--------------------------------------
The Schedule method is on a different bean, so it will start a transaction. The transaction will then time out and an exception will be thrown when it is commited. You need both beans to use BMT.
> Cannot use BMT in @Schedule service
> -----------------------------------
>
> Key: WFLY-7212
> URL: https://issues.jboss.org/browse/WFLY-7212
> Project: WildFly
> Issue Type: Feature Request
> Components: EE, EJB, Transactions
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Environment: Wildfly 10.1.0-Final. Windows 10. MySql 5.5.
> Reporter: Karl Nicholas
> Labels: arjuna, ejb, scheduled, scheduled_tasks, transaction
>
> When injecting a `@Resource private UserTransaction tx;`, a `TransactionReaper` terminates kills my `UserTransaction` after 5 minutes no matter what. Since it's a batch update, I need more than 5 minutes.
> Here is a simple piece of code that doesn't work:
> {code:java}
> @EJB private TestFiveMinuteBatch testFiveMinuteBatch;
> @Schedule(second="0", minute="8", hour="10", persistent=false) // 03:30 am (12:30 am CA ) every day
> public void updateTest() {
> testFiveMinuteBatch.test();
> }
> @Stateless
> @TransactionManagement(TransactionManagementType.BEAN)
> public class TestFiveMinuteBatch {
> @Resource private UserTransaction tx;
> public void test() {
> for ( int i=0; i < 6; ++i ) {
> System.out.println("Minute: " + i);
> try {
> Thread.sleep(60000);
> } catch (InterruptedException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
> }
> }
> }
> {code}
> After 5 minutes I get this warning:
> {noformat}
> 10:13:00,034 WARN [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffffac1f6209:-595568e4:57e80419:e in state RUN
> 10:13:00,039 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012121: TransactionReaper::doCancellations worker Thread[Transaction Reaper Worker 0,5,main] successfully canceled TX 0:ffffac1f6209:-595568e4:57e80419:e
> 10:13:00,130 INFO [stdout] (EJB default - 1) Minute: 5
> {noformat}
> After service terminates I get this error:
> {noformat}
> 10:14:00,131 WARN [com.arjuna.ats.arjuna] (EJB default - 1) ARJUNA012077: Abort called on already aborted atomic action 0:ffffac1f6209:-595568e4:57e80419:e
> 10:14:00,163 ERROR [org.jboss.as.ejb3.timer] (EJB default - 1) WFLYEJB0020: Error invoking timeout for timer: [id=8a8f4546-28d0-491e-85a6-f668f58ab5dc timedObjectId=opca-ear.opca-ejb.ScheduledService auto-timer?:true persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@31fe8c3e initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Mon Sep 26 10:08:00 PDT 2016 timerState=IN_TIMEOUT info=null]: javax.ejb.EJBTransactionRolledbackException: Transaction rolled back
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleEndTransactionException(CMTTxInterceptor.java:137)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:117)
> at org.jboss.as.ejb3.tx.TimerCMTTxInterceptor.endTransaction(TimerCMTTxInterceptor.java:67)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:279)
> 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.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:110)
> 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.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.ejb3.timerservice.TimedObjectInvokerImpl.callTimeout(TimedObjectInvokerImpl.java:99)
> at org.jboss.as.ejb3.timerservice.CalendarTimerTask.invokeBeanMethod(CalendarTimerTask.java:64)
> at org.jboss.as.ejb3.timerservice.CalendarTimerTask.callTimeout(CalendarTimerTask.java:53)
> at org.jboss.as.ejb3.timerservice.TimerTask.run(TimerTask.java:157)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl$Task$1.run(TimerServiceImpl.java:1215)
> at org.wildfly.extension.requestcontroller.RequestController$QueuedTask$1.run(RequestController.java:497)
> 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)
> Caused by: javax.transaction.RollbackException: WFLYEJB0447: Transaction 'TransactionImple < ac, BasicAction: 0:ffffac1f6209:-595568e4:57e80419:e status: ActionStatus.ABORTED >' was already rolled back
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:98)
> ... 38 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7209) Operation to list installed Resource Adapters
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/WFLY-7209?page=com.atlassian.jira.plugin.... ]
Stefano Maestri commented on WFLY-7209:
---------------------------------------
I'm not sure I'm following 100%. Resource adapters could be activate in 2 different way:
# w/ an entry in resource-adapters subsystem configuration
# w/ ironjacamar.xml file in the rar archive
in the first case you have all configuration and stats under its resource-adpater entry in DMR.
In the second case you have all readonly attribute and stats under /deployment=<rar-name>. For example this is a valid command :
/deployment=amq-ij.rar/subsystem=resource-adapters/ironjacamar=ironjacamar/resource-adapter=amq-ij.rar:read-resource()
If you are not in one of those 2 cases the rar is not activated and in fact it's just a library deployment until it will be activated w/ a valid configuration.
I don't understand what else you need, but maybe I'm not getting your use case. Could you explain a bit further?
S.
> Operation to list installed Resource Adapters
> ---------------------------------------------
>
> Key: WFLY-7209
> URL: https://issues.jboss.org/browse/WFLY-7209
> Project: WildFly
> Issue Type: Feature Request
> Components: JCA
> Reporter: Guillermo González de Agüero
> Assignee: Stefano Maestri
> Fix For: 10.1.0.Final
>
>
> Currently there's no way to list all the installed Resource Adapters. Only configured resource adapters can be queried. However, they are automatically enabled at deployment time.
> I propose to add a new operation to list installed RAs and their configuration, similar to the one available for JDBC drivers. This would allow HAL to provide a wizard of available options when configuring them.
> The command would be something like: /subsystem=resource-adapters:installed-resource-adapters-list()
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (DROOLS-1311) PDF asciidoc generation
by Geoffrey De Smet (JIRA)
Geoffrey De Smet created DROOLS-1311:
----------------------------------------
Summary: PDF asciidoc generation
Key: DROOLS-1311
URL: https://issues.jboss.org/browse/DROOLS-1311
Project: Drools
Issue Type: Feature Request
Components: docs
Reporter: Geoffrey De Smet
Assignee: Geoffrey De Smet
Using approach from optaplanner-docs in asciidoc
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7206) Graceful Shutdown and Quiescing for Transactions
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/WFLY-7206?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris closed WFLY-7206.
---------------------------------
Fix Version/s: (was: 11.0.0.Alpha1)
Resolution: Duplicate Issue
> Graceful Shutdown and Quiescing for Transactions
> ------------------------------------------------
>
> Key: WFLY-7206
> URL: https://issues.jboss.org/browse/WFLY-7206
> Project: WildFly
> Issue Type: Feature Request
> Components: Server, Transactions, Web Console, XTS
> Reporter: Gytis Trikleris
> Assignee: Gytis Trikleris
> Priority: Critical
>
> * During the quiesce period - the server component will not accept new requests.
> * Components of the server will support controlled shutdown or quiescence - ie. In-flight transactions and requests will be serviced before the shutdown.
> This also implies eing able to control all request paths - HTTP (via mod_cluster), JMS and RMI (via smart proxies).
> * The Quiesce operation will accept a timeout which will indicate the maximum period that a shutdown will wait for in-flight requests / transactions to complete. After the timeout expires the server component will shutdown immediately.
> * It applies to servers that are started with all supported server profiles (i.e. default, default-ha, full and full-ha) in both standalone and domain modes.
> * In a clustered environment if a node in cluster is on graceful shutdown, the other node(s) in the cluster should not log warnings, but infos (or debug or nothing) because this is a normal situation (Ref: PRODMGT-815)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-4937) Implement graceful shutdown for transactions
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/WFLY-4937?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris updated WFLY-4937:
----------------------------------
Component/s: XTS
> Implement graceful shutdown for transactions
> --------------------------------------------
>
> Key: WFLY-4937
> URL: https://issues.jboss.org/browse/WFLY-4937
> Project: WildFly
> Issue Type: Feature Request
> Components: Transactions, XTS
> Reporter: Michael Musgrove
> Assignee: Gytis Trikleris
> Priority: Critical
> Fix For: 11.0.0.Alpha1
>
>
> This feature will allow EAP supported transaction services to react to suspend and resume requests. The supported services are JTA, JTS, WS-AT, and WS-BA.
> After suspend, all the services remain functional. All external requests bound to the existing transactions are allowed in. All external requests requiring new transaction are blocked. All remote transaction management requests, except begin, are allowed in.
> After resume, all requests are allowed in.
> After suspend timeout, all services must shutdown.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-4937) Implement graceful shutdown for transactions
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/WFLY-4937?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris updated WFLY-4937:
----------------------------------
Affects Version/s: (was: 11.0.0.Alpha1)
> Implement graceful shutdown for transactions
> --------------------------------------------
>
> Key: WFLY-4937
> URL: https://issues.jboss.org/browse/WFLY-4937
> Project: WildFly
> Issue Type: Feature Request
> Components: Transactions
> Reporter: Michael Musgrove
> Assignee: Gytis Trikleris
> Priority: Critical
> Fix For: 11.0.0.Alpha1
>
>
> This feature will allow EAP supported transaction services to react to suspend and resume requests. The supported services are JTA, JTS, WS-AT, and WS-BA.
> After suspend, all the services remain functional. All external requests bound to the existing transactions are allowed in. All external requests requiring new transaction are blocked. All remote transaction management requests, except begin, are allowed in.
> After resume, all requests are allowed in.
> After suspend timeout, all services must shutdown.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-4937) Implement graceful shutdown for transactions
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/WFLY-4937?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris updated WFLY-4937:
----------------------------------
Fix Version/s: 11.0.0.Alpha1
(was: 11.0.0.CR1)
> Implement graceful shutdown for transactions
> --------------------------------------------
>
> Key: WFLY-4937
> URL: https://issues.jboss.org/browse/WFLY-4937
> Project: WildFly
> Issue Type: Feature Request
> Components: Transactions
> Reporter: Michael Musgrove
> Assignee: Gytis Trikleris
> Priority: Critical
> Fix For: 11.0.0.Alpha1
>
>
> This feature will allow EAP supported transaction services to react to suspend and resume requests. The supported services are JTA, JTS, WS-AT, and WS-BA.
> After suspend, all the services remain functional. All external requests bound to the existing transactions are allowed in. All external requests requiring new transaction are blocked. All remote transaction management requests, except begin, are allowed in.
> After resume, all requests are allowed in.
> After suspend timeout, all services must shutdown.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-4937) Implement graceful shutdown for transactions
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/WFLY-4937?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris updated WFLY-4937:
----------------------------------
Priority: Critical (was: Major)
> Implement graceful shutdown for transactions
> --------------------------------------------
>
> Key: WFLY-4937
> URL: https://issues.jboss.org/browse/WFLY-4937
> Project: WildFly
> Issue Type: Feature Request
> Components: Transactions
> Reporter: Michael Musgrove
> Assignee: Gytis Trikleris
> Priority: Critical
> Fix For: 11.0.0.Alpha1
>
>
> This feature will allow EAP supported transaction services to react to suspend and resume requests. The supported services are JTA, JTS, WS-AT, and WS-BA.
> After suspend, all the services remain functional. All external requests bound to the existing transactions are allowed in. All external requests requiring new transaction are blocked. All remote transaction management requests, except begin, are allowed in.
> After resume, all requests are allowed in.
> After suspend timeout, all services must shutdown.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-4937) Implement graceful shutdown for transactions
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/WFLY-4937?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris updated WFLY-4937:
----------------------------------
Affects Version/s: 11.0.0.Alpha1
(was: 10.0.0.Alpha5)
> Implement graceful shutdown for transactions
> --------------------------------------------
>
> Key: WFLY-4937
> URL: https://issues.jboss.org/browse/WFLY-4937
> Project: WildFly
> Issue Type: Feature Request
> Components: Transactions
> Reporter: Michael Musgrove
> Assignee: Gytis Trikleris
> Fix For: 11.0.0.Alpha1
>
>
> This feature will allow EAP supported transaction services to react to suspend and resume requests. The supported services are JTA, JTS, WS-AT, and WS-BA.
> After suspend, all the services remain functional. All external requests bound to the existing transactions are allowed in. All external requests requiring new transaction are blocked. All remote transaction management requests, except begin, are allowed in.
> After resume, all requests are allowed in.
> After suspend timeout, all services must shutdown.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-4937) Implement graceful shutdown for transactions
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/WFLY-4937?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris updated WFLY-4937:
----------------------------------
Description:
This feature will allow EAP supported transaction services to react to suspend and resume requests. The supported services are JTA, JTS, WS-AT, and WS-BA.
After suspend, all the services remain functional. All external requests bound to the existing transactions are allowed in. All external requests requiring new transaction are blocked. All remote transaction management requests, except begin, are allowed in.
After resume, all requests are allowed in.
After suspend timeout, all services must shutdown.
was:
We will handle suspend for JTA and JTS by disallowing new transactions and then block the suspend thread until the count of active transactions drops to zero. We will also suspend the recovery manager.
We will *not* do graceful shutdown for the optional XTS subsystem. For example an incoming XTS request for an existing transaction will be blocked.
Question: should we
- raise a new JIRA for this XTS case;
- document the deficiency and see if there are complaints;
- document the deficiency and fix it in a subsequent release
> Implement graceful shutdown for transactions
> --------------------------------------------
>
> Key: WFLY-4937
> URL: https://issues.jboss.org/browse/WFLY-4937
> Project: WildFly
> Issue Type: Feature Request
> Components: Transactions
> Affects Versions: 10.0.0.Alpha5
> Reporter: Michael Musgrove
> Assignee: Gytis Trikleris
> Fix For: 11.0.0.CR1
>
>
> This feature will allow EAP supported transaction services to react to suspend and resume requests. The supported services are JTA, JTS, WS-AT, and WS-BA.
> After suspend, all the services remain functional. All external requests bound to the existing transactions are allowed in. All external requests requiring new transaction are blocked. All remote transaction management requests, except begin, are allowed in.
> After resume, all requests are allowed in.
> After suspend timeout, all services must shutdown.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7229) WFLYCLWEBUT0001 for server-side invalidated sessions
by Michał Nowakowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-7229?page=com.atlassian.jira.plugin.... ]
Michał Nowakowski updated WFLY-7229:
------------------------------------
Description:
Attached is a simple webapp (pardon the name) with a single servlet "/main", that does the following:
- a session is assigned (or created, if none existed before)
- its details are printed and the browser is told to refresh after 20 seconds
- before the browser refreshes, the session is invalidated server-side by separate thread.
Expected behaviour is, that WF should give the user a new session. That's indeed how it works in standalone mode and without <distributable/> in web.xml. But in domain mode, OR with <distributable/> added (and, possibly, full-ha profile chosen), I get errors:
- The first stacktrace happens when the thread invalidates the session.
- The second stacktrace happens, when the browser refreshes. The user sees "Error 500".
- Then, after a minute or so, I get the last one. It then repeats periodically.
We can't upgrade from 10.0 because of this - and we know we need an upgrade because of fixes in Infinispan.
was:
Attached is a simple webapp (pardon the name) with a single servlet "/main", that does the following:
- a session is assigned (or created, if none existed before)
- its details are printed and the browser is told to refresh after 20 seconds
- before the browser refreshes, the session is invalidated server-side by separate thread.
Expected behaviour is, that WF should give the user a new session. That's indeed how it works in standalone mode and without <distributable/> in web.xml. But in domain mode, OR with <distributable/> added (and, possibly, full-ha profile chosen), I get errors:
- The first stacktrace happens when the thread invalidates the session.
- The second stacktrace happens, when the browser refreshes. The user sees "Error 500".
- The, after a minute or so, I get the last one. It then repeats periodically.
We can't upgrade from 10.0 because of this - and we know we need an upgrade because of fixes in Infinispan.
> WFLYCLWEBUT0001 for server-side invalidated sessions
> ----------------------------------------------------
>
> Key: WFLY-7229
> URL: https://issues.jboss.org/browse/WFLY-7229
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.1.0.Final
> Environment: Happens whenever <distributable/> is used in web.xml, both in standalone and domain modes.
> Reporter: Michał Nowakowski
> Assignee: Stuart Douglas
> Attachments: stacktrace_01.txt, stacktrace_02.txt, stacktrace_03.txt, testPortlet.tar.gz
>
>
> Attached is a simple webapp (pardon the name) with a single servlet "/main", that does the following:
> - a session is assigned (or created, if none existed before)
> - its details are printed and the browser is told to refresh after 20 seconds
> - before the browser refreshes, the session is invalidated server-side by separate thread.
> Expected behaviour is, that WF should give the user a new session. That's indeed how it works in standalone mode and without <distributable/> in web.xml. But in domain mode, OR with <distributable/> added (and, possibly, full-ha profile chosen), I get errors:
> - The first stacktrace happens when the thread invalidates the session.
> - The second stacktrace happens, when the browser refreshes. The user sees "Error 500".
> - Then, after a minute or so, I get the last one. It then repeats periodically.
> We can't upgrade from 10.0 because of this - and we know we need an upgrade because of fixes in Infinispan.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7229) WFLYCLWEBUT0001 for server-side invalidated sessions
by Michał Nowakowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-7229?page=com.atlassian.jira.plugin.... ]
Michał Nowakowski updated WFLY-7229:
------------------------------------
Issue Type: Bug (was: Feature Request)
> WFLYCLWEBUT0001 for server-side invalidated sessions
> ----------------------------------------------------
>
> Key: WFLY-7229
> URL: https://issues.jboss.org/browse/WFLY-7229
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.1.0.Final
> Environment: Happens whenever <distributable/> is used in web.xml, both in standalone and domain modes.
> Reporter: Michał Nowakowski
> Assignee: Stuart Douglas
> Attachments: stacktrace_01.txt, stacktrace_02.txt, stacktrace_03.txt, testPortlet.tar.gz
>
>
> Attached is a simple webapp (pardon the name) with a single servlet "/main", that does the following:
> - a session is assigned (or created, if none existed before)
> - its details are printed and the browser is told to refresh after 20 seconds
> - before the browser refreshes, the session is invalidated server-side by separate thread.
> Expected behaviour is, that WF should give the user a new session. That's indeed how it works in standalone mode and without <distributable/> in web.xml. But in domain mode, OR with <distributable/> added (and, possibly, full-ha profile chosen), I get errors:
> - The first stacktrace happens when the thread invalidates the session.
> - The second stacktrace happens, when the browser refreshes. The user sees "Error 500".
> - The, after a minute or so, I get the last one. It then repeats periodically.
> We can't upgrade from 10.0 because of this - and we know we need an upgrade because of fixes in Infinispan.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7229) WFLYCLWEBUT0001 for server-side invalidated sessions
by Michał Nowakowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-7229?page=com.atlassian.jira.plugin.... ]
Michał Nowakowski commented on WFLY-7229:
-----------------------------------------
My mistake. Of course, this is a bug report.
> WFLYCLWEBUT0001 for server-side invalidated sessions
> ----------------------------------------------------
>
> Key: WFLY-7229
> URL: https://issues.jboss.org/browse/WFLY-7229
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.1.0.Final
> Environment: Happens whenever <distributable/> is used in web.xml, both in standalone and domain modes.
> Reporter: Michał Nowakowski
> Assignee: Stuart Douglas
> Attachments: stacktrace_01.txt, stacktrace_02.txt, stacktrace_03.txt, testPortlet.tar.gz
>
>
> Attached is a simple webapp (pardon the name) with a single servlet "/main", that does the following:
> - a session is assigned (or created, if none existed before)
> - its details are printed and the browser is told to refresh after 20 seconds
> - before the browser refreshes, the session is invalidated server-side by separate thread.
> Expected behaviour is, that WF should give the user a new session. That's indeed how it works in standalone mode and without <distributable/> in web.xml. But in domain mode, OR with <distributable/> added (and, possibly, full-ha profile chosen), I get errors:
> - The first stacktrace happens when the thread invalidates the session.
> - The second stacktrace happens, when the browser refreshes. The user sees "Error 500".
> - The, after a minute or so, I get the last one. It then repeats periodically.
> We can't upgrade from 10.0 because of this - and we know we need an upgrade because of fixes in Infinispan.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7232) Add support for Elytron provided SSLContexts in Artemis
by Stefan Guilhen (JIRA)
Stefan Guilhen created WFLY-7232:
------------------------------------
Summary: Add support for Elytron provided SSLContexts in Artemis
Key: WFLY-7232
URL: https://issues.jboss.org/browse/WFLY-7232
Project: WildFly
Issue Type: Feature Request
Components: JMS
Reporter: Stefan Guilhen
Assignee: Jeff Mesnil
SSL in messaging is handled by Artemis and it is enabled by a set of properties inserted into the acceptor/connector configuration. Ideally we should be able to change Artemis so that it would obtain an SSLContext that is ready to use from Elytron instead of relying on a set of properties to set up an SSLContext itself. This would help keep all SSL related configuration centralized in the Elytron subsystem and should simplify the configuration for SSL.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7231) Add support for an Elytron based ActiveMQSecurityManager implementation
by Stefan Guilhen (JIRA)
Stefan Guilhen created WFLY-7231:
------------------------------------
Summary: Add support for an Elytron based ActiveMQSecurityManager implementation
Key: WFLY-7231
URL: https://issues.jboss.org/browse/WFLY-7231
Project: WildFly
Issue Type: Feature Request
Components: JMS
Reporter: Stefan Guilhen
Assignee: Jeff Mesnil
This RFE covers the Elytron integration with the messaging-activemq subsystem. The most direct way to achieve this would be through a new ActiveMQSecurityManager implementation that uses an Elytron SecurityDomain to authenticate and authorize users. The new implementation would be installed whenever Elytron is enabled for the subsystem, which can be done by adding a new attribute that references an Elytron SecurityDomain in the server security settings.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7224) Missing validation check for simple-regex-realm-mapper and mapped-regex-realm-mapper in Elytron subsystem
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/WFLY-7224?page=com.atlassian.jira.plugin.... ]
Ilia Vassilev commented on WFLY-7224:
-------------------------------------
Hi [~honza889]. I'm proposing the following fix [1] for this issue. Please check if the fix is correct and let me know what needs to be modified in order to complete it and submit PR. This change will also resolve https://issues.jboss.org/browse/WFLY-7225.
[1] https://github.com/ivassile/elytron-subsystem/commit/798829eec0a636b0e6e8...
> Missing validation check for simple-regex-realm-mapper and mapped-regex-realm-mapper in Elytron subsystem
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7224
> URL: https://issues.jboss.org/browse/WFLY-7224
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
>
> Elytron subsystem allows to add realm mapper (e.g. simple-regex-realm-mapper) with pattern which does not include a capture group. In case when this realm mapper is used in add operation for security domain through CLI then operation fails with incomprehensible log:
> {code}
> {
> "outcome" => "failed",
> "failure-description" => {"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined},
> "rolled-back" => true
> }
> {code}
> Exception in server log:
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.security.realm-mapper.SomeRealmMapper: org.jboss.msc.service.StartException in service org.wildfly.security.realm-mapper.SomeRealmMapper: 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.IllegalArgumentException: ELY01065: Pattern requires a capture group
> at org.wildfly.security.auth.util.SimpleRegexRealmMapper.<init>(SimpleRegexRealmMapper.java:64)
> at org.wildfly.security.auth.util.SimpleRegexRealmMapper.<init>(SimpleRegexRealmMapper.java:49)
> at org.wildfly.extension.elytron.RealmMapperDefinitions$SimpleRegexRealmMapperAddHandler.lambda$performRuntime$0(RealmMapperDefinitions.java:157)
> 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}
> The same happens for mapped-regex-realm-mapper.
> Point here is that we allow to successfully add wrong realm mapper (without capture group) but we check whether it is wrong later in security domain. This check should be done during adding wrong realm mapper to avoid following incomprehensible CLI log and exception in server log.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JASSIST-261) Issue with javassist on jdk 9b112
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-261?page=com.atlassian.jira.plugi... ]
Shigeru Chiba commented on JASSIST-261:
---------------------------------------
Did it work? Great!
Scott, shall we make a GA release? Now, the code is a java9-only branch. Since Java 9 is still EA, shall we also release a javassist for Java9 EA or merge the java9 branch into the master and release? Let me know your idea.
> Issue with javassist on jdk 9b112
> ---------------------------------
>
> Key: JASSIST-261
> URL: https://issues.jboss.org/browse/JASSIST-261
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.20.0-GA
> Environment: Javassist with jdk 9b112
> Reporter: Hoang Chuong Tran
> Assignee: Shigeru Chiba
>
> I am migrating a project to java 9, which also uses javassist to generate runtime code.
> One test of mine fails on jdk 9b112 while it passes on jdk 8u77.
> {noformat}
> import static javassist.CtClass.voidType;
> import java.lang.reflect.Method;
> import java.lang.reflect.Modifier;
> import java.util.HashMap;
> import java.util.Map;
> import org.junit.Test;
> import javassist.ClassClassPath;
> import javassist.ClassPool;
> import javassist.CtClass;
> import javassist.CtField;
> import javassist.CtMethod;
> import javassist.CtNewMethod;
> public class MyTests {
> public static class MyObject {
> protected Object field;
> Object getField() {return field;}
> public void setField(Object field) {}
> }
> @Test
> public void test() throws InstantiationException, IllegalAccessException {
> Class<? extends MyObject> clazz = compile(MyObject.class);
> clazz.newInstance().setField(null);
> }
> /** Compile a transfer class */
> public static synchronized Class<? extends MyObject> compile(Class<?> targetClass) {
> // Determine class setters
> Map<String, Method> setters = extractSetters(targetClass);
> ClassPool classPool = ClassPool.getDefault();
> classPool.insertClassPath(new ClassClassPath(targetClass));
> try {
> // Compile a new transfer class on the fly
> CtClass baseClass = classPool.get(MyObject.class.getName());
> CtClass proxyClass = classPool.makeClass(targetClass.getName() + "_Modified", baseClass);
> for(Method originalSetter : setters.values()) {
> // Create a field to hold the attribute
> Class<?> fieldClass = originalSetter.getParameterTypes()[0];
> CtClass fieldType = classPool.get(fieldClass.getName());
> String fieldName = originalSetter.getName().substring(3);
> CtField field = new CtField(fieldType, fieldName, proxyClass);
> proxyClass.addField(field);
> // Create a setter method to set that field
> CtClass[] parameters = new CtClass[] { fieldType };
> String setterBody = "{ System.out.println(\"Hello World\"); }";
> CtMethod setter = CtNewMethod.make(voidType, originalSetter.getName(), parameters, new CtClass[0], setterBody, proxyClass);
> proxyClass.addMethod(setter);
> }
> Class<? extends MyObject> javaClass = proxyClass.toClass(targetClass.getClassLoader(), targetClass.getProtectionDomain());
> return javaClass;
> } catch(Exception e) {
> throw new RuntimeException("Failure during transfer compilation for " + targetClass, e);
> }
> }
> /** Extract setter methods from a class */
> public static Map<String, Method> extractSetters(Class<?> cls) {
> Map<String, Method> setters = new HashMap<String, Method>();
> for(Method method : cls.getMethods()) {
> // Lookup setter methods
> if(method.getName().startsWith("set")) {
> // Only public setters
> int modifiers = method.getModifiers();
> if(Modifier.isPublic(modifiers)) {
> Class<?>[] exceptions = method.getExceptionTypes();
> Class<?>[] parameters = method.getParameterTypes();
> Class<?> returnType = method.getReturnType();
> if(exceptions.length <= 0 && parameters.length == 1 && "void".equals(returnType.getName())) {
> setters.put(method.getName(), method);
> }
> }
> }
> }
> return setters;
> }
> }
> {noformat}
> On jdk 8u77, the {{compile()}} function returns with success and "Hello world" is printed to the console.
> On jdk 9b112, I got the following exception
> {noformat}
> java.lang.RuntimeException: Failure during transfer compilation for class MyTests$MyObject
> at MyTests.compile(MyTests.java:68)
> at MyTests.test(MyTests.java:29)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:670)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: javassist.NotFoundException: java.lang.Object
> at javassist.ClassPool.get(ClassPool.java:450)
> at MyTests.compile(MyTests.java:51)
> ... 24 more
> {noformat}
> I suspect that is due to the jigsaw integration into the jdk.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JASSIST-261) Issue with javassist on jdk 9b112
by Steve Ebersole (JIRA)
[ https://issues.jboss.org/browse/JASSIST-261?page=com.atlassian.jira.plugi... ]
Steve Ebersole commented on JASSIST-261:
----------------------------------------
https://hibernate.atlassian.net/browse/HHH-11138
> Issue with javassist on jdk 9b112
> ---------------------------------
>
> Key: JASSIST-261
> URL: https://issues.jboss.org/browse/JASSIST-261
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.20.0-GA
> Environment: Javassist with jdk 9b112
> Reporter: Hoang Chuong Tran
> Assignee: Shigeru Chiba
>
> I am migrating a project to java 9, which also uses javassist to generate runtime code.
> One test of mine fails on jdk 9b112 while it passes on jdk 8u77.
> {noformat}
> import static javassist.CtClass.voidType;
> import java.lang.reflect.Method;
> import java.lang.reflect.Modifier;
> import java.util.HashMap;
> import java.util.Map;
> import org.junit.Test;
> import javassist.ClassClassPath;
> import javassist.ClassPool;
> import javassist.CtClass;
> import javassist.CtField;
> import javassist.CtMethod;
> import javassist.CtNewMethod;
> public class MyTests {
> public static class MyObject {
> protected Object field;
> Object getField() {return field;}
> public void setField(Object field) {}
> }
> @Test
> public void test() throws InstantiationException, IllegalAccessException {
> Class<? extends MyObject> clazz = compile(MyObject.class);
> clazz.newInstance().setField(null);
> }
> /** Compile a transfer class */
> public static synchronized Class<? extends MyObject> compile(Class<?> targetClass) {
> // Determine class setters
> Map<String, Method> setters = extractSetters(targetClass);
> ClassPool classPool = ClassPool.getDefault();
> classPool.insertClassPath(new ClassClassPath(targetClass));
> try {
> // Compile a new transfer class on the fly
> CtClass baseClass = classPool.get(MyObject.class.getName());
> CtClass proxyClass = classPool.makeClass(targetClass.getName() + "_Modified", baseClass);
> for(Method originalSetter : setters.values()) {
> // Create a field to hold the attribute
> Class<?> fieldClass = originalSetter.getParameterTypes()[0];
> CtClass fieldType = classPool.get(fieldClass.getName());
> String fieldName = originalSetter.getName().substring(3);
> CtField field = new CtField(fieldType, fieldName, proxyClass);
> proxyClass.addField(field);
> // Create a setter method to set that field
> CtClass[] parameters = new CtClass[] { fieldType };
> String setterBody = "{ System.out.println(\"Hello World\"); }";
> CtMethod setter = CtNewMethod.make(voidType, originalSetter.getName(), parameters, new CtClass[0], setterBody, proxyClass);
> proxyClass.addMethod(setter);
> }
> Class<? extends MyObject> javaClass = proxyClass.toClass(targetClass.getClassLoader(), targetClass.getProtectionDomain());
> return javaClass;
> } catch(Exception e) {
> throw new RuntimeException("Failure during transfer compilation for " + targetClass, e);
> }
> }
> /** Extract setter methods from a class */
> public static Map<String, Method> extractSetters(Class<?> cls) {
> Map<String, Method> setters = new HashMap<String, Method>();
> for(Method method : cls.getMethods()) {
> // Lookup setter methods
> if(method.getName().startsWith("set")) {
> // Only public setters
> int modifiers = method.getModifiers();
> if(Modifier.isPublic(modifiers)) {
> Class<?>[] exceptions = method.getExceptionTypes();
> Class<?>[] parameters = method.getParameterTypes();
> Class<?> returnType = method.getReturnType();
> if(exceptions.length <= 0 && parameters.length == 1 && "void".equals(returnType.getName())) {
> setters.put(method.getName(), method);
> }
> }
> }
> }
> return setters;
> }
> }
> {noformat}
> On jdk 8u77, the {{compile()}} function returns with success and "Hello world" is printed to the console.
> On jdk 9b112, I got the following exception
> {noformat}
> java.lang.RuntimeException: Failure during transfer compilation for class MyTests$MyObject
> at MyTests.compile(MyTests.java:68)
> at MyTests.test(MyTests.java:29)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:670)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: javassist.NotFoundException: java.lang.Object
> at javassist.ClassPool.get(ClassPool.java:450)
> at MyTests.compile(MyTests.java:51)
> ... 24 more
> {noformat}
> I suspect that is due to the jigsaw integration into the jdk.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JASSIST-261) Issue with javassist on jdk 9b112
by Steve Ebersole (JIRA)
[ https://issues.jboss.org/browse/JASSIST-261?page=com.atlassian.jira.plugi... ]
Steve Ebersole commented on JASSIST-261:
----------------------------------------
I was able to use that snapshot[1] and run these tests successfully now for Hibernate's tests
[1] {{Download http://repository.jboss.org/nexus/content/groups/public/org/javassist/jav...
> Issue with javassist on jdk 9b112
> ---------------------------------
>
> Key: JASSIST-261
> URL: https://issues.jboss.org/browse/JASSIST-261
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.20.0-GA
> Environment: Javassist with jdk 9b112
> Reporter: Hoang Chuong Tran
> Assignee: Shigeru Chiba
>
> I am migrating a project to java 9, which also uses javassist to generate runtime code.
> One test of mine fails on jdk 9b112 while it passes on jdk 8u77.
> {noformat}
> import static javassist.CtClass.voidType;
> import java.lang.reflect.Method;
> import java.lang.reflect.Modifier;
> import java.util.HashMap;
> import java.util.Map;
> import org.junit.Test;
> import javassist.ClassClassPath;
> import javassist.ClassPool;
> import javassist.CtClass;
> import javassist.CtField;
> import javassist.CtMethod;
> import javassist.CtNewMethod;
> public class MyTests {
> public static class MyObject {
> protected Object field;
> Object getField() {return field;}
> public void setField(Object field) {}
> }
> @Test
> public void test() throws InstantiationException, IllegalAccessException {
> Class<? extends MyObject> clazz = compile(MyObject.class);
> clazz.newInstance().setField(null);
> }
> /** Compile a transfer class */
> public static synchronized Class<? extends MyObject> compile(Class<?> targetClass) {
> // Determine class setters
> Map<String, Method> setters = extractSetters(targetClass);
> ClassPool classPool = ClassPool.getDefault();
> classPool.insertClassPath(new ClassClassPath(targetClass));
> try {
> // Compile a new transfer class on the fly
> CtClass baseClass = classPool.get(MyObject.class.getName());
> CtClass proxyClass = classPool.makeClass(targetClass.getName() + "_Modified", baseClass);
> for(Method originalSetter : setters.values()) {
> // Create a field to hold the attribute
> Class<?> fieldClass = originalSetter.getParameterTypes()[0];
> CtClass fieldType = classPool.get(fieldClass.getName());
> String fieldName = originalSetter.getName().substring(3);
> CtField field = new CtField(fieldType, fieldName, proxyClass);
> proxyClass.addField(field);
> // Create a setter method to set that field
> CtClass[] parameters = new CtClass[] { fieldType };
> String setterBody = "{ System.out.println(\"Hello World\"); }";
> CtMethod setter = CtNewMethod.make(voidType, originalSetter.getName(), parameters, new CtClass[0], setterBody, proxyClass);
> proxyClass.addMethod(setter);
> }
> Class<? extends MyObject> javaClass = proxyClass.toClass(targetClass.getClassLoader(), targetClass.getProtectionDomain());
> return javaClass;
> } catch(Exception e) {
> throw new RuntimeException("Failure during transfer compilation for " + targetClass, e);
> }
> }
> /** Extract setter methods from a class */
> public static Map<String, Method> extractSetters(Class<?> cls) {
> Map<String, Method> setters = new HashMap<String, Method>();
> for(Method method : cls.getMethods()) {
> // Lookup setter methods
> if(method.getName().startsWith("set")) {
> // Only public setters
> int modifiers = method.getModifiers();
> if(Modifier.isPublic(modifiers)) {
> Class<?>[] exceptions = method.getExceptionTypes();
> Class<?>[] parameters = method.getParameterTypes();
> Class<?> returnType = method.getReturnType();
> if(exceptions.length <= 0 && parameters.length == 1 && "void".equals(returnType.getName())) {
> setters.put(method.getName(), method);
> }
> }
> }
> }
> return setters;
> }
> }
> {noformat}
> On jdk 8u77, the {{compile()}} function returns with success and "Hello world" is printed to the console.
> On jdk 9b112, I got the following exception
> {noformat}
> java.lang.RuntimeException: Failure during transfer compilation for class MyTests$MyObject
> at MyTests.compile(MyTests.java:68)
> at MyTests.test(MyTests.java:29)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:670)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: javassist.NotFoundException: java.lang.Object
> at javassist.ClassPool.get(ClassPool.java:450)
> at MyTests.compile(MyTests.java:51)
> ... 24 more
> {noformat}
> I suspect that is due to the jigsaw integration into the jdk.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1836) Rejection-style transformer tests assume each operation generated by parser has distinct PathAddress
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1836?page=com.atlassian.jira.plugi... ]
Kabir Khan moved WFLY-6766 to WFCORE-1836:
------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-1836 (was: WFLY-6766)
Component/s: Test Suite
(was: Test Suite)
Affects Version/s: (was: 10.0.0.Final)
> Rejection-style transformer tests assume each operation generated by parser has distinct PathAddress
> ----------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1836
> URL: https://issues.jboss.org/browse/WFCORE-1836
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Reporter: Paul Ferraro
> Assignee: Kabir Khan
>
> For rejection-style transformer tests, the subsystem test framework stores expected rejected operations in a map keyed by PathAddress. This is fine when the subsystem's parser only generates add operations. However, if the parser generates an add operation as well as a a write-attribute operation, these 2 operations will have the same path address. If we expect one of these operations to be rejected, but not the other, we end up with an unexpected rejection - and the test fails.
> This is a little hard to explain in the abstract, so let me know if any of the above doesn't make sense.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1836) Rejection-style transformer tests assume each operation generated by parser has distinct PathAddress
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1836?page=com.atlassian.jira.plugi... ]
Kabir Khan reassigned WFCORE-1836:
----------------------------------
Assignee: Brian Stansberry (was: Kabir Khan)
> Rejection-style transformer tests assume each operation generated by parser has distinct PathAddress
> ----------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1836
> URL: https://issues.jboss.org/browse/WFCORE-1836
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Reporter: Paul Ferraro
> Assignee: Brian Stansberry
>
> For rejection-style transformer tests, the subsystem test framework stores expected rejected operations in a map keyed by PathAddress. This is fine when the subsystem's parser only generates add operations. However, if the parser generates an add operation as well as a a write-attribute operation, these 2 operations will have the same path address. If we expect one of these operations to be rejected, but not the other, we end up with an unexpected rejection - and the test fails.
> This is a little hard to explain in the abstract, so let me know if any of the above doesn't make sense.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6766) Rejection-style transformer tests assume each operation generated by parser has distinct PathAddress
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-6766?page=com.atlassian.jira.plugin.... ]
Kabir Khan commented on WFLY-6766:
----------------------------------
Yes
> Rejection-style transformer tests assume each operation generated by parser has distinct PathAddress
> ----------------------------------------------------------------------------------------------------
>
> Key: WFLY-6766
> URL: https://issues.jboss.org/browse/WFLY-6766
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 10.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Kabir Khan
>
> For rejection-style transformer tests, the subsystem test framework stores expected rejected operations in a map keyed by PathAddress. This is fine when the subsystem's parser only generates add operations. However, if the parser generates an add operation as well as a a write-attribute operation, these 2 operations will have the same path address. If we expect one of these operations to be rejected, but not the other, we end up with an unexpected rejection - and the test fails.
> This is a little hard to explain in the abstract, so let me know if any of the above doesn't make sense.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1835) Allow server to start in suspended mode
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1835:
----------------------------------------
Summary: Allow server to start in suspended mode
Key: WFCORE-1835
URL: https://issues.jboss.org/browse/WFCORE-1835
Project: WildFly Core
Issue Type: Bug
Reporter: Stuart Douglas
Assignee: Stuart Douglas
It should be possible to start the server in suspended mode. In addition to this as part of normal startup the server should be suspended until the MSC service container hits stability. This will fix a lot of the graceful startup issues that have been reported.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6766) Rejection-style transformer tests assume each operation generated by parser has distinct PathAddress
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-6766?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-6766:
----------------------------------------
[~kabirkhan] this one is WFCORE, right?
> Rejection-style transformer tests assume each operation generated by parser has distinct PathAddress
> ----------------------------------------------------------------------------------------------------
>
> Key: WFLY-6766
> URL: https://issues.jboss.org/browse/WFLY-6766
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 10.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Kabir Khan
>
> For rejection-style transformer tests, the subsystem test framework stores expected rejected operations in a map keyed by PathAddress. This is fine when the subsystem's parser only generates add operations. However, if the parser generates an add operation as well as a a write-attribute operation, these 2 operations will have the same path address. If we expect one of these operations to be rejected, but not the other, we end up with an unexpected rejection - and the test fails.
> This is a little hard to explain in the abstract, so let me know if any of the above doesn't make sense.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (ELY-644) Creating LDAP security realm fails with cryptic error message
by Zach Rhoads (JIRA)
Zach Rhoads created ELY-644:
-------------------------------
Summary: Creating LDAP security realm fails with cryptic error message
Key: ELY-644
URL: https://issues.jboss.org/browse/ELY-644
Project: WildFly Elytron
Issue Type: Bug
Reporter: Zach Rhoads
Assignee: Darran Lofthouse
When creating an LDAP security realm via CLI, setup fails with cryptic error message.
For example, creating a dir-context works fine:
/subsystem=elytron/dir-context=exampleDC:add(url="ldap://127.0.0.1:10389",principal="uid=admin,ou=system",credential="secret")
But when creating an ldap-realm:
/subsystem=elytron/ldap-realm=exampleLR:add(dir-context=exampleDC,identity-mapping={search-base-dn="ou=Users,dc=jboss,dc=org",rdn-identifier="uid",user-password-mapper={from="userPassword"}})
It fails:
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException",
"rolled-back" => true
}
Full log in wildfly:
14:11:03,368 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "elytron"),
("ldap-realm" => "exampleLR")
]): java.lang.IllegalArgumentException
at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:69)
at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:267)
at org.wildfly.extension.elytron.LdapRealmDefinition$UserPasswordCredentialMappingObjectDefinition.configure(LdapRealmDefinition.java:163)
at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.configureIdentityMapping(LdapRealmDefinition.java:420)
at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.performRuntime(LdapRealmDefinition.java:375)
at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337)
at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
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)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7230) Undertow subsystem template missing changes latest schema updates.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7230?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-7230:
-----------------------------------
Fix Version/s: 11.0.0.Alpha1
> Undertow subsystem template missing changes latest schema updates.
> ------------------------------------------------------------------
>
> Key: WFLY-7230
> URL: https://issues.jboss.org/browse/WFLY-7230
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 11.0.0.Alpha1
>
>
> The following error message is reported starting domain.sh -c domain-elytron.xml
> {noformat}
> [Host Controller] 16:45:45,433 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0033: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
> [Host Controller] at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131)
> [Host Controller] at org.jboss.as.host.controller.DomainModelControllerService.boot(DomainModelControllerService.java:721)
> [Host Controller] at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:302)
> [Host Controller] at java.lang.Thread.run(Thread.java:745)
> [Host Controller] Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[780,21]
> [Host Controller] Message: WFLYCTL0376: Unexpected attribute 'security-domain' encountered. Valid attributes are: 'http-authentication-factory, override-deployment-config'
> [Host Controller] at org.jboss.as.controller.parsing.ParseUtils.unexpectedAttribute(ParseUtils.java:128)
> [Host Controller] at org.jboss.as.controller.PersistentResourceXMLDescription.parseAttributes(PersistentResourceXMLDescription.java:198)
> [Host Controller] at org.jboss.as.controller.PersistentResourceXMLDescription.parseAttributeGroups(PersistentResourceXMLDescription.java:140)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6599) JDBC_PING can't use a JNDI database connection because it is closed on shutdown
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6599?page=com.atlassian.jira.plugin.... ]
Radoslav Husar edited comment on WFLY-6599 at 9/27/16 2:58 PM:
---------------------------------------------------------------
-See JGRP-2063 for changes that need to be done in JGroups directly.-
Proposed fix without changes in JGroups.
was (Author: rhusar):
-See JGRP-2063 for changes that need to be done in JGroups directly.-
Fixed without changes in JGroups.
> JDBC_PING can't use a JNDI database connection because it is closed on shutdown
> -------------------------------------------------------------------------------
>
> Key: WFLY-6599
> URL: https://issues.jboss.org/browse/WFLY-6599
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Reporter: Matthew Casperson
> Assignee: Radoslav Husar
> Fix For: 11.0.0.Alpha1
>
>
> If you configure the JDBC_PING protocol in JGroups to use a datasource provided by WildFly via the *datasource_jndi_name* setting, you'll get the following exception when WildFly is shutdown:
> {code}
> [Server:main-server] 2016-05-10 11:05:45+1000 ERROR [[org.jgroups.protocols.JDBC_PING]] [[MSC service thread 1-4]] Could not open connection to database: java.sql.SQLException: javax.resource.ResourceException: IJ000470: You are trying to use a connection factory that has been shut down: java:/comp/env/jdbc/jgroups
> [Server:main-server] at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:146)
> [Server:main-server] at org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:66)
> [Server:main-server] at org.jgroups.protocols.JDBC_PING.getConnection(JDBC_PING.java:348)
> [Server:main-server] at org.jgroups.protocols.JDBC_PING.delete(JDBC_PING.java:379)
> [Server:main-server] at org.jgroups.protocols.JDBC_PING.deleteSelf(JDBC_PING.java:395)
> [Server:main-server] at org.jgroups.protocols.JDBC_PING.stop(JDBC_PING.java:144)
> [Server:main-server] at org.jgroups.stack.ProtocolStack.stopStack(ProtocolStack.java:1015)
> [Server:main-server] at org.jgroups.JChannel.stopStack(JChannel.java:1002)
> [Server:main-server] at org.jgroups.JChannel.disconnect(JChannel.java:373)
> [Server:main-server] at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.stop(ChannelConnectorBuilder.java:103)
> [Server:main-server] at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056)
> [Server:main-server] at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017)
> [Server:main-server] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Server:main-server] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Server:main-server] at java.lang.Thread.run(Thread.java:745)
> [Server:main-server] Caused by: javax.resource.ResourceException: IJ000470: You are trying to use a connection factory that has been shut down: java:/comp/env/jdbc/jgroups
> [Server:main-server] at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:735)
> [Server:main-server] at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:138)
> [Server:main-server] ... 14 more
> {code}
> The solution is to configure the database connection directly, but then it seems that you loose the ability to use features like database connection validation, reconnection and the other settings provided by a WildFly datasource the improve the reliability of a database connection.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6599) JDBC_PING can't use a JNDI database connection because it is closed on shutdown
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6599?page=com.atlassian.jira.plugin.... ]
Radoslav Husar edited comment on WFLY-6599 at 9/27/16 2:57 PM:
---------------------------------------------------------------
-See JGRP-2063 for changes that need to be done in JGroups directly.-
Fixed without changes in JGroups.
was (Author: rhusar):
See JGRP-2063 for changes that need to be done in JGroups directly.
> JDBC_PING can't use a JNDI database connection because it is closed on shutdown
> -------------------------------------------------------------------------------
>
> Key: WFLY-6599
> URL: https://issues.jboss.org/browse/WFLY-6599
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Reporter: Matthew Casperson
> Assignee: Radoslav Husar
> Fix For: 11.0.0.Alpha1
>
>
> If you configure the JDBC_PING protocol in JGroups to use a datasource provided by WildFly via the *datasource_jndi_name* setting, you'll get the following exception when WildFly is shutdown:
> {code}
> [Server:main-server] 2016-05-10 11:05:45+1000 ERROR [[org.jgroups.protocols.JDBC_PING]] [[MSC service thread 1-4]] Could not open connection to database: java.sql.SQLException: javax.resource.ResourceException: IJ000470: You are trying to use a connection factory that has been shut down: java:/comp/env/jdbc/jgroups
> [Server:main-server] at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:146)
> [Server:main-server] at org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:66)
> [Server:main-server] at org.jgroups.protocols.JDBC_PING.getConnection(JDBC_PING.java:348)
> [Server:main-server] at org.jgroups.protocols.JDBC_PING.delete(JDBC_PING.java:379)
> [Server:main-server] at org.jgroups.protocols.JDBC_PING.deleteSelf(JDBC_PING.java:395)
> [Server:main-server] at org.jgroups.protocols.JDBC_PING.stop(JDBC_PING.java:144)
> [Server:main-server] at org.jgroups.stack.ProtocolStack.stopStack(ProtocolStack.java:1015)
> [Server:main-server] at org.jgroups.JChannel.stopStack(JChannel.java:1002)
> [Server:main-server] at org.jgroups.JChannel.disconnect(JChannel.java:373)
> [Server:main-server] at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.stop(ChannelConnectorBuilder.java:103)
> [Server:main-server] at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056)
> [Server:main-server] at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017)
> [Server:main-server] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Server:main-server] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Server:main-server] at java.lang.Thread.run(Thread.java:745)
> [Server:main-server] Caused by: javax.resource.ResourceException: IJ000470: You are trying to use a connection factory that has been shut down: java:/comp/env/jdbc/jgroups
> [Server:main-server] at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:735)
> [Server:main-server] at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:138)
> [Server:main-server] ... 14 more
> {code}
> The solution is to configure the database connection directly, but then it seems that you loose the ability to use features like database connection validation, reconnection and the other settings provided by a WildFly datasource the improve the reliability of a database connection.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7230) Undertow subsystem template missing changes latest schema updates.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7230?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse moved JBEAP-6231 to WFLY-7230:
-----------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7230 (was: JBEAP-6231)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Web (Undertow)
(was: Web (Undertow))
Affects Version/s: (was: 7.1.0.DR5)
> Undertow subsystem template missing changes latest schema updates.
> ------------------------------------------------------------------
>
> Key: WFLY-7230
> URL: https://issues.jboss.org/browse/WFLY-7230
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
>
> The following error message is reported starting domain.sh -c domain-elytron.xml
> {noformat}
> [Host Controller] 16:45:45,433 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0033: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
> [Host Controller] at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131)
> [Host Controller] at org.jboss.as.host.controller.DomainModelControllerService.boot(DomainModelControllerService.java:721)
> [Host Controller] at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:302)
> [Host Controller] at java.lang.Thread.run(Thread.java:745)
> [Host Controller] Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[780,21]
> [Host Controller] Message: WFLYCTL0376: Unexpected attribute 'security-domain' encountered. Valid attributes are: 'http-authentication-factory, override-deployment-config'
> [Host Controller] at org.jboss.as.controller.parsing.ParseUtils.unexpectedAttribute(ParseUtils.java:128)
> [Host Controller] at org.jboss.as.controller.PersistentResourceXMLDescription.parseAttributes(PersistentResourceXMLDescription.java:198)
> [Host Controller] at org.jboss.as.controller.PersistentResourceXMLDescription.parseAttributeGroups(PersistentResourceXMLDescription.java:140)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JASSIST-261) Issue with javassist on jdk 9b112
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/JASSIST-261?page=com.atlassian.jira.plugi... ]
Scott Marlow commented on JASSIST-261:
--------------------------------------
[~sebersole] I just pushed a 3.21.0-SNAPSHOT:
{quote}
Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jav...
Uploaded: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jav... (719 KB at 296.1 KB/sec)
Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jav...
Uploaded: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jav... (10 KB at 20.4 KB/sec)
Downloading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jav...
Downloaded: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jav... (365 B at 0.5 KB/sec)
Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jav...
Uploaded: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jav... (990 B at 1.8 KB/sec)
Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jav...
Uploaded: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jav... (344 B at 0.6 KB/sec)
Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jav...
Uploaded: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jav... (515 KB at 345.2 KB/sec)
Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jav...
Uploaded: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jav... (990 B at 1.6 KB/sec)
{quote}
> Issue with javassist on jdk 9b112
> ---------------------------------
>
> Key: JASSIST-261
> URL: https://issues.jboss.org/browse/JASSIST-261
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.20.0-GA
> Environment: Javassist with jdk 9b112
> Reporter: Hoang Chuong Tran
> Assignee: Shigeru Chiba
>
> I am migrating a project to java 9, which also uses javassist to generate runtime code.
> One test of mine fails on jdk 9b112 while it passes on jdk 8u77.
> {noformat}
> import static javassist.CtClass.voidType;
> import java.lang.reflect.Method;
> import java.lang.reflect.Modifier;
> import java.util.HashMap;
> import java.util.Map;
> import org.junit.Test;
> import javassist.ClassClassPath;
> import javassist.ClassPool;
> import javassist.CtClass;
> import javassist.CtField;
> import javassist.CtMethod;
> import javassist.CtNewMethod;
> public class MyTests {
> public static class MyObject {
> protected Object field;
> Object getField() {return field;}
> public void setField(Object field) {}
> }
> @Test
> public void test() throws InstantiationException, IllegalAccessException {
> Class<? extends MyObject> clazz = compile(MyObject.class);
> clazz.newInstance().setField(null);
> }
> /** Compile a transfer class */
> public static synchronized Class<? extends MyObject> compile(Class<?> targetClass) {
> // Determine class setters
> Map<String, Method> setters = extractSetters(targetClass);
> ClassPool classPool = ClassPool.getDefault();
> classPool.insertClassPath(new ClassClassPath(targetClass));
> try {
> // Compile a new transfer class on the fly
> CtClass baseClass = classPool.get(MyObject.class.getName());
> CtClass proxyClass = classPool.makeClass(targetClass.getName() + "_Modified", baseClass);
> for(Method originalSetter : setters.values()) {
> // Create a field to hold the attribute
> Class<?> fieldClass = originalSetter.getParameterTypes()[0];
> CtClass fieldType = classPool.get(fieldClass.getName());
> String fieldName = originalSetter.getName().substring(3);
> CtField field = new CtField(fieldType, fieldName, proxyClass);
> proxyClass.addField(field);
> // Create a setter method to set that field
> CtClass[] parameters = new CtClass[] { fieldType };
> String setterBody = "{ System.out.println(\"Hello World\"); }";
> CtMethod setter = CtNewMethod.make(voidType, originalSetter.getName(), parameters, new CtClass[0], setterBody, proxyClass);
> proxyClass.addMethod(setter);
> }
> Class<? extends MyObject> javaClass = proxyClass.toClass(targetClass.getClassLoader(), targetClass.getProtectionDomain());
> return javaClass;
> } catch(Exception e) {
> throw new RuntimeException("Failure during transfer compilation for " + targetClass, e);
> }
> }
> /** Extract setter methods from a class */
> public static Map<String, Method> extractSetters(Class<?> cls) {
> Map<String, Method> setters = new HashMap<String, Method>();
> for(Method method : cls.getMethods()) {
> // Lookup setter methods
> if(method.getName().startsWith("set")) {
> // Only public setters
> int modifiers = method.getModifiers();
> if(Modifier.isPublic(modifiers)) {
> Class<?>[] exceptions = method.getExceptionTypes();
> Class<?>[] parameters = method.getParameterTypes();
> Class<?> returnType = method.getReturnType();
> if(exceptions.length <= 0 && parameters.length == 1 && "void".equals(returnType.getName())) {
> setters.put(method.getName(), method);
> }
> }
> }
> }
> return setters;
> }
> }
> {noformat}
> On jdk 8u77, the {{compile()}} function returns with success and "Hello world" is printed to the console.
> On jdk 9b112, I got the following exception
> {noformat}
> java.lang.RuntimeException: Failure during transfer compilation for class MyTests$MyObject
> at MyTests.compile(MyTests.java:68)
> at MyTests.test(MyTests.java:29)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:670)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: javassist.NotFoundException: java.lang.Object
> at javassist.ClassPool.get(ClassPool.java:450)
> at MyTests.compile(MyTests.java:51)
> ... 24 more
> {noformat}
> I suspect that is due to the jigsaw integration into the jdk.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JASSIST-261) Issue with javassist on jdk 9b112
by Steve Ebersole (JIRA)
[ https://issues.jboss.org/browse/JASSIST-261?page=com.atlassian.jira.plugi... ]
Steve Ebersole commented on JASSIST-261:
----------------------------------------
Is that pushed to a Maven repo? If so I could try in the Hibernate build.
> Issue with javassist on jdk 9b112
> ---------------------------------
>
> Key: JASSIST-261
> URL: https://issues.jboss.org/browse/JASSIST-261
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.20.0-GA
> Environment: Javassist with jdk 9b112
> Reporter: Hoang Chuong Tran
> Assignee: Shigeru Chiba
>
> I am migrating a project to java 9, which also uses javassist to generate runtime code.
> One test of mine fails on jdk 9b112 while it passes on jdk 8u77.
> {noformat}
> import static javassist.CtClass.voidType;
> import java.lang.reflect.Method;
> import java.lang.reflect.Modifier;
> import java.util.HashMap;
> import java.util.Map;
> import org.junit.Test;
> import javassist.ClassClassPath;
> import javassist.ClassPool;
> import javassist.CtClass;
> import javassist.CtField;
> import javassist.CtMethod;
> import javassist.CtNewMethod;
> public class MyTests {
> public static class MyObject {
> protected Object field;
> Object getField() {return field;}
> public void setField(Object field) {}
> }
> @Test
> public void test() throws InstantiationException, IllegalAccessException {
> Class<? extends MyObject> clazz = compile(MyObject.class);
> clazz.newInstance().setField(null);
> }
> /** Compile a transfer class */
> public static synchronized Class<? extends MyObject> compile(Class<?> targetClass) {
> // Determine class setters
> Map<String, Method> setters = extractSetters(targetClass);
> ClassPool classPool = ClassPool.getDefault();
> classPool.insertClassPath(new ClassClassPath(targetClass));
> try {
> // Compile a new transfer class on the fly
> CtClass baseClass = classPool.get(MyObject.class.getName());
> CtClass proxyClass = classPool.makeClass(targetClass.getName() + "_Modified", baseClass);
> for(Method originalSetter : setters.values()) {
> // Create a field to hold the attribute
> Class<?> fieldClass = originalSetter.getParameterTypes()[0];
> CtClass fieldType = classPool.get(fieldClass.getName());
> String fieldName = originalSetter.getName().substring(3);
> CtField field = new CtField(fieldType, fieldName, proxyClass);
> proxyClass.addField(field);
> // Create a setter method to set that field
> CtClass[] parameters = new CtClass[] { fieldType };
> String setterBody = "{ System.out.println(\"Hello World\"); }";
> CtMethod setter = CtNewMethod.make(voidType, originalSetter.getName(), parameters, new CtClass[0], setterBody, proxyClass);
> proxyClass.addMethod(setter);
> }
> Class<? extends MyObject> javaClass = proxyClass.toClass(targetClass.getClassLoader(), targetClass.getProtectionDomain());
> return javaClass;
> } catch(Exception e) {
> throw new RuntimeException("Failure during transfer compilation for " + targetClass, e);
> }
> }
> /** Extract setter methods from a class */
> public static Map<String, Method> extractSetters(Class<?> cls) {
> Map<String, Method> setters = new HashMap<String, Method>();
> for(Method method : cls.getMethods()) {
> // Lookup setter methods
> if(method.getName().startsWith("set")) {
> // Only public setters
> int modifiers = method.getModifiers();
> if(Modifier.isPublic(modifiers)) {
> Class<?>[] exceptions = method.getExceptionTypes();
> Class<?>[] parameters = method.getParameterTypes();
> Class<?> returnType = method.getReturnType();
> if(exceptions.length <= 0 && parameters.length == 1 && "void".equals(returnType.getName())) {
> setters.put(method.getName(), method);
> }
> }
> }
> }
> return setters;
> }
> }
> {noformat}
> On jdk 8u77, the {{compile()}} function returns with success and "Hello world" is printed to the console.
> On jdk 9b112, I got the following exception
> {noformat}
> java.lang.RuntimeException: Failure during transfer compilation for class MyTests$MyObject
> at MyTests.compile(MyTests.java:68)
> at MyTests.test(MyTests.java:29)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:670)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: javassist.NotFoundException: java.lang.Object
> at javassist.ClassPool.get(ClassPool.java:450)
> at MyTests.compile(MyTests.java:51)
> ... 24 more
> {noformat}
> I suspect that is due to the jigsaw integration into the jdk.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (DROOLS-1308) Rules compilation failure depending on condition ordering
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1308?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1308:
-------------------------------------
I reproduced this problem with this simple rule
{code}
rule R when
$l : List( )
String() from $l
(String() or Number())
then end
{code}
The problem there is that the parser reads the from expression as
{code}
from $l (String() or Number())
{code}
and it is impossible to disambiguate this from a function call. The straightforward fix to this is wrapping also the from clause in parenthesis as it follows:
{code}
rule R when
$l : List( )
(String() from $l)
(String() or Number())
then end
{code}
We will fix the DRL marshaller accordingly.
> Rules compilation failure depending on condition ordering
> ---------------------------------------------------------
>
> Key: DROOLS-1308
> URL: https://issues.jboss.org/browse/DROOLS-1308
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.4.0.Final
> Reporter: Martin Weiler
> Assignee: Mario Fusco
>
> When creating rules in guided editor, we are running into validation errors depending on the order of the conditions. The problem is that the order of the conditions is important:
> {noformat}
> when
> COND_X
> COND_Y => works
> when
> COND_Y
> COND_X => fails
> java.lang.AssertionError: [10,18]: [ERR 101] Line 10:18 no viable alternative at input 'Number' in rule "ATO_Negative_AU_Test"
> [0,0]: Parser returned a null Package
> {noformat}
> Test cases showing the compilation failures (@Test testOrder1 vs
> testOrder2) can be found here:
> https://gist.github.com/martinweiler/e684a0e75a2c9f4de4dee5a13affb8b0
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JASSIST-261) Issue with javassist on jdk 9b112
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-261?page=com.atlassian.jira.plugi... ]
Shigeru Chiba commented on JASSIST-261:
---------------------------------------
I implemented my idea mentioned above.
Scott, could you try the latest version available as Javassist 3.21.0 for Java 9 early access 2?
see https://github.com/jboss-javassist/javassist/releases/tag/rel_3_21_0-java...
> Issue with javassist on jdk 9b112
> ---------------------------------
>
> Key: JASSIST-261
> URL: https://issues.jboss.org/browse/JASSIST-261
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.20.0-GA
> Environment: Javassist with jdk 9b112
> Reporter: Hoang Chuong Tran
> Assignee: Shigeru Chiba
>
> I am migrating a project to java 9, which also uses javassist to generate runtime code.
> One test of mine fails on jdk 9b112 while it passes on jdk 8u77.
> {noformat}
> import static javassist.CtClass.voidType;
> import java.lang.reflect.Method;
> import java.lang.reflect.Modifier;
> import java.util.HashMap;
> import java.util.Map;
> import org.junit.Test;
> import javassist.ClassClassPath;
> import javassist.ClassPool;
> import javassist.CtClass;
> import javassist.CtField;
> import javassist.CtMethod;
> import javassist.CtNewMethod;
> public class MyTests {
> public static class MyObject {
> protected Object field;
> Object getField() {return field;}
> public void setField(Object field) {}
> }
> @Test
> public void test() throws InstantiationException, IllegalAccessException {
> Class<? extends MyObject> clazz = compile(MyObject.class);
> clazz.newInstance().setField(null);
> }
> /** Compile a transfer class */
> public static synchronized Class<? extends MyObject> compile(Class<?> targetClass) {
> // Determine class setters
> Map<String, Method> setters = extractSetters(targetClass);
> ClassPool classPool = ClassPool.getDefault();
> classPool.insertClassPath(new ClassClassPath(targetClass));
> try {
> // Compile a new transfer class on the fly
> CtClass baseClass = classPool.get(MyObject.class.getName());
> CtClass proxyClass = classPool.makeClass(targetClass.getName() + "_Modified", baseClass);
> for(Method originalSetter : setters.values()) {
> // Create a field to hold the attribute
> Class<?> fieldClass = originalSetter.getParameterTypes()[0];
> CtClass fieldType = classPool.get(fieldClass.getName());
> String fieldName = originalSetter.getName().substring(3);
> CtField field = new CtField(fieldType, fieldName, proxyClass);
> proxyClass.addField(field);
> // Create a setter method to set that field
> CtClass[] parameters = new CtClass[] { fieldType };
> String setterBody = "{ System.out.println(\"Hello World\"); }";
> CtMethod setter = CtNewMethod.make(voidType, originalSetter.getName(), parameters, new CtClass[0], setterBody, proxyClass);
> proxyClass.addMethod(setter);
> }
> Class<? extends MyObject> javaClass = proxyClass.toClass(targetClass.getClassLoader(), targetClass.getProtectionDomain());
> return javaClass;
> } catch(Exception e) {
> throw new RuntimeException("Failure during transfer compilation for " + targetClass, e);
> }
> }
> /** Extract setter methods from a class */
> public static Map<String, Method> extractSetters(Class<?> cls) {
> Map<String, Method> setters = new HashMap<String, Method>();
> for(Method method : cls.getMethods()) {
> // Lookup setter methods
> if(method.getName().startsWith("set")) {
> // Only public setters
> int modifiers = method.getModifiers();
> if(Modifier.isPublic(modifiers)) {
> Class<?>[] exceptions = method.getExceptionTypes();
> Class<?>[] parameters = method.getParameterTypes();
> Class<?> returnType = method.getReturnType();
> if(exceptions.length <= 0 && parameters.length == 1 && "void".equals(returnType.getName())) {
> setters.put(method.getName(), method);
> }
> }
> }
> }
> return setters;
> }
> }
> {noformat}
> On jdk 8u77, the {{compile()}} function returns with success and "Hello world" is printed to the console.
> On jdk 9b112, I got the following exception
> {noformat}
> java.lang.RuntimeException: Failure during transfer compilation for class MyTests$MyObject
> at MyTests.compile(MyTests.java:68)
> at MyTests.test(MyTests.java:29)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:670)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: javassist.NotFoundException: java.lang.Object
> at javassist.ClassPool.get(ClassPool.java:450)
> at MyTests.compile(MyTests.java:51)
> ... 24 more
> {noformat}
> I suspect that is due to the jigsaw integration into the jdk.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1834) Unexpected attribute error message doesn't list 'name' attribute.
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFCORE-1834:
----------------------------------------
Summary: Unexpected attribute error message doesn't list 'name' attribute.
Key: WFCORE-1834
URL: https://issues.jboss.org/browse/WFCORE-1834
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Reporter: Darran Lofthouse
Assignee: Tomaz Cerar
Fix For: 3.0.0.Alpha9
I have recently updated one of our resource definitions and missed updating one of the subsystem templates so currently have the following error reported: -
{noformat}
Message: WFLYCTL0376: Unexpected attribute 'security-domain' encountered. Valid attributes are: 'http-authentication-factory, override-deployment-config'
[Host Controller] at org.jboss.as.controller.parsing.ParseUtils.unexpectedAttribute(ParseUtils.java:128)
{noformat}
Previously my resource has been using the 'security-domain' attribute for it's name but now has been reverted to using 'name' for the name - in the above error message 'name' should have been listed as one of the valid attributes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7224) Missing validation check for simple-regex-realm-mapper and mapped-regex-realm-mapper in Elytron subsystem
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/WFLY-7224?page=com.atlassian.jira.plugin.... ]
Ilia Vassilev commented on WFLY-7224:
-------------------------------------
[~dlofthouse] ok. I'll ask [~honza889]. Thanks!
> Missing validation check for simple-regex-realm-mapper and mapped-regex-realm-mapper in Elytron subsystem
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7224
> URL: https://issues.jboss.org/browse/WFLY-7224
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
>
> Elytron subsystem allows to add realm mapper (e.g. simple-regex-realm-mapper) with pattern which does not include a capture group. In case when this realm mapper is used in add operation for security domain through CLI then operation fails with incomprehensible log:
> {code}
> {
> "outcome" => "failed",
> "failure-description" => {"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined},
> "rolled-back" => true
> }
> {code}
> Exception in server log:
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.security.realm-mapper.SomeRealmMapper: org.jboss.msc.service.StartException in service org.wildfly.security.realm-mapper.SomeRealmMapper: 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.IllegalArgumentException: ELY01065: Pattern requires a capture group
> at org.wildfly.security.auth.util.SimpleRegexRealmMapper.<init>(SimpleRegexRealmMapper.java:64)
> at org.wildfly.security.auth.util.SimpleRegexRealmMapper.<init>(SimpleRegexRealmMapper.java:49)
> at org.wildfly.extension.elytron.RealmMapperDefinitions$SimpleRegexRealmMapperAddHandler.lambda$performRuntime$0(RealmMapperDefinitions.java:157)
> 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}
> The same happens for mapped-regex-realm-mapper.
> Point here is that we allow to successfully add wrong realm mapper (without capture group) but we check whether it is wrong later in security domain. This check should be done during adding wrong realm mapper to avoid following incomprehensible CLI log and exception in server log.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7224) Missing validation check for simple-regex-realm-mapper and mapped-regex-realm-mapper in Elytron subsystem
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7224?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-7224:
----------------------------------------
[~ivassile] For subsystem related tasks most importantly just coordinate with [~honza889] he is the engineer on our team handling the subsystem issues at the moment.
> Missing validation check for simple-regex-realm-mapper and mapped-regex-realm-mapper in Elytron subsystem
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7224
> URL: https://issues.jboss.org/browse/WFLY-7224
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
>
> Elytron subsystem allows to add realm mapper (e.g. simple-regex-realm-mapper) with pattern which does not include a capture group. In case when this realm mapper is used in add operation for security domain through CLI then operation fails with incomprehensible log:
> {code}
> {
> "outcome" => "failed",
> "failure-description" => {"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined},
> "rolled-back" => true
> }
> {code}
> Exception in server log:
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.security.realm-mapper.SomeRealmMapper: org.jboss.msc.service.StartException in service org.wildfly.security.realm-mapper.SomeRealmMapper: 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.IllegalArgumentException: ELY01065: Pattern requires a capture group
> at org.wildfly.security.auth.util.SimpleRegexRealmMapper.<init>(SimpleRegexRealmMapper.java:64)
> at org.wildfly.security.auth.util.SimpleRegexRealmMapper.<init>(SimpleRegexRealmMapper.java:49)
> at org.wildfly.extension.elytron.RealmMapperDefinitions$SimpleRegexRealmMapperAddHandler.lambda$performRuntime$0(RealmMapperDefinitions.java:157)
> 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}
> The same happens for mapped-regex-realm-mapper.
> Point here is that we allow to successfully add wrong realm mapper (without capture group) but we check whether it is wrong later in security domain. This check should be done during adding wrong realm mapper to avoid following incomprehensible CLI log and exception in server log.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1833) Temporarily workaround Jigsaw ServiceLoader regression
by Richard Opalka (JIRA)
Richard Opalka created WFCORE-1833:
--------------------------------------
Summary: Temporarily workaround Jigsaw ServiceLoader regression
Key: WFCORE-1833
URL: https://issues.jboss.org/browse/WFCORE-1833
Project: WildFly Core
Issue Type: Sub-task
Reporter: Richard Opalka
Assignee: Richard Opalka
There's ServiceLoader regression in recent Jigsaw JDK9 builds.
We will implement temporary workaround for this Jigsaw issue.
This issue can be closed / resolved once this workaround
will be eliminated from our code base.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7224) Missing validation check for simple-regex-realm-mapper and mapped-regex-realm-mapper in Elytron subsystem
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/WFLY-7224?page=com.atlassian.jira.plugin.... ]
Ilia Vassilev commented on WFLY-7224:
-------------------------------------
[~dlofthouse] Do you mind if I work on this one and related https://issues.jboss.org/browse/WFLY-7225?
> Missing validation check for simple-regex-realm-mapper and mapped-regex-realm-mapper in Elytron subsystem
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7224
> URL: https://issues.jboss.org/browse/WFLY-7224
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
>
> Elytron subsystem allows to add realm mapper (e.g. simple-regex-realm-mapper) with pattern which does not include a capture group. In case when this realm mapper is used in add operation for security domain through CLI then operation fails with incomprehensible log:
> {code}
> {
> "outcome" => "failed",
> "failure-description" => {"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined},
> "rolled-back" => true
> }
> {code}
> Exception in server log:
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.security.realm-mapper.SomeRealmMapper: org.jboss.msc.service.StartException in service org.wildfly.security.realm-mapper.SomeRealmMapper: 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.IllegalArgumentException: ELY01065: Pattern requires a capture group
> at org.wildfly.security.auth.util.SimpleRegexRealmMapper.<init>(SimpleRegexRealmMapper.java:64)
> at org.wildfly.security.auth.util.SimpleRegexRealmMapper.<init>(SimpleRegexRealmMapper.java:49)
> at org.wildfly.extension.elytron.RealmMapperDefinitions$SimpleRegexRealmMapperAddHandler.lambda$performRuntime$0(RealmMapperDefinitions.java:157)
> 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}
> The same happens for mapped-regex-realm-mapper.
> Point here is that we allow to successfully add wrong realm mapper (without capture group) but we check whether it is wrong later in security domain. This check should be done during adding wrong realm mapper to avoid following incomprehensible CLI log and exception in server log.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7212) Cannot use BMT in @Schedule service
by Karl Nicholas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7212?page=com.atlassian.jira.plugin.... ]
Karl Nicholas commented on WFLY-7212:
-------------------------------------
But hold on, isn't that what the second set of code I posted was trying to do? If so, then that didn't work, or at least it doesn't solve the issue of having the transaction-reaper come along in 5 minutes and shut things down. Am I missing something about UserTransaction? Thanks.
> Cannot use BMT in @Schedule service
> -----------------------------------
>
> Key: WFLY-7212
> URL: https://issues.jboss.org/browse/WFLY-7212
> Project: WildFly
> Issue Type: Feature Request
> Components: EE, EJB, Transactions
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Environment: Wildfly 10.1.0-Final. Windows 10. MySql 5.5.
> Reporter: Karl Nicholas
> Labels: arjuna, ejb, scheduled, scheduled_tasks, transaction
>
> When injecting a `@Resource private UserTransaction tx;`, a `TransactionReaper` terminates kills my `UserTransaction` after 5 minutes no matter what. Since it's a batch update, I need more than 5 minutes.
> Here is a simple piece of code that doesn't work:
> {code:java}
> @EJB private TestFiveMinuteBatch testFiveMinuteBatch;
> @Schedule(second="0", minute="8", hour="10", persistent=false) // 03:30 am (12:30 am CA ) every day
> public void updateTest() {
> testFiveMinuteBatch.test();
> }
> @Stateless
> @TransactionManagement(TransactionManagementType.BEAN)
> public class TestFiveMinuteBatch {
> @Resource private UserTransaction tx;
> public void test() {
> for ( int i=0; i < 6; ++i ) {
> System.out.println("Minute: " + i);
> try {
> Thread.sleep(60000);
> } catch (InterruptedException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
> }
> }
> }
> {code}
> After 5 minutes I get this warning:
> {noformat}
> 10:13:00,034 WARN [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffffac1f6209:-595568e4:57e80419:e in state RUN
> 10:13:00,039 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012121: TransactionReaper::doCancellations worker Thread[Transaction Reaper Worker 0,5,main] successfully canceled TX 0:ffffac1f6209:-595568e4:57e80419:e
> 10:13:00,130 INFO [stdout] (EJB default - 1) Minute: 5
> {noformat}
> After service terminates I get this error:
> {noformat}
> 10:14:00,131 WARN [com.arjuna.ats.arjuna] (EJB default - 1) ARJUNA012077: Abort called on already aborted atomic action 0:ffffac1f6209:-595568e4:57e80419:e
> 10:14:00,163 ERROR [org.jboss.as.ejb3.timer] (EJB default - 1) WFLYEJB0020: Error invoking timeout for timer: [id=8a8f4546-28d0-491e-85a6-f668f58ab5dc timedObjectId=opca-ear.opca-ejb.ScheduledService auto-timer?:true persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@31fe8c3e initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Mon Sep 26 10:08:00 PDT 2016 timerState=IN_TIMEOUT info=null]: javax.ejb.EJBTransactionRolledbackException: Transaction rolled back
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleEndTransactionException(CMTTxInterceptor.java:137)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:117)
> at org.jboss.as.ejb3.tx.TimerCMTTxInterceptor.endTransaction(TimerCMTTxInterceptor.java:67)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:279)
> 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.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:110)
> 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.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.ejb3.timerservice.TimedObjectInvokerImpl.callTimeout(TimedObjectInvokerImpl.java:99)
> at org.jboss.as.ejb3.timerservice.CalendarTimerTask.invokeBeanMethod(CalendarTimerTask.java:64)
> at org.jboss.as.ejb3.timerservice.CalendarTimerTask.callTimeout(CalendarTimerTask.java:53)
> at org.jboss.as.ejb3.timerservice.TimerTask.run(TimerTask.java:157)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl$Task$1.run(TimerServiceImpl.java:1215)
> at org.wildfly.extension.requestcontroller.RequestController$QueuedTask$1.run(RequestController.java:497)
> 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)
> Caused by: javax.transaction.RollbackException: WFLYEJB0447: Transaction 'TransactionImple < ac, BasicAction: 0:ffffac1f6209:-595568e4:57e80419:e status: ActionStatus.ABORTED >' was already rolled back
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:98)
> ... 38 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7226) Missing realm-map attribute for mapped-regex-realm-mapper throws IllegalArgumentException to server log
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7226?page=com.atlassian.jira.plugin.... ]
Jan Kalina reassigned WFLY-7226:
--------------------------------
Assignee: Jan Kalina (was: Darran Lofthouse)
> Missing realm-map attribute for mapped-regex-realm-mapper throws IllegalArgumentException to server log
> -------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7226
> URL: https://issues.jboss.org/browse/WFLY-7226
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
>
> In case when mapped-regex-realm-mapper is added through CLI and realm-map attribute is not used then IllegalArgumentException is thrown to server log instead of some CLI failure message like "realm-map may not be null".
> Expcetion in server log:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("mapped-regex-realm-mapper" => "MappedRealmMapper")
> ]): java.lang.IllegalArgumentException
> at org.jboss.dmr.ModelValue.getKeys(ModelValue.java:139)
> at org.jboss.dmr.ModelNode.keys(ModelNode.java:1378)
> at org.wildfly.extension.elytron.RealmMapperDefinitions$MappedRegexRealmMapperAddHandler.performRuntime(RealmMapperDefinitions.java:221)
> at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337)
> at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> 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}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7101) Wildfly 10.1.0 blocks calls to Singleton EJBs in PostConstruct
by Dietrich Schmidt (JIRA)
[ https://issues.jboss.org/browse/WFLY-7101?page=com.atlassian.jira.plugin.... ]
Dietrich Schmidt reopened WFLY-7101:
------------------------------------
Compare comment 3.
> 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, 8 months
[JBoss JIRA] (WFLY-7101) Wildfly 10.1.0 blocks calls to Singleton EJBs in PostConstruct
by Dietrich Schmidt (JIRA)
[ https://issues.jboss.org/browse/WFLY-7101?page=com.atlassian.jira.plugin.... ]
Dietrich Schmidt edited comment on WFLY-7101 at 9/27/16 11:03 AM:
------------------------------------------------------------------
EJB spec 4.8.1 does not apply to this bug, please re-investigate.
Singleton bean A (=ServerImpl) with @startup calls in its @Postconstruct method a method in singleton bean B (=TestReaderImpl) - this works fine.
Now in this @PostConstruct several Threads are created with a ManagedExcecutorService - these threads start normally, but if they call a method iin singleton bean B, they are blocked. This must not happen and is a bug.
was (Author: rumpelstilzchen926):
EJB spec 4.8.1 does not apply to this bug, please re-investigate.
Singleton bean A (=ServerImpl) with @startup calls in its @Postconstruct method a method in singleton bean B (=TestReaderImpl) - this works fine.
Now in this @PostConstruct several Threads are created with a ManagedExcecutorService - these threads start normally, but if the call a method iin singleton bean B, they are blocked. This must not happen and is a bug.
> 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, 8 months
[JBoss JIRA] (WFLY-7101) Wildfly 10.1.0 blocks calls to Singleton EJBs in PostConstruct
by Dietrich Schmidt (JIRA)
[ https://issues.jboss.org/browse/WFLY-7101?page=com.atlassian.jira.plugin.... ]
Dietrich Schmidt commented on WFLY-7101:
----------------------------------------
EJB spec 4.8.1 does not apply to this bug, please re-investigate.
Singleton bean A (=ServerImpl) with @startup calls in its @Postconstruct method a method in singleton bean B (=TestReaderImpl) - this works fine.
Now in this @PostConstruct several Threads are created with a ManagedExcecutorService - these threads start normally, but if the call a method iin singleton bean B, they are blocked. This must not happen and is a bug.
> 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, 8 months
[JBoss JIRA] (DROOLS-1310) Expired fact with activationCount > 0 are not evicted from objectstore
by Matteo Mortari (JIRA)
Matteo Mortari created DROOLS-1310:
--------------------------------------
Summary: Expired fact with activationCount > 0 are not evicted from objectstore
Key: DROOLS-1310
URL: https://issues.jboss.org/browse/DROOLS-1310
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 6.5.0.CR2
Reporter: Matteo Mortari
Assignee: Mario Fusco
Priority: Minor
Expired fact with activationCount > 0 are not evicted from objectstore: intended behavior for serialization purposes, but for instance side-effects when used in an activation-group scenario where the rules are not 100% dual.
Sized-down reproducer will be submitted at a later time.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (DROOLS-1309) Rules compilation failure depending on condition ordering
by Edson Tirelli (JIRA)
Edson Tirelli created DROOLS-1309:
-------------------------------------
Summary: Rules compilation failure depending on condition ordering
Key: DROOLS-1309
URL: https://issues.jboss.org/browse/DROOLS-1309
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 6.4.0.Final
Reporter: Martin Weiler
Assignee: Mario Fusco
When creating rules in guided editor, we are running into validation errors depending on the order of the conditions. The problem is that the order of the conditions is important:
{noformat}
when
COND_X
COND_Y => works
when
COND_Y
COND_X => fails
java.lang.AssertionError: [10,18]: [ERR 101] Line 10:18 no viable alternative at input 'Number' in rule "ATO_Negative_AU_Test"
[0,0]: Parser returned a null Package
{noformat}
Test cases showing the compilation failures (@Test testOrder1 vs
testOrder2) can be found here:
https://gist.github.com/martinweiler/e684a0e75a2c9f4de4dee5a13affb8b0
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7190) Group related resources in Elytron subsystem
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7190?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-7190:
-----------------------------------
Affects Version/s: (was: 11.0.0.Alpha1)
> Group related resources in Elytron subsystem
> --------------------------------------------
>
> Key: WFLY-7190
> URL: https://issues.jboss.org/browse/WFLY-7190
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Fix For: 11.0.0.Alpha1
>
>
> Domain model of subsystem is too flat. Every resource (realms, mappers, factories ...) is located at the base level of Elytron subsystem. Then it is hard to orientate in subsystem since it does not have deeper structure.
> Suggestion:
> It can be structuralized similar as PicketBox subsystem. There could be some subresources like realms, domains etc.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7190) Group related resources in Elytron subsystem
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7190?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-7190:
-----------------------------------
Fix Version/s: 11.0.0.Alpha1
> Group related resources in Elytron subsystem
> --------------------------------------------
>
> Key: WFLY-7190
> URL: https://issues.jboss.org/browse/WFLY-7190
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Fix For: 11.0.0.Alpha1
>
>
> Domain model of subsystem is too flat. Every resource (realms, mappers, factories ...) is located at the base level of Elytron subsystem. Then it is hard to orientate in subsystem since it does not have deeper structure.
> Suggestion:
> It can be structuralized similar as PicketBox subsystem. There could be some subresources like realms, domains etc.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7229) WFLYCLWEBUT0001 for server-side invalidated sessions
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-7229?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-7229:
----------------------------------------
Did you mean to call this a Feature Request instead of a Bug?
> WFLYCLWEBUT0001 for server-side invalidated sessions
> ----------------------------------------------------
>
> Key: WFLY-7229
> URL: https://issues.jboss.org/browse/WFLY-7229
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Affects Versions: 10.1.0.Final
> Environment: Happens whenever <distributable/> is used in web.xml, both in standalone and domain modes.
> Reporter: Michał Nowakowski
> Assignee: Stuart Douglas
> Attachments: stacktrace_01.txt, stacktrace_02.txt, stacktrace_03.txt, testPortlet.tar.gz
>
>
> Attached is a simple webapp (pardon the name) with a single servlet "/main", that does the following:
> - a session is assigned (or created, if none existed before)
> - its details are printed and the browser is told to refresh after 20 seconds
> - before the browser refreshes, the session is invalidated server-side by separate thread.
> Expected behaviour is, that WF should give the user a new session. That's indeed how it works in standalone mode and without <distributable/> in web.xml. But in domain mode, OR with <distributable/> added (and, possibly, full-ha profile chosen), I get errors:
> - The first stacktrace happens when the thread invalidates the session.
> - The second stacktrace happens, when the browser refreshes. The user sees "Error 500".
> - The, after a minute or so, I get the last one. It then repeats periodically.
> We can't upgrade from 10.0 because of this - and we know we need an upgrade because of fixes in Infinispan.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1826) Tab completion don't return inner attributes
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1826?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise updated WFCORE-1826:
-----------------------------------------
Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1835
> Tab completion don't return inner attributes
> --------------------------------------------
>
> Key: WFCORE-1826
> URL: https://issues.jboss.org/browse/WFCORE-1826
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
>
> *Description of problem:*
> Tab completion returns wrong values
> *How reproducible:*
> Always
> *Steps to Reproduce:*
> {noformat}
> /extension=org.wildfly.extension.elytron:add
> /subsystem=elytron:add
> reload
> /subsystem=elytron/simple-permission-mapper=login-permission-mapper2:add(permission-mappings=[{permissions=[{class-name="org.wildfly.security.auth.permission.LoginPermission"}],<TAB>
> {noformat}
> *Actual results:*
> {noformat}
> /subsystem=elytron/simple-permission-mapper=login-permission-mapper2:add(permission-mappings=[{permissions=[{class-name="org.wildfly.security.auth.permission.LoginPermission"}],{
> {noformat}
> *Expected results:*
> {noformat}
> [standalone@localhost:9990 /] /subsystem=elytron/simple-permission-mapper=login-permission-mapper2:add(permission-mappings=[{permissions=[{class-name="org.wildfly.security.auth.permission.LoginPermission"}],
> principals roles
> [standalone@localhost:9990 /] /subsystem=elytron/simple-permission-mapper=login-permission-mapper2:add(permission-mappings=[{permissions=[{class-name="org.wildfly.security.auth.permission.LoginPermission"}],
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1825) Tab completion throws IllegalArgumentException after two '{' characters and '=' character
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1825?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise updated WFCORE-1825:
-----------------------------------------
Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1835
> Tab completion throws IllegalArgumentException after two '{' characters and '=' character
> -----------------------------------------------------------------------------------------
>
> Key: WFCORE-1825
> URL: https://issues.jboss.org/browse/WFCORE-1825
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
>
> *Description of problem:*
> This issue is similar like JBEAP-6043. Tab completion throws IllegalArgumentException after two '\{' characters and '=' character. Or tab completition returns unlimited count of ')' characters.
> *How reproducible:*
> Always
> ----
> *1. Steps to Reproduce:*
> {noformat}
> Get fresh EAP.
> ./standalone.sh &
> ./jboss-cli.sh -c
> /subsystem=elytron/simple-permission-mapper=login-permission-mapper2:add(permission-mappings=[{roles=[{role<TAB><TAB><TAB><TAB><TAB><TAB><TAB><TAB><TAB><TAB>
> {noformat}
> *1. Actual results:*
> {noformat}
> /subsystem=elytron/simple-permission-mapper=login-permission-mapper2:add(permission-mappings=[{roles=[{role))))))))))
> {noformat}
> ----
> *2. Steps to Reproduce:*
> {noformat}
> ./standalone.sh -c standalone-elytron.xml &
> ./jboss-cli.sh -c
> /subsystem=elytron/simple-permission-mapper=login-permission-mapper2:add(permission-mappings=[{roles=[{role=<TAB>
> {noformat}
> *2. Actual results:*
> * java.lang.IllegalArgumentException
> * Details:
> {noformat}
> [mkopecky@dhcp-10-40-5-171 bin]$ ./jboss-cli.sh -c
> [standalone@localhost:9990 /] /subsystem=elytron/simple-permission-mapper=login-permission-mapper2:add(permission-mappings=[{roles=[{role=Exception in thread "Aesh Process Loop 30318020" java.lang.IllegalArgumentException
> at org.jboss.dmr.ModelValue.getChild(ModelValue.java:115)
> at org.jboss.dmr.ModelNode.get(ModelNode.java:861)
> at org.jboss.as.cli.impl.ValueTypeCompleter$ValueTypeCallbackHandler.getCandidates(ValueTypeCompleter.java:475)
> at org.jboss.as.cli.impl.ValueTypeCompleter.complete(ValueTypeCompleter.java:321)
> at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:254)
> at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:74)
> at org.jboss.as.cli.CommandCompleter.doComplete(CommandCompleter.java:137)
> at org.jboss.as.cli.CommandCompleter.complete(CommandCompleter.java:64)
> at org.jboss.as.cli.impl.Console$Factory$1$1.complete(Console.java:143)
> at org.jboss.aesh.console.AeshCompletionHandler.complete(AeshCompletionHandler.java:155)
> at org.jboss.aesh.console.AeshInputProcessor.complete(AeshInputProcessor.java:427)
> at org.jboss.aesh.console.AeshInputProcessor.parseOperation(AeshInputProcessor.java:165)
> at org.jboss.aesh.console.Console.processInternalOperation(Console.java:773)
> at org.jboss.aesh.console.Console.execute(Console.java:733)
> at org.jboss.aesh.console.Console.access$900(Console.java:73)
> at org.jboss.aesh.console.Console$6.run(Console.java:642)
> 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)
> [mkopecky@dhcp-10-40-5-171 bin]$
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7228) Improve wording in logging message for key WFLYWELD0013
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-7228?page=com.atlassian.jira.plugin.... ]
Brian Stansberry reassigned WFLY-7228:
--------------------------------------
Issue Type: Bug (was: Enhancement)
Component/s: CDI / Weld
Assignee: Stuart Douglas (was: Jason Greene)
I added the component and changed this to 'Bug' which is a simpler issue type to deal with downstream. The repetition of 'deployment' is enough to make this a bug even though it's not the main point.
> Improve wording in logging message for key WFLYWELD0013
> -------------------------------------------------------
>
> Key: WFLY-7228
> URL: https://issues.jboss.org/browse/WFLY-7228
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Reporter: Gunnar Morling
> Assignee: Stuart Douglas
> Priority: Minor
>
> I'm seeing this message:
> {quote}
> WFLYWELD0013: Deployment deployment "demo.war" contains CDI annotations but no bean archive was not found. (No beans.xml nor class with bean defining annotations)
> {quote}
> Apart from the repeated "deployment", the double negation makes it confusing, I reckon it should say something like that:
> {quote}
> WFLYWELD0013: Deployment "demo.war" contains CDI annotations but is not a bean archive (Found no beans.xml nor a class with bean defining annotations)
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (DROOLS-1308) Rules compilation failure depending on condition ordering
by Martin Weiler (JIRA)
Martin Weiler created DROOLS-1308:
-------------------------------------
Summary: Rules compilation failure depending on condition ordering
Key: DROOLS-1308
URL: https://issues.jboss.org/browse/DROOLS-1308
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 6.4.0.Final
Reporter: Martin Weiler
Assignee: Mario Fusco
When creating rules in guided editor, we are running into validation errors depending on the order of the conditions. The problem is that the order of the conditions is important:
{noformat}
when
COND_X
COND_Y => works
when
COND_Y
COND_X => fails
java.lang.AssertionError: [10,18]: [ERR 101] Line 10:18 no viable alternative at input 'Number' in rule "ATO_Negative_AU_Test"
[0,0]: Parser returned a null Package
{noformat}
Test cases showing the compilation failures (@Test testOrder1 vs
testOrder2) can be found here:
https://gist.github.com/martinweiler/e684a0e75a2c9f4de4dee5a13affb8b0
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1824) Can not parse object list attributes that contains a complex attribute
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1824?page=com.atlassian.jira.plugi... ]
Tomaz Cerar updated WFCORE-1824:
--------------------------------
Summary: Can not parse object list attributes that contains a complex attribute (was: Can not parse object attributes that contains a Properties attribute)
> Can not parse object list attributes that contains a complex attribute
> ----------------------------------------------------------------------
>
> Key: WFCORE-1824
> URL: https://issues.jboss.org/browse/WFCORE-1824
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha8
> Reporter: Jeff Mesnil
> Assignee: Tomaz Cerar
>
> My resource defines an attribute which is a LIST of OBJECT that corresponds to a class (class name + module) and Properties that are passed to the created instance:
> {noformat}
> private static final String CLASS = "class";
> private static final String MODULE = "module";
> public static final PropertiesAttributeDefinition PROPERTIES = new PropertiesAttributeDefinition.Builder("properties", true)
> .setAllowExpression(true)
> .build();
> public static final ObjectTypeAttributeDefinition PROCESS_STATE_LISTENER = ObjectTypeAttributeDefinition.Builder.of("process-state-listener",
> SimpleAttributeDefinitionBuilder.create(CLASS, ModelType.STRING, false)
> .setAllowExpression(false)
> .build(),
> SimpleAttributeDefinitionBuilder.create(MODULE, ModelType.STRING, false)
> .setAllowExpression(false)
> .build(),
> PROPERTIES)
> .setRestartAllServices()
> .setAllowNull(true)
> .build();
> public static final AttributeDefinition PROCESS_STATE_LISTENERS = ObjectListAttributeDefinition.Builder.of("listeners", PROCESS_STATE_LISTENER)
> .setAllowNull(false)
> .setRuntimeServiceNotRequired()
> .build();
> {noformat}
> I can create the resource from the CLI:
> {noformat}
> /subsystem=core-management/service=process-state-listeners:add(listeners=[{class=org.foo.Listener, module=org.foo,, properties = {foo = true, bar = ${bar.prop:2}}}])
> {"outcome" => "success"}
> {noformat}
> And the resource and its attribute is properly marshalled to the XML configuration:
> {noformat}
> <process-state-listeners>
> <listeners>
> <process-state-listener class="org.foo.Listener" module="org.foo">
> <properties>
> <property name="foo" value="true"/>
> <property name="bar" value="${bar.prop:2}"/>
> </properties>
> </process-state-listener>
> </listeners>
> </process-state-listeners>
> {noformat}
> However the resource can not be parsed and it fails with the exception:
> {noformat}
> 2016-09-27 14:57:35,285 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131)
> at org.jboss.as.server.ServerService.boot(ServerService.java:355)
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:303)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[118,25]
> Message: WFLYCTL0198: Unexpected element '{urn:jboss:domain:core-management:1.0}properties' encountered
> at org.jboss.as.controller.parsing.ParseUtils.unexpectedElement(ParseUtils.java:89)
> at org.jboss.as.controller.parsing.ParseUtils.requireNoContent(ParseUtils.java:244)
> at org.jboss.as.controller.AttributeParser$5.parseElement(AttributeParser.java:197)
> at org.jboss.as.controller.PersistentResourceXMLDescription.parseAttributes(PersistentResourceXMLDescription.java:208)
> at org.jboss.as.controller.PersistentResourceXMLDescription.parseAttributeGroups(PersistentResourceXMLDescription.java:140)
> at org.jboss.as.controller.PersistentResourceXMLDescription.parse(PersistentResourceXMLDescription.java:117)
> at org.jboss.as.controller.PersistentResourceXMLDescription.parseChildren(PersistentResourceXMLDescription.java:258)
> at org.jboss.as.controller.PersistentResourceXMLDescription.parse(PersistentResourceXMLDescription.java:135)
> at org.wildfly.extension.management.CoreManagementSubsystemParser_1_0.readElement(CoreManagementSubsystemParser_1_0.java:77)
> at org.wildfly.extension.management.CoreManagementSubsystemParser_1_0.readElement(CoreManagementSubsystemParser_1_0.java:50)
> at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
> at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69)
> at org.jboss.as.server.parsing.StandaloneXml_5.parseServerProfile(StandaloneXml_5.java:591)
> at org.jboss.as.server.parsing.StandaloneXml_5.readServerElement(StandaloneXml_5.java:245)
> at org.jboss.as.server.parsing.StandaloneXml_5.readElement(StandaloneXml_5.java:144)
> at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107)
> at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:49)
> at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
> at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69)
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123)
> ... 3 more
> {noformat}
> The code in org.jboss.as.controller.AttributeParser#parseElement:197 to parse a list of objects assumes that the object's value are all represented by XML attributes. In my case, that's not correct as the "properties" attribute is represented by XML elements.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (SECURITY-959) Missing doPrivileged sections in JBossSecurityClient
by Jan Tymel (JIRA)
Jan Tymel created SECURITY-959:
----------------------------------
Summary: Missing doPrivileged sections in JBossSecurityClient
Key: SECURITY-959
URL: https://issues.jboss.org/browse/SECURITY-959
Project: PicketBox
Issue Type: Bug
Components: PicketBox
Affects Versions: PicketBox_5_0_0.Alpha3
Reporter: Jan Tymel
Assignee: Darran Lofthouse
Priority: Blocker
There is a regression introduced by recent PicketBox upgrade (part of [1]). With PicketBox 4.9.7[2] it is possible to run {{performSimpleLogin()}} and {{cleanUp()}} methods of {{JBossSecurityClient}} class with security manager enabled. However; running these methods with PicketBox 5.0.0.Alpha3[3] causes AccessControlException.
PicketBox 4.9.7 is in EAP 7.1.0.DR3, PicketBox 5.0.0.Alpha3 in EAP 7.1.0.DR4 and DR5 => regression against 7.1.0.DR3.
This issue was noticed in consequence of an investigation of failed tests in AS TS run with security manager.
Tests that fail on {{performSimpleLogin()}} method:
* org.jboss.as.test.integration.ee.concurrent.DefaultContextServiceTestCase#testTaskSubmit
* org.jboss.as.test.integration.ee.concurrent.DefaultManagedExecutorServiceTestCase#testTaskSubmit
* org.jboss.as.test.integration.ee.concurrent.DefaultManagedScheduledExecutorServiceTestCase#testTaskSubmit
* org.jboss.as.test.integration.ee.concurrent.DefaultManagedThreadFactoryTestCase#testTaskSubmit
* org.jboss.as.test.integration.ejb.security.RunAsPrincipalTestCase#testAnonymous
* org.jboss.as.test.integration.ejb.security.RunAsPrincipalTestCase#testJackInABox
* org.jboss.as.test.integration.ejb.security.RunAsPrincipalTestCase#testSingletonPostconstructSecurity
* org.jboss.as.test.integration.ejb.security.callerprincipal.GetCallerPrincipalTestCase#testMDBLifecycle
* org.jboss.as.test.integration.ejb.security.singleton.SingletonSecurityTestCase#testInvocationOnSecuredMethodWithCorrectRole
* org.jboss.as.test.integration.ejb.security.singleton.SingletonSecurityTestCase#testInvocationOnSecuredMethodWithInCorrectRole
{{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=DefaultContextServiceTestCase -Dsecurity.manager}}
{code}
SEVERE [org.jboss.arquillian.protocol.jmx.JMXTestRunner] (pool-3-thread-1) Failed: org.jboss.as.test.integration.ee.concurrent.DefaultContextServiceTestCase.testTaskSubmit: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "org.jboss.security.getSecurityContext")" in code source "(vfs:/content/DefaultContextServiceTestCase.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.DefaultContextServiceTestCase.war:main" from Service Module Loader")
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
at org.jboss.security.SecurityContextAssociation.getSecurityContext(SecurityContextAssociation.java:145)
at org.jboss.security.client.JBossSecurityClient.performSimpleLogin(JBossSecurityClient.java:77)
at org.jboss.security.client.SecurityClient.login(SecurityClient.java:74)
at org.jboss.as.test.integration.ee.concurrent.DefaultContextServiceTestCase.testTaskSubmit(DefaultContextServiceTestCase.java:55)
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:498)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:370)
at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
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:498)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38)
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:498)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
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:498)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
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:498)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
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:498)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136)
at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:363)
at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:245)
at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259)
at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:315)
at org.jboss.arquillian.container.test.impl.execution.BeforeLifecycleEventExecuter.on(BeforeLifecycleEventExecuter.java:35)
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:498)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
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:498)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
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:498)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
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:498)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159)
at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:311)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204)
at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:66)
at org.jboss.arquillian.protocol.jmx.JMXTestRunner.doRunTestMethod(JMXTestRunner.java:180)
at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.doRunTestMethod(ArquillianService.java:243)
at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:162)
at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:141)
at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:219)
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:498)
at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
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:498)
at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:1503)
at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:724)
at org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168)
at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950)
at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:75)
at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:70)
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.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:70)
at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149)
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)
{code}
Tests failing on {{cleanUp()}} method:
* org.jboss.as.test.integration.ejb.servlet.ServletUnitTestCase#testEJBServlet
* org.jboss.as.test.integration.ejb.servlet.ServletUnitTestCase#testEJBServletEar
{{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=ServletUnitTestCase -Dsecurity.manager}}
{code}
ERROR [org.jboss.as.test.integration.ejb.servlet.EJBServlet] (default task-1) java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "org.jboss.security.getSecurityContext")" in code source "(vfs:/content/ejb3-servlet.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.ejb3-servlet.war:main" from Service Module Loader")
15:07:52,122 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /ejb3-servlet/EJBServlet: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "org.jboss.security.setSecurityContext")" in code source "(vfs:/content/ejb3-servlet.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.ejb3-servlet.war:main" from Service Module Loader")
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
at org.jboss.security.SecurityContextAssociation.setSecurityContext(SecurityContextAssociation.java:124)
at org.jboss.security.client.JBossSecurityClient.cleanUp(JBossSecurityClient.java:95)
at org.jboss.security.client.SecurityClient.logout(SecurityClient.java:86)
at org.jboss.as.test.integration.ejb.servlet.EJBServlet.processRequest(EJBServlet.java:75)
at org.jboss.as.test.integration.ejb.servlet.EJBServlet.doGet(EJBServlet.java:84)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1668)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1668)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1668)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1668)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:110)
at java.security.AccessController.doPrivileged(Native Method)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:107)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
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)
{code}
[1] https://github.com/wildfly/wildfly-core/pull/1764/files
[2] https://github.com/picketbox/picketbox/blob/v4.9.6.Final/security-jboss-s...
[3] https://github.com/picketbox/picketbox/blob/5.0.0.Alpha3/security-jboss-s...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1832) Missing doPrivileged sections in JBossSecurityClient
by Jan Tymel (JIRA)
Jan Tymel created WFCORE-1832:
---------------------------------
Summary: Missing doPrivileged sections in JBossSecurityClient
Key: WFCORE-1832
URL: https://issues.jboss.org/browse/WFCORE-1832
Project: WildFly Core
Issue Type: Bug
Components: Security
Reporter: Jan Tymel
Assignee: Darran Lofthouse
Priority: Blocker
There is a regression introduced by recent PicketBox upgrade (part of [1]). With PicketBox 4.9.7[2] it is possible to run {{performSimpleLogin()}} and {{cleanUp()}} methods of {{JBossSecurityClient}} class with security manager enabled. However; running these methods with PicketBox 5.0.0.Alpha3[3] causes AccessControlException.
PicketBox 4.9.7 is in EAP 7.1.0.DR3, PicketBox 5.0.0.Alpha3 in EAP 7.1.0.DR4 and DR5 => regression against 7.1.0.DR3.
This issue was noticed in consequence of an investigation of failed tests in AS TS run with security manager.
Tests that fail on {{performSimpleLogin()}} method:
* org.jboss.as.test.integration.ee.concurrent.DefaultContextServiceTestCase#testTaskSubmit
* org.jboss.as.test.integration.ee.concurrent.DefaultManagedExecutorServiceTestCase#testTaskSubmit
* org.jboss.as.test.integration.ee.concurrent.DefaultManagedScheduledExecutorServiceTestCase#testTaskSubmit
* org.jboss.as.test.integration.ee.concurrent.DefaultManagedThreadFactoryTestCase#testTaskSubmit
* org.jboss.as.test.integration.ejb.security.RunAsPrincipalTestCase#testAnonymous
* org.jboss.as.test.integration.ejb.security.RunAsPrincipalTestCase#testJackInABox
* org.jboss.as.test.integration.ejb.security.RunAsPrincipalTestCase#testSingletonPostconstructSecurity
* org.jboss.as.test.integration.ejb.security.callerprincipal.GetCallerPrincipalTestCase#testMDBLifecycle
* org.jboss.as.test.integration.ejb.security.singleton.SingletonSecurityTestCase#testInvocationOnSecuredMethodWithCorrectRole
* org.jboss.as.test.integration.ejb.security.singleton.SingletonSecurityTestCase#testInvocationOnSecuredMethodWithInCorrectRole
{{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=DefaultContextServiceTestCase -Dsecurity.manager}}
{code}
SEVERE [org.jboss.arquillian.protocol.jmx.JMXTestRunner] (pool-3-thread-1) Failed: org.jboss.as.test.integration.ee.concurrent.DefaultContextServiceTestCase.testTaskSubmit: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "org.jboss.security.getSecurityContext")" in code source "(vfs:/content/DefaultContextServiceTestCase.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.DefaultContextServiceTestCase.war:main" from Service Module Loader")
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
at org.jboss.security.SecurityContextAssociation.getSecurityContext(SecurityContextAssociation.java:145)
at org.jboss.security.client.JBossSecurityClient.performSimpleLogin(JBossSecurityClient.java:77)
at org.jboss.security.client.SecurityClient.login(SecurityClient.java:74)
at org.jboss.as.test.integration.ee.concurrent.DefaultContextServiceTestCase.testTaskSubmit(DefaultContextServiceTestCase.java:55)
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:498)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:370)
at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
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:498)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38)
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:498)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
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:498)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
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:498)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
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:498)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136)
at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:363)
at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:245)
at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259)
at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:315)
at org.jboss.arquillian.container.test.impl.execution.BeforeLifecycleEventExecuter.on(BeforeLifecycleEventExecuter.java:35)
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:498)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
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:498)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
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:498)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
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:498)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159)
at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:311)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204)
at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:66)
at org.jboss.arquillian.protocol.jmx.JMXTestRunner.doRunTestMethod(JMXTestRunner.java:180)
at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.doRunTestMethod(ArquillianService.java:243)
at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:162)
at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:141)
at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:219)
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:498)
at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
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:498)
at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:1503)
at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:724)
at org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168)
at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950)
at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:75)
at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:70)
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.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:70)
at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149)
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)
{code}
Tests failing on {{cleanUp()}} method:
* org.jboss.as.test.integration.ejb.servlet.ServletUnitTestCase#testEJBServlet
* org.jboss.as.test.integration.ejb.servlet.ServletUnitTestCase#testEJBServletEar
{{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=ServletUnitTestCase -Dsecurity.manager}}
{code}
ERROR [org.jboss.as.test.integration.ejb.servlet.EJBServlet] (default task-1) java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "org.jboss.security.getSecurityContext")" in code source "(vfs:/content/ejb3-servlet.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.ejb3-servlet.war:main" from Service Module Loader")
15:07:52,122 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /ejb3-servlet/EJBServlet: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "org.jboss.security.setSecurityContext")" in code source "(vfs:/content/ejb3-servlet.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.ejb3-servlet.war:main" from Service Module Loader")
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
at org.jboss.security.SecurityContextAssociation.setSecurityContext(SecurityContextAssociation.java:124)
at org.jboss.security.client.JBossSecurityClient.cleanUp(JBossSecurityClient.java:95)
at org.jboss.security.client.SecurityClient.logout(SecurityClient.java:86)
at org.jboss.as.test.integration.ejb.servlet.EJBServlet.processRequest(EJBServlet.java:75)
at org.jboss.as.test.integration.ejb.servlet.EJBServlet.doGet(EJBServlet.java:84)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1668)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1668)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1668)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1668)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:110)
at java.security.AccessController.doPrivileged(Native Method)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:107)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
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)
{code}
[1] https://github.com/wildfly/wildfly-core/pull/1764/files
[2] https://github.com/picketbox/picketbox/blob/v4.9.6.Final/security-jboss-s...
[3] https://github.com/picketbox/picketbox/blob/5.0.0.Alpha3/security-jboss-s...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-4937) Implement graceful shutdown for transactions
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-4937?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson reassigned WFLY-4937:
-----------------------------------
Assignee: Gytis Trikleris (was: Michael Musgrove)
> Implement graceful shutdown for transactions
> --------------------------------------------
>
> Key: WFLY-4937
> URL: https://issues.jboss.org/browse/WFLY-4937
> Project: WildFly
> Issue Type: Feature Request
> Components: Transactions
> Affects Versions: 10.0.0.Alpha5
> Reporter: Michael Musgrove
> Assignee: Gytis Trikleris
> Fix For: 11.0.0.CR1
>
>
> We will handle suspend for JTA and JTS by disallowing new transactions and then block the suspend thread until the count of active transactions drops to zero. We will also suspend the recovery manager.
> We will *not* do graceful shutdown for the optional XTS subsystem. For example an incoming XTS request for an existing transaction will be blocked.
> Question: should we
> - raise a new JIRA for this XTS case;
> - document the deficiency and see if there are complaints;
> - document the deficiency and fix it in a subsequent release
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1824) Can not parse object attributes that contains a Properties attribute
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1824?page=com.atlassian.jira.plugi... ]
Jeff Mesnil updated WFCORE-1824:
--------------------------------
Description:
My resource defines an attribute which is a LIST of OBJECT that corresponds to a class (class name + module) and Properties that are passed to the created instance:
{noformat}
private static final String CLASS = "class";
private static final String MODULE = "module";
public static final PropertiesAttributeDefinition PROPERTIES = new PropertiesAttributeDefinition.Builder("properties", true)
.setAllowExpression(true)
.build();
public static final ObjectTypeAttributeDefinition PROCESS_STATE_LISTENER = ObjectTypeAttributeDefinition.Builder.of("process-state-listener",
SimpleAttributeDefinitionBuilder.create(CLASS, ModelType.STRING, false)
.setAllowExpression(false)
.build(),
SimpleAttributeDefinitionBuilder.create(MODULE, ModelType.STRING, false)
.setAllowExpression(false)
.build(),
PROPERTIES)
.setRestartAllServices()
.setAllowNull(true)
.build();
public static final AttributeDefinition PROCESS_STATE_LISTENERS = ObjectListAttributeDefinition.Builder.of("listeners", PROCESS_STATE_LISTENER)
.setAllowNull(false)
.setRuntimeServiceNotRequired()
.build();
{noformat}
I can create the resource from the CLI:
{noformat}
/subsystem=core-management/service=process-state-listeners:add(listeners=[{class=org.foo.Listener, module=org.foo,, properties = {foo = true, bar = ${bar.prop:2}}}])
{"outcome" => "success"}
{noformat}
And the resource and its attribute is properly marshalled to the XML configuration:
{noformat}
<process-state-listeners>
<listeners>
<process-state-listener class="org.foo.Listener" module="org.foo">
<properties>
<property name="foo" value="true"/>
<property name="bar" value="${bar.prop:2}"/>
</properties>
</process-state-listener>
</listeners>
</process-state-listeners>
{noformat}
However the resource can not be parsed and it fails with the exception:
{noformat}
2016-09-27 14:57:35,285 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131)
at org.jboss.as.server.ServerService.boot(ServerService.java:355)
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:303)
at java.lang.Thread.run(Thread.java:745)
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[118,25]
Message: WFLYCTL0198: Unexpected element '{urn:jboss:domain:core-management:1.0}properties' encountered
at org.jboss.as.controller.parsing.ParseUtils.unexpectedElement(ParseUtils.java:89)
at org.jboss.as.controller.parsing.ParseUtils.requireNoContent(ParseUtils.java:244)
at org.jboss.as.controller.AttributeParser$5.parseElement(AttributeParser.java:197)
at org.jboss.as.controller.PersistentResourceXMLDescription.parseAttributes(PersistentResourceXMLDescription.java:208)
at org.jboss.as.controller.PersistentResourceXMLDescription.parseAttributeGroups(PersistentResourceXMLDescription.java:140)
at org.jboss.as.controller.PersistentResourceXMLDescription.parse(PersistentResourceXMLDescription.java:117)
at org.jboss.as.controller.PersistentResourceXMLDescription.parseChildren(PersistentResourceXMLDescription.java:258)
at org.jboss.as.controller.PersistentResourceXMLDescription.parse(PersistentResourceXMLDescription.java:135)
at org.wildfly.extension.management.CoreManagementSubsystemParser_1_0.readElement(CoreManagementSubsystemParser_1_0.java:77)
at org.wildfly.extension.management.CoreManagementSubsystemParser_1_0.readElement(CoreManagementSubsystemParser_1_0.java:50)
at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69)
at org.jboss.as.server.parsing.StandaloneXml_5.parseServerProfile(StandaloneXml_5.java:591)
at org.jboss.as.server.parsing.StandaloneXml_5.readServerElement(StandaloneXml_5.java:245)
at org.jboss.as.server.parsing.StandaloneXml_5.readElement(StandaloneXml_5.java:144)
at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107)
at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:49)
at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69)
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123)
... 3 more
{noformat}
The code in org.jboss.as.controller.AttributeParser#parseElement:197 to parse a list of objects assumes that the object's value are all represented by XML attributes. In my case, that's not correct as the "properties" attribute is represented by XML elements.
was:
My resource defines an attribute which is a LIST of OBJECT that corresponds to a class (class name + module) and Properties that are passed to the created instance:
{noformat}
private static final String CLASS = "class";
private static final String MODULE = "module";
public static final PropertiesAttributeDefinition PROPERTIES = new PropertiesAttributeDefinition.Builder("properties", true)
.setAllowExpression(true)
.build();
public static final ObjectTypeAttributeDefinition PROCESS_STATE_LISTENER = ObjectTypeAttributeDefinition.Builder.of("process-state-listener",
SimpleAttributeDefinitionBuilder.create(CLASS, ModelType.STRING, false)
.setAllowExpression(false)
.build(),
SimpleAttributeDefinitionBuilder.create(MODULE, ModelType.STRING, false)
.setAllowExpression(false)
.build(),
PROPERTIES)
.setRestartAllServices()
.setAllowNull(true)
.build();
public static final AttributeDefinition PROCESS_STATE_LISTENERS = ObjectListAttributeDefinition.Builder.of("listeners", PROCESS_STATE_LISTENER)
.setAllowNull(false)
.setRuntimeServiceNotRequired()
.build();
{noformat}
I can create the resource from the CLI:
{noformat}
/subsystem=core-management/service=process-state-listeners:add(listeners=[{class=org.foo.Listener, module=org.foo,, properties = {foo = true, bar = ${bar.prop:2}}}])
{"outcome" => "success"}
{noformat}
And the resource and its attribute is properly marshalled to the XML configuration:
{noformat}
<process-state-listeners>
<listeners>
<process-state-listener class="org.foo.Listener" module="org.foo">
<properties>
<property name="foo" value="true"/>
<property name="bar" value="${bar.prop:2}"/>
</properties>
</process-state-listener>
</listeners>
</process-state-listeners>
{noformat}
However the resource can not be parsed and it fails with the exception:
{noformat}
boss.as.server.parsing.StandaloneXml_5.readElement(StandaloneXml_5.java:144)
at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107)
at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:49)
at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69)
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123)
... 3 more
09:45:00,537 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.{noformat}
The code in org.jboss.as.controller.AttributeParser#parseElement:197 to parse a list of objects assumes that the object's value are all represented by XML attributes. In my case, that's not correct as the "properties" attribute is represented by XML elements.
> Can not parse object attributes that contains a Properties attribute
> --------------------------------------------------------------------
>
> Key: WFCORE-1824
> URL: https://issues.jboss.org/browse/WFCORE-1824
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha8
> Reporter: Jeff Mesnil
> Assignee: Tomaz Cerar
>
> My resource defines an attribute which is a LIST of OBJECT that corresponds to a class (class name + module) and Properties that are passed to the created instance:
> {noformat}
> private static final String CLASS = "class";
> private static final String MODULE = "module";
> public static final PropertiesAttributeDefinition PROPERTIES = new PropertiesAttributeDefinition.Builder("properties", true)
> .setAllowExpression(true)
> .build();
> public static final ObjectTypeAttributeDefinition PROCESS_STATE_LISTENER = ObjectTypeAttributeDefinition.Builder.of("process-state-listener",
> SimpleAttributeDefinitionBuilder.create(CLASS, ModelType.STRING, false)
> .setAllowExpression(false)
> .build(),
> SimpleAttributeDefinitionBuilder.create(MODULE, ModelType.STRING, false)
> .setAllowExpression(false)
> .build(),
> PROPERTIES)
> .setRestartAllServices()
> .setAllowNull(true)
> .build();
> public static final AttributeDefinition PROCESS_STATE_LISTENERS = ObjectListAttributeDefinition.Builder.of("listeners", PROCESS_STATE_LISTENER)
> .setAllowNull(false)
> .setRuntimeServiceNotRequired()
> .build();
> {noformat}
> I can create the resource from the CLI:
> {noformat}
> /subsystem=core-management/service=process-state-listeners:add(listeners=[{class=org.foo.Listener, module=org.foo,, properties = {foo = true, bar = ${bar.prop:2}}}])
> {"outcome" => "success"}
> {noformat}
> And the resource and its attribute is properly marshalled to the XML configuration:
> {noformat}
> <process-state-listeners>
> <listeners>
> <process-state-listener class="org.foo.Listener" module="org.foo">
> <properties>
> <property name="foo" value="true"/>
> <property name="bar" value="${bar.prop:2}"/>
> </properties>
> </process-state-listener>
> </listeners>
> </process-state-listeners>
> {noformat}
> However the resource can not be parsed and it fails with the exception:
> {noformat}
> 2016-09-27 14:57:35,285 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131)
> at org.jboss.as.server.ServerService.boot(ServerService.java:355)
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:303)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[118,25]
> Message: WFLYCTL0198: Unexpected element '{urn:jboss:domain:core-management:1.0}properties' encountered
> at org.jboss.as.controller.parsing.ParseUtils.unexpectedElement(ParseUtils.java:89)
> at org.jboss.as.controller.parsing.ParseUtils.requireNoContent(ParseUtils.java:244)
> at org.jboss.as.controller.AttributeParser$5.parseElement(AttributeParser.java:197)
> at org.jboss.as.controller.PersistentResourceXMLDescription.parseAttributes(PersistentResourceXMLDescription.java:208)
> at org.jboss.as.controller.PersistentResourceXMLDescription.parseAttributeGroups(PersistentResourceXMLDescription.java:140)
> at org.jboss.as.controller.PersistentResourceXMLDescription.parse(PersistentResourceXMLDescription.java:117)
> at org.jboss.as.controller.PersistentResourceXMLDescription.parseChildren(PersistentResourceXMLDescription.java:258)
> at org.jboss.as.controller.PersistentResourceXMLDescription.parse(PersistentResourceXMLDescription.java:135)
> at org.wildfly.extension.management.CoreManagementSubsystemParser_1_0.readElement(CoreManagementSubsystemParser_1_0.java:77)
> at org.wildfly.extension.management.CoreManagementSubsystemParser_1_0.readElement(CoreManagementSubsystemParser_1_0.java:50)
> at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
> at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69)
> at org.jboss.as.server.parsing.StandaloneXml_5.parseServerProfile(StandaloneXml_5.java:591)
> at org.jboss.as.server.parsing.StandaloneXml_5.readServerElement(StandaloneXml_5.java:245)
> at org.jboss.as.server.parsing.StandaloneXml_5.readElement(StandaloneXml_5.java:144)
> at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107)
> at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:49)
> at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
> at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69)
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123)
> ... 3 more
> {noformat}
> The code in org.jboss.as.controller.AttributeParser#parseElement:197 to parse a list of objects assumes that the object's value are all represented by XML attributes. In my case, that's not correct as the "properties" attribute is represented by XML elements.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1164) Warning about private module use issued twice
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1164?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1164:
-------------------------------------------------
Ivo Hradek <ihradek(a)redhat.com> changed the Status of [bug 1365668|https://bugzilla.redhat.com/show_bug.cgi?id=1365668] from ON_QA to VERIFIED
> Warning about private module use issued twice
> ---------------------------------------------
>
> Key: WFCORE-1164
> URL: https://issues.jboss.org/browse/WFCORE-1164
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Reporter: Frank Langelage
> Assignee: Stuart Douglas
> Priority: Minor
> Fix For: 2.0.4.Final
>
> Attachments: test.war
>
>
> My web app is using some modules of WildFly AS which are not public.
> The warning about using private modules is issued twice for every module:
> 09.11. 22:07:34,088 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.jboss.common-core:main") which may be changed or removed in future versions without notice.
> 09.11. 22:07:34,090 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.jboss.common-core:main") which may be changed or removed in future versions without notice.
> 09.11. 22:07:34,091 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.apache.commons.collections:main") which may be changed or removed in future versions without notice.
> 09.11. 22:07:34,091 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.apache.commons.collections:main") which may be changed or removed in future versions without notice.
> 09.11. 22:07:34,092 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.apache.cxf.impl:main") which may be changed or removed in future versions without notice.
> 09.11. 22:07:34,094 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.apache.cxf.impl:main") which may be changed or removed in future versions without notice.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1831) Build XML parser from a resource's pathElement
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1831?page=com.atlassian.jira.plugi... ]
Tomaz Cerar updated WFCORE-1831:
--------------------------------
Fix Version/s: 3.0.0.Alpha9
> Build XML parser from a resource's pathElement
> ----------------------------------------------
>
> Key: WFCORE-1831
> URL: https://issues.jboss.org/browse/WFCORE-1831
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha8
> Reporter: Jeff Mesnil
> Assignee: Tomaz Cerar
> Fix For: 3.0.0.Alpha9
>
>
> The current PersistentResourceXMLBuilder API requires to pass a ResourceDefinition to build the XML representation to parse and marshall. This requires to provides static ResourceDefinition which may be impratical if the resource model can be affected by the runtime state.
> The PersistentResourceXMLDescription only relies on the resourceDefinition's pathElement to know the "name" of the resource. The list of attributes to map to XML is provided explicitly to the builder.
> The PersistentResourceXMLBuilder API should be modified to use only a PathElement and remove its reference to resourceDefinition.
> For compatibility the current builder method with PersistentResourceDefinition must be kept and delegate to the new one.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1831) Build XML parser from a resource's pathElement
by Jeff Mesnil (JIRA)
Jeff Mesnil created WFCORE-1831:
-----------------------------------
Summary: Build XML parser from a resource's pathElement
Key: WFCORE-1831
URL: https://issues.jboss.org/browse/WFCORE-1831
Project: WildFly Core
Issue Type: Enhancement
Components: Domain Management
Affects Versions: 3.0.0.Alpha8
Reporter: Jeff Mesnil
Assignee: Brian Stansberry
The current PersistentResourceXMLBuilder API requires to pass a ResourceDefinition to build the XML representation to parse and marshall. This requires to provides static ResourceDefinition which may be impratical if the resource model can be affected by the runtime state.
The PersistentResourceXMLDescription only relies on the resourceDefinition's pathElement to know the "name" of the resource. The list of attributes to map to XML is provided explicitly to the builder.
The PersistentResourceXMLBuilder API should be modified to use only a PathElement and remove its reference to resourceDefinition.
For compatibility the current builder method with PersistentResourceDefinition must be kept and delegate to the new one.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1831) Build XML parser from a resource's pathElement
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1831?page=com.atlassian.jira.plugi... ]
Jeff Mesnil reassigned WFCORE-1831:
-----------------------------------
Assignee: Tomaz Cerar (was: Brian Stansberry)
> Build XML parser from a resource's pathElement
> ----------------------------------------------
>
> Key: WFCORE-1831
> URL: https://issues.jboss.org/browse/WFCORE-1831
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha8
> Reporter: Jeff Mesnil
> Assignee: Tomaz Cerar
>
> The current PersistentResourceXMLBuilder API requires to pass a ResourceDefinition to build the XML representation to parse and marshall. This requires to provides static ResourceDefinition which may be impratical if the resource model can be affected by the runtime state.
> The PersistentResourceXMLDescription only relies on the resourceDefinition's pathElement to know the "name" of the resource. The list of attributes to map to XML is provided explicitly to the builder.
> The PersistentResourceXMLBuilder API should be modified to use only a PathElement and remove its reference to resourceDefinition.
> For compatibility the current builder method with PersistentResourceDefinition must be kept and delegate to the new one.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7229) WFLYCLWEBUT0001 for server-side invalidated sessions
by Michał Nowakowski (JIRA)
Michał Nowakowski created WFLY-7229:
---------------------------------------
Summary: WFLYCLWEBUT0001 for server-side invalidated sessions
Key: WFLY-7229
URL: https://issues.jboss.org/browse/WFLY-7229
Project: WildFly
Issue Type: Feature Request
Components: Web (Undertow)
Affects Versions: 10.1.0.Final
Environment: Happens whenever <distributable/> is used in web.xml, both in standalone and domain modes.
Reporter: Michał Nowakowski
Assignee: Stuart Douglas
Attachments: stacktrace_01.txt, stacktrace_02.txt, stacktrace_03.txt, testPortlet.tar.gz
Attached is a simple webapp (pardon the name) with a single servlet "/main", that does the following:
- a session is assigned (or created, if none existed before)
- its details are printed and the browser is told to refresh after 20 seconds
- before the browser refreshes, the session is invalidated server-side by separate thread.
Expected behaviour is, that WF should give the user a new session. That's indeed how it works in standalone mode and without <distributable/> in web.xml. But in domain mode, OR with <distributable/> added (and, possibly, full-ha profile chosen), I get errors:
- The first stacktrace happens when the thread invalidates the session.
- The second stacktrace happens, when the browser refreshes. The user sees "Error 500".
- The, after a minute or so, I get the last one. It then repeats periodically.
We can't upgrade from 10.0 because of this - and we know we need an upgrade because of fixes in Infinispan.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7228) Improve wording in logging message for key WFLYWELD0013
by Gunnar Morling (JIRA)
[ https://issues.jboss.org/browse/WFLY-7228?page=com.atlassian.jira.plugin.... ]
Gunnar Morling updated WFLY-7228:
---------------------------------
Summary: Improve wording in logging message for key WFLYWELD0013 (was: Improve wording in Weld logging message for key WFLYWELD0013)
> Improve wording in logging message for key WFLYWELD0013
> -------------------------------------------------------
>
> Key: WFLY-7228
> URL: https://issues.jboss.org/browse/WFLY-7228
> Project: WildFly
> Issue Type: Enhancement
> Reporter: Gunnar Morling
> Assignee: Jason Greene
> Priority: Minor
>
> I'm seeing this message:
> {quote}
> WFLYWELD0013: Deployment deployment "demo.war" contains CDI annotations but no bean archive was not found. (No beans.xml nor class with bean defining annotations)
> {quote}
> Apart from the repeated "deployment", the double negation makes it confusing, I reckon it should say something like that:
> {quote}
> WFLYWELD0013: Deployment "demo.war" contains CDI annotations but is not a bean archive (Found no beans.xml nor a class with bean defining annotations)
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7228) Improve wording in Weld logging message for key WFLYWELD0013
by Gunnar Morling (JIRA)
[ https://issues.jboss.org/browse/WFLY-7228?page=com.atlassian.jira.plugin.... ]
Gunnar Morling updated WFLY-7228:
---------------------------------
Priority: Minor (was: Major)
> Improve wording in Weld logging message for key WFLYWELD0013
> ------------------------------------------------------------
>
> Key: WFLY-7228
> URL: https://issues.jboss.org/browse/WFLY-7228
> Project: WildFly
> Issue Type: Enhancement
> Reporter: Gunnar Morling
> Assignee: Jason Greene
> Priority: Minor
>
> I'm seeing this message:
> {quote}
> WFLYWELD0013: Deployment deployment "demo.war" contains CDI annotations but no bean archive was not found. (No beans.xml nor class with bean defining annotations)
> {quote}
> Apart from the repeated "deployment", the double negation makes it confusing, I reckon it should say something like that:
> {quote}
> WFLYWELD0013: Deployment "demo.war" contains CDI annotations but is not a bean archive (Found no beans.xml nor a class with bean defining annotations)
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7228) Improve wording in Weld logging message for key WFLYWELD0013
by Gunnar Morling (JIRA)
Gunnar Morling created WFLY-7228:
------------------------------------
Summary: Improve wording in Weld logging message for key WFLYWELD0013
Key: WFLY-7228
URL: https://issues.jboss.org/browse/WFLY-7228
Project: WildFly
Issue Type: Enhancement
Reporter: Gunnar Morling
Assignee: Jason Greene
I'm seeing this message:
{quote}
WFLYWELD0013: Deployment deployment "demo.war" contains CDI annotations but no bean archive was not found. (No beans.xml nor class with bean defining annotations)
{quote}
Apart from the repeated "deployment", the double negation makes it confusing, I reckon it should say something like that:
{quote}
WFLYWELD0013: Deployment "demo.war" contains CDI annotations but is not a bean archive (Found no beans.xml nor a class with bean defining annotations)
{quote}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (ELY-643) On the SSLContextBuilder support setUseCipherSuitesOrder
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-643?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina updated ELY-643:
---------------------------
Summary: On the SSLContextBuilder support setUseCipherSuitesOrder (was: On the SSLContextBuilder support setUserCipherSuiteOrder)
> On the SSLContextBuilder support setUseCipherSuitesOrder
> --------------------------------------------------------
>
> Key: ELY-643
> URL: https://issues.jboss.org/browse/ELY-643
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: SSL
> Reporter: Darran Lofthouse
> Assignee: Jan Kalina
> Priority: Critical
> Fix For: 1.1.0.Beta10
>
>
> Currently we hard code this value to 'true' which should remain the default as the OpenSSL style cipher suite selection includes preferred mechanism ordering - however it should be possible to override this and set it to false.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JGRP-2038) RpcDipatcher: calls with CompletableFuture don't respect timeout
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2038?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2038:
---------------------------
Description: When calling {{RpcDispatcher.callRemoteMethodsWithFuture()}}, a timeout passed via RequestOptions is not respected; calls don't timeout out if any of the members doesn't reply. (was: When calling {{RpsDispatcher.callRemoteMethodsWithFuture()}}, a timeout passed via RequestOptions is not respected; calls don't timeout out if any of the members doesn't reply.)
> RpcDipatcher: calls with CompletableFuture don't respect timeout
> ----------------------------------------------------------------
>
> Key: JGRP-2038
> URL: https://issues.jboss.org/browse/JGRP-2038
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> When calling {{RpcDispatcher.callRemoteMethodsWithFuture()}}, a timeout passed via RequestOptions is not respected; calls don't timeout out if any of the members doesn't reply.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JBJCA-1333) Add protection in DsXmlDeployer to prevent from loading xml resource
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1333?page=com.atlassian.jira.plugin... ]
Stefano Maestri resolved JBJCA-1333.
------------------------------------
Resolution: Done
> Add protection in DsXmlDeployer to prevent from loading xml resource
> --------------------------------------------------------------------
>
> Key: JBJCA-1333
> URL: https://issues.jboss.org/browse/JBJCA-1333
> Project: IronJacamar
> Issue Type: Enhancement
> Components: Deployer
> Affects Versions: 1.2.7.Final
> Reporter: COLLIGNON Thomas
> Assignee: Stefano Maestri
> Priority: Minor
> Fix For: 1.2.8.Final
>
>
> If we place a datasource.xml in a jar file, the class DsXmlDeployer will fail with "URI not hierarchical error", because it doesn't handle jar file.
> The goal of this issue is prevent for loading jar file in DsXmlDeployer.
> The second goal is to provide ability of overring DsXmlDeployer in custom deployer who extends this class.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1830) Upgrade MSC from 1.2.6.Final-redhat-1 to 1.2.7.Final
by Ivo Studensky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1830?page=com.atlassian.jira.plugi... ]
Ivo Studensky moved JBEAP-6219 to WFCORE-1830:
----------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-1830 (was: JBEAP-6219)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Domain Management
(was: MSC)
Affects Version/s: 3.0.0.Alpha8
(was: 7.0.0.ER1)
> Upgrade MSC from 1.2.6.Final-redhat-1 to 1.2.7.Final
> ----------------------------------------------------
>
> Key: WFCORE-1830
> URL: https://issues.jboss.org/browse/WFCORE-1830
> Project: WildFly Core
> Issue Type: Component Upgrade
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha8
> Reporter: Ivo Studensky
> Assignee: David Lloyd
>
> This is an upgrade jira for MSC component. See the referenced issues that need to get in.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7226) Missing realm-map attribute for mapped-regex-realm-mapper throws IllegalArgumentException to server log
by Ondrej Lukas (JIRA)
Ondrej Lukas created WFLY-7226:
----------------------------------
Summary: Missing realm-map attribute for mapped-regex-realm-mapper throws IllegalArgumentException to server log
Key: WFLY-7226
URL: https://issues.jboss.org/browse/WFLY-7226
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Ondrej Lukas
Assignee: Darran Lofthouse
In case when mapped-regex-realm-mapper is added through CLI and realm-map attribute is not used then IllegalArgumentException is thrown to server log instead of some CLI failure message like "realm-map may not be null".
Expcetion in server log:
{code}
ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "elytron"),
("mapped-regex-realm-mapper" => "MappedRealmMapper")
]): java.lang.IllegalArgumentException
at org.jboss.dmr.ModelValue.getKeys(ModelValue.java:139)
at org.jboss.dmr.ModelNode.keys(ModelNode.java:1378)
at org.wildfly.extension.elytron.RealmMapperDefinitions$MappedRegexRealmMapperAddHandler.performRuntime(RealmMapperDefinitions.java:221)
at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337)
at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
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}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7226) Missing realm-map attribute for mapped-regex-realm-mapper throws IllegalArgumentException to server log
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7226?page=com.atlassian.jira.plugin.... ]
Ondrej Lukas updated WFLY-7226:
-------------------------------
Affects Version/s: 11.0.0.Alpha1
> Missing realm-map attribute for mapped-regex-realm-mapper throws IllegalArgumentException to server log
> -------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7226
> URL: https://issues.jboss.org/browse/WFLY-7226
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
>
> In case when mapped-regex-realm-mapper is added through CLI and realm-map attribute is not used then IllegalArgumentException is thrown to server log instead of some CLI failure message like "realm-map may not be null".
> Expcetion in server log:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("mapped-regex-realm-mapper" => "MappedRealmMapper")
> ]): java.lang.IllegalArgumentException
> at org.jboss.dmr.ModelValue.getKeys(ModelValue.java:139)
> at org.jboss.dmr.ModelNode.keys(ModelNode.java:1378)
> at org.wildfly.extension.elytron.RealmMapperDefinitions$MappedRegexRealmMapperAddHandler.performRuntime(RealmMapperDefinitions.java:221)
> at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337)
> at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> 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}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7225) Writing wrong realm-mapper to security-domain causes failures after reload
by Ondrej Lukas (JIRA)
Ondrej Lukas created WFLY-7225:
----------------------------------
Summary: Writing wrong realm-mapper to security-domain causes failures after reload
Key: WFLY-7225
URL: https://issues.jboss.org/browse/WFLY-7225
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Ondrej Lukas
Assignee: Darran Lofthouse
In case when write-attribute operation to security-domain is used for some realm-mapper with pattern which does not include a capture group, then operation succeeded. However after server reload/restart exception occurs in server log and affected security domain does not start correctly.
Suggestion:
Writing wrong realm-mapper to security-domain should be denied.
Issue can be related to JBEAP-6214.
Exceptions in server log:
{code}
ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service org.wildfly.security.realm-mapper.SomeRealmMapper: org.jboss.msc.service.StartException in service org.wildfly.security.realm-mapper.SomeRealmMapper: 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.IllegalArgumentException: ELY01065: Pattern requires a capture group
at org.wildfly.security.auth.util.SimpleRegexRealmMapper.<init>(SimpleRegexRealmMapper.java:64)
at org.wildfly.security.auth.util.SimpleRegexRealmMapper.<init>(SimpleRegexRealmMapper.java:49)
at org.wildfly.extension.elytron.RealmMapperDefinitions$SimpleRegexRealmMapperAddHandler.lambda$performRuntime$0(RealmMapperDefinitions.java:157)
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
...
ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "elytron"),
("security-domain" => "SomeSecurityDomain")
]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined}
07:29:21,263 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "elytron"),
("simple-regex-realm-mapper" => "SomeRealmMapper")
]) - failure description: {
"WFLYCTL0080: Failed services" => {"org.wildfly.security.realm-mapper.SomeRealmMapper" => "org.jboss.msc.service.StartException in service org.wildfly.security.realm-mapper.SomeRealmMapper: Failed to start service
Caused by: java.lang.IllegalArgumentException: ELY01065: Pattern requires a capture group"},
"WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.realm-mapper.SomeRealmMapper"],
"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
}
...
ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha8-redhat-2) started (with errors) in 616ms - Started 351 of 601 services (2 services failed or missing dependencies, 399 services are lazy, passive or on-demand)
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7225) Writing wrong realm-mapper to security-domain causes failures after reload
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7225?page=com.atlassian.jira.plugin.... ]
Ondrej Lukas updated WFLY-7225:
-------------------------------
Affects Version/s: 11.0.0.Alpha1
> Writing wrong realm-mapper to security-domain causes failures after reload
> --------------------------------------------------------------------------
>
> Key: WFLY-7225
> URL: https://issues.jboss.org/browse/WFLY-7225
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
>
> In case when write-attribute operation to security-domain is used for some realm-mapper with pattern which does not include a capture group, then operation succeeded. However after server reload/restart exception occurs in server log and affected security domain does not start correctly.
> Suggestion:
> Writing wrong realm-mapper to security-domain should be denied.
> Issue can be related to JBEAP-6214.
> Exceptions in server log:
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service org.wildfly.security.realm-mapper.SomeRealmMapper: org.jboss.msc.service.StartException in service org.wildfly.security.realm-mapper.SomeRealmMapper: 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.IllegalArgumentException: ELY01065: Pattern requires a capture group
> at org.wildfly.security.auth.util.SimpleRegexRealmMapper.<init>(SimpleRegexRealmMapper.java:64)
> at org.wildfly.security.auth.util.SimpleRegexRealmMapper.<init>(SimpleRegexRealmMapper.java:49)
> at org.wildfly.extension.elytron.RealmMapperDefinitions$SimpleRegexRealmMapperAddHandler.lambda$performRuntime$0(RealmMapperDefinitions.java:157)
> 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
> ...
> ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("security-domain" => "SomeSecurityDomain")
> ]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined}
> 07:29:21,263 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("simple-regex-realm-mapper" => "SomeRealmMapper")
> ]) - failure description: {
> "WFLYCTL0080: Failed services" => {"org.wildfly.security.realm-mapper.SomeRealmMapper" => "org.jboss.msc.service.StartException in service org.wildfly.security.realm-mapper.SomeRealmMapper: Failed to start service
> Caused by: java.lang.IllegalArgumentException: ELY01065: Pattern requires a capture group"},
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.realm-mapper.SomeRealmMapper"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> }
> ...
> ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha8-redhat-2) started (with errors) in 616ms - Started 351 of 601 services (2 services failed or missing dependencies, 399 services are lazy, passive or on-demand)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7224) Missing validation check for simple-regex-realm-mapper and mapped-regex-realm-mapper in Elytron subsystem
by Ondrej Lukas (JIRA)
Ondrej Lukas created WFLY-7224:
----------------------------------
Summary: Missing validation check for simple-regex-realm-mapper and mapped-regex-realm-mapper in Elytron subsystem
Key: WFLY-7224
URL: https://issues.jboss.org/browse/WFLY-7224
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Ondrej Lukas
Assignee: Darran Lofthouse
Elytron subsystem allows to add realm mapper (e.g. simple-regex-realm-mapper) with pattern which does not include a capture group. In case when this realm mapper is used in add operation for security domain through CLI then operation fails with incomprehensible log:
{code}
{
"outcome" => "failed",
"failure-description" => {"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined},
"rolled-back" => true
}
{code}
Exception in server log:
{code}
ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.security.realm-mapper.SomeRealmMapper: org.jboss.msc.service.StartException in service org.wildfly.security.realm-mapper.SomeRealmMapper: 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.IllegalArgumentException: ELY01065: Pattern requires a capture group
at org.wildfly.security.auth.util.SimpleRegexRealmMapper.<init>(SimpleRegexRealmMapper.java:64)
at org.wildfly.security.auth.util.SimpleRegexRealmMapper.<init>(SimpleRegexRealmMapper.java:49)
at org.wildfly.extension.elytron.RealmMapperDefinitions$SimpleRegexRealmMapperAddHandler.lambda$performRuntime$0(RealmMapperDefinitions.java:157)
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}
The same happens for mapped-regex-realm-mapper.
Point here is that we allow to successfully add wrong realm mapper (without capture group) but we check whether it is wrong later in security domain. This check should be done during adding wrong realm mapper to avoid following incomprehensible CLI log and exception in server log.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7224) Missing validation check for simple-regex-realm-mapper and mapped-regex-realm-mapper in Elytron subsystem
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7224?page=com.atlassian.jira.plugin.... ]
Ondrej Lukas updated WFLY-7224:
-------------------------------
Affects Version/s: 11.0.0.Alpha1
> Missing validation check for simple-regex-realm-mapper and mapped-regex-realm-mapper in Elytron subsystem
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7224
> URL: https://issues.jboss.org/browse/WFLY-7224
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
>
> Elytron subsystem allows to add realm mapper (e.g. simple-regex-realm-mapper) with pattern which does not include a capture group. In case when this realm mapper is used in add operation for security domain through CLI then operation fails with incomprehensible log:
> {code}
> {
> "outcome" => "failed",
> "failure-description" => {"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined},
> "rolled-back" => true
> }
> {code}
> Exception in server log:
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.security.realm-mapper.SomeRealmMapper: org.jboss.msc.service.StartException in service org.wildfly.security.realm-mapper.SomeRealmMapper: 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.IllegalArgumentException: ELY01065: Pattern requires a capture group
> at org.wildfly.security.auth.util.SimpleRegexRealmMapper.<init>(SimpleRegexRealmMapper.java:64)
> at org.wildfly.security.auth.util.SimpleRegexRealmMapper.<init>(SimpleRegexRealmMapper.java:49)
> at org.wildfly.extension.elytron.RealmMapperDefinitions$SimpleRegexRealmMapperAddHandler.lambda$performRuntime$0(RealmMapperDefinitions.java:157)
> 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}
> The same happens for mapped-regex-realm-mapper.
> Point here is that we allow to successfully add wrong realm mapper (without capture group) but we check whether it is wrong later in security domain. This check should be done during adding wrong realm mapper to avoid following incomprehensible CLI log and exception in server log.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7223) Allow server to start in suspended mode
by Stuart Douglas (JIRA)
Stuart Douglas created WFLY-7223:
------------------------------------
Summary: Allow server to start in suspended mode
Key: WFLY-7223
URL: https://issues.jboss.org/browse/WFLY-7223
Project: WildFly
Issue Type: Bug
Reporter: Stuart Douglas
Assignee: Stuart Douglas
It should be possible to start the server in suspended mode. In addition to this as part of normal startup the server should be suspended until the MSC service container hits stability. This will fix a lot of the graceful startup issues that have been reported.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7220) Undertow .xsd queue-size attribute definition discrepancy
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFLY-7220?page=com.atlassian.jira.plugin.... ]
Chao Wang moved JBEAP-6211 to WFLY-7220:
----------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7220 (was: JBEAP-6211)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Web (Undertow)
(was: Web (Undertow))
Affects Version/s: 10.1.0.Final
(was: 7.1.0.DR4)
> Undertow .xsd queue-size attribute definition discrepancy
> ---------------------------------------------------------
>
> Key: WFLY-7220
> URL: https://issues.jboss.org/browse/WFLY-7220
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.1.0.Final
> Reporter: Chao Wang
> Assignee: Chao Wang
> Priority: Minor
>
> With fix for JBEAP-3668 there was introduced discrepancy between model in Java code and {{wildfly-undertow_4_0.xsd}}.
> Currently {{/subsystem=undertow/configuration=filter/request-limit\[queue-size\]}} is set to 0 by default but this change is not reflected in the mentioned .xsd file. {{.xsd}} should be updated appropriately to keep in sync with what is implemented in java.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7212) Cannot use BMT in @Schedule service
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7212?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-7212:
--------------------------------------
If you want a non-vendor specific way make the @Schedule bean use BMT and then you can control it via UserTransaction.
> Cannot use BMT in @Schedule service
> -----------------------------------
>
> Key: WFLY-7212
> URL: https://issues.jboss.org/browse/WFLY-7212
> Project: WildFly
> Issue Type: Feature Request
> Components: EE, EJB, Transactions
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Environment: Wildfly 10.1.0-Final. Windows 10. MySql 5.5.
> Reporter: Karl Nicholas
> Labels: arjuna, ejb, scheduled, scheduled_tasks, transaction
>
> When injecting a `@Resource private UserTransaction tx;`, a `TransactionReaper` terminates kills my `UserTransaction` after 5 minutes no matter what. Since it's a batch update, I need more than 5 minutes.
> Here is a simple piece of code that doesn't work:
> {code:java}
> @EJB private TestFiveMinuteBatch testFiveMinuteBatch;
> @Schedule(second="0", minute="8", hour="10", persistent=false) // 03:30 am (12:30 am CA ) every day
> public void updateTest() {
> testFiveMinuteBatch.test();
> }
> @Stateless
> @TransactionManagement(TransactionManagementType.BEAN)
> public class TestFiveMinuteBatch {
> @Resource private UserTransaction tx;
> public void test() {
> for ( int i=0; i < 6; ++i ) {
> System.out.println("Minute: " + i);
> try {
> Thread.sleep(60000);
> } catch (InterruptedException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
> }
> }
> }
> {code}
> After 5 minutes I get this warning:
> {noformat}
> 10:13:00,034 WARN [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffffac1f6209:-595568e4:57e80419:e in state RUN
> 10:13:00,039 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012121: TransactionReaper::doCancellations worker Thread[Transaction Reaper Worker 0,5,main] successfully canceled TX 0:ffffac1f6209:-595568e4:57e80419:e
> 10:13:00,130 INFO [stdout] (EJB default - 1) Minute: 5
> {noformat}
> After service terminates I get this error:
> {noformat}
> 10:14:00,131 WARN [com.arjuna.ats.arjuna] (EJB default - 1) ARJUNA012077: Abort called on already aborted atomic action 0:ffffac1f6209:-595568e4:57e80419:e
> 10:14:00,163 ERROR [org.jboss.as.ejb3.timer] (EJB default - 1) WFLYEJB0020: Error invoking timeout for timer: [id=8a8f4546-28d0-491e-85a6-f668f58ab5dc timedObjectId=opca-ear.opca-ejb.ScheduledService auto-timer?:true persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@31fe8c3e initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Mon Sep 26 10:08:00 PDT 2016 timerState=IN_TIMEOUT info=null]: javax.ejb.EJBTransactionRolledbackException: Transaction rolled back
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleEndTransactionException(CMTTxInterceptor.java:137)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:117)
> at org.jboss.as.ejb3.tx.TimerCMTTxInterceptor.endTransaction(TimerCMTTxInterceptor.java:67)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:279)
> 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.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:110)
> 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.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.ejb3.timerservice.TimedObjectInvokerImpl.callTimeout(TimedObjectInvokerImpl.java:99)
> at org.jboss.as.ejb3.timerservice.CalendarTimerTask.invokeBeanMethod(CalendarTimerTask.java:64)
> at org.jboss.as.ejb3.timerservice.CalendarTimerTask.callTimeout(CalendarTimerTask.java:53)
> at org.jboss.as.ejb3.timerservice.TimerTask.run(TimerTask.java:157)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl$Task$1.run(TimerServiceImpl.java:1215)
> at org.wildfly.extension.requestcontroller.RequestController$QueuedTask$1.run(RequestController.java:497)
> 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)
> Caused by: javax.transaction.RollbackException: WFLYEJB0447: Transaction 'TransactionImple < ac, BasicAction: 0:ffffac1f6209:-595568e4:57e80419:e status: ActionStatus.ABORTED >' was already rolled back
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:98)
> ... 38 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7212) Cannot use BMT in @Schedule service
by Karl Nicholas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7212?page=com.atlassian.jira.plugin.... ]
Karl Nicholas commented on WFLY-7212:
-------------------------------------
Yes, ok, that's working:
@TransactionTimeout(value=1, unit = TimeUnit.HOURS)
Vender specific, but that's better than not working. Thank you for your time.
> Cannot use BMT in @Schedule service
> -----------------------------------
>
> Key: WFLY-7212
> URL: https://issues.jboss.org/browse/WFLY-7212
> Project: WildFly
> Issue Type: Feature Request
> Components: EE, EJB, Transactions
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Environment: Wildfly 10.1.0-Final. Windows 10. MySql 5.5.
> Reporter: Karl Nicholas
> Labels: arjuna, ejb, scheduled, scheduled_tasks, transaction
>
> When injecting a `@Resource private UserTransaction tx;`, a `TransactionReaper` terminates kills my `UserTransaction` after 5 minutes no matter what. Since it's a batch update, I need more than 5 minutes.
> Here is a simple piece of code that doesn't work:
> {code:java}
> @EJB private TestFiveMinuteBatch testFiveMinuteBatch;
> @Schedule(second="0", minute="8", hour="10", persistent=false) // 03:30 am (12:30 am CA ) every day
> public void updateTest() {
> testFiveMinuteBatch.test();
> }
> @Stateless
> @TransactionManagement(TransactionManagementType.BEAN)
> public class TestFiveMinuteBatch {
> @Resource private UserTransaction tx;
> public void test() {
> for ( int i=0; i < 6; ++i ) {
> System.out.println("Minute: " + i);
> try {
> Thread.sleep(60000);
> } catch (InterruptedException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
> }
> }
> }
> {code}
> After 5 minutes I get this warning:
> {noformat}
> 10:13:00,034 WARN [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffffac1f6209:-595568e4:57e80419:e in state RUN
> 10:13:00,039 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012121: TransactionReaper::doCancellations worker Thread[Transaction Reaper Worker 0,5,main] successfully canceled TX 0:ffffac1f6209:-595568e4:57e80419:e
> 10:13:00,130 INFO [stdout] (EJB default - 1) Minute: 5
> {noformat}
> After service terminates I get this error:
> {noformat}
> 10:14:00,131 WARN [com.arjuna.ats.arjuna] (EJB default - 1) ARJUNA012077: Abort called on already aborted atomic action 0:ffffac1f6209:-595568e4:57e80419:e
> 10:14:00,163 ERROR [org.jboss.as.ejb3.timer] (EJB default - 1) WFLYEJB0020: Error invoking timeout for timer: [id=8a8f4546-28d0-491e-85a6-f668f58ab5dc timedObjectId=opca-ear.opca-ejb.ScheduledService auto-timer?:true persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@31fe8c3e initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Mon Sep 26 10:08:00 PDT 2016 timerState=IN_TIMEOUT info=null]: javax.ejb.EJBTransactionRolledbackException: Transaction rolled back
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleEndTransactionException(CMTTxInterceptor.java:137)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:117)
> at org.jboss.as.ejb3.tx.TimerCMTTxInterceptor.endTransaction(TimerCMTTxInterceptor.java:67)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:279)
> 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.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:110)
> 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.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.ejb3.timerservice.TimedObjectInvokerImpl.callTimeout(TimedObjectInvokerImpl.java:99)
> at org.jboss.as.ejb3.timerservice.CalendarTimerTask.invokeBeanMethod(CalendarTimerTask.java:64)
> at org.jboss.as.ejb3.timerservice.CalendarTimerTask.callTimeout(CalendarTimerTask.java:53)
> at org.jboss.as.ejb3.timerservice.TimerTask.run(TimerTask.java:157)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl$Task$1.run(TimerServiceImpl.java:1215)
> at org.wildfly.extension.requestcontroller.RequestController$QueuedTask$1.run(RequestController.java:497)
> 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)
> Caused by: javax.transaction.RollbackException: WFLYEJB0447: Transaction 'TransactionImple < ac, BasicAction: 0:ffffac1f6209:-595568e4:57e80419:e status: ActionStatus.ABORTED >' was already rolled back
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:98)
> ... 38 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7101) Wildfly 10.1.0 blocks calls to Singleton EJBs in PostConstruct
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7101?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-7101:
--------------------------------------
This is not a bug, but actually required by the EJB spec, in 4.8.1 it says "the container must initialize the singleton session bean instance during the application startup sequence. The container must initialize all such startup-time singleton session beans before any external client requests (that is, client requests originating outside of the application) are delivered to any enterprise bean components in the application"
> 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, 8 months
[JBoss JIRA] (WFLY-7101) Wildfly 10.1.0 blocks calls to Singleton EJBs in PostConstruct
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7101?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-7101.
----------------------------------
Resolution: Rejected
> 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, 8 months
[JBoss JIRA] (WFLY-7212) Cannot use BMT in @Schedule service
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7212?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-7212:
--------------------------------------
If you want a transaction add @org.jboss.ejb3.annotation.TransactionTimeout(value=1, unit=HOURS) to the @Schedule method.
UserTransaction.setTransactionTimeout actually sets the timeout for newly created transactions by that thread, it will not affect an existing CMT tranaction.
> Cannot use BMT in @Schedule service
> -----------------------------------
>
> Key: WFLY-7212
> URL: https://issues.jboss.org/browse/WFLY-7212
> Project: WildFly
> Issue Type: Feature Request
> Components: EE, EJB, Transactions
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Environment: Wildfly 10.1.0-Final. Windows 10. MySql 5.5.
> Reporter: Karl Nicholas
> Labels: arjuna, ejb, scheduled, scheduled_tasks, transaction
>
> When injecting a `@Resource private UserTransaction tx;`, a `TransactionReaper` terminates kills my `UserTransaction` after 5 minutes no matter what. Since it's a batch update, I need more than 5 minutes.
> Here is a simple piece of code that doesn't work:
> {code:java}
> @EJB private TestFiveMinuteBatch testFiveMinuteBatch;
> @Schedule(second="0", minute="8", hour="10", persistent=false) // 03:30 am (12:30 am CA ) every day
> public void updateTest() {
> testFiveMinuteBatch.test();
> }
> @Stateless
> @TransactionManagement(TransactionManagementType.BEAN)
> public class TestFiveMinuteBatch {
> @Resource private UserTransaction tx;
> public void test() {
> for ( int i=0; i < 6; ++i ) {
> System.out.println("Minute: " + i);
> try {
> Thread.sleep(60000);
> } catch (InterruptedException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
> }
> }
> }
> {code}
> After 5 minutes I get this warning:
> {noformat}
> 10:13:00,034 WARN [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffffac1f6209:-595568e4:57e80419:e in state RUN
> 10:13:00,039 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012121: TransactionReaper::doCancellations worker Thread[Transaction Reaper Worker 0,5,main] successfully canceled TX 0:ffffac1f6209:-595568e4:57e80419:e
> 10:13:00,130 INFO [stdout] (EJB default - 1) Minute: 5
> {noformat}
> After service terminates I get this error:
> {noformat}
> 10:14:00,131 WARN [com.arjuna.ats.arjuna] (EJB default - 1) ARJUNA012077: Abort called on already aborted atomic action 0:ffffac1f6209:-595568e4:57e80419:e
> 10:14:00,163 ERROR [org.jboss.as.ejb3.timer] (EJB default - 1) WFLYEJB0020: Error invoking timeout for timer: [id=8a8f4546-28d0-491e-85a6-f668f58ab5dc timedObjectId=opca-ear.opca-ejb.ScheduledService auto-timer?:true persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@31fe8c3e initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Mon Sep 26 10:08:00 PDT 2016 timerState=IN_TIMEOUT info=null]: javax.ejb.EJBTransactionRolledbackException: Transaction rolled back
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleEndTransactionException(CMTTxInterceptor.java:137)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:117)
> at org.jboss.as.ejb3.tx.TimerCMTTxInterceptor.endTransaction(TimerCMTTxInterceptor.java:67)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:279)
> 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.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:110)
> 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.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.ejb3.timerservice.TimedObjectInvokerImpl.callTimeout(TimedObjectInvokerImpl.java:99)
> at org.jboss.as.ejb3.timerservice.CalendarTimerTask.invokeBeanMethod(CalendarTimerTask.java:64)
> at org.jboss.as.ejb3.timerservice.CalendarTimerTask.callTimeout(CalendarTimerTask.java:53)
> at org.jboss.as.ejb3.timerservice.TimerTask.run(TimerTask.java:157)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl$Task$1.run(TimerServiceImpl.java:1215)
> at org.wildfly.extension.requestcontroller.RequestController$QueuedTask$1.run(RequestController.java:497)
> 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)
> Caused by: javax.transaction.RollbackException: WFLYEJB0447: Transaction 'TransactionImple < ac, BasicAction: 0:ffffac1f6209:-595568e4:57e80419:e status: ActionStatus.ABORTED >' was already rolled back
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:98)
> ... 38 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7212) Cannot use BMT in @Schedule service
by Karl Nicholas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7212?page=com.atlassian.jira.plugin.... ]
Karl Nicholas commented on WFLY-7212:
-------------------------------------
Hi and thanks for your reply. No, I want a transaction, of course, but the problem persists whether I have a transaction or not. I was trying to upload the simplest possible code.
I'm double checking to make sure I can't use a CMT, because I was under the impression that I didn't have access to a CMT from a scheduled service, but it's been a while since I was tackling that issue.
> Cannot use BMT in @Schedule service
> -----------------------------------
>
> Key: WFLY-7212
> URL: https://issues.jboss.org/browse/WFLY-7212
> Project: WildFly
> Issue Type: Feature Request
> Components: EE, EJB, Transactions
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Environment: Wildfly 10.1.0-Final. Windows 10. MySql 5.5.
> Reporter: Karl Nicholas
> Labels: arjuna, ejb, scheduled, scheduled_tasks, transaction
>
> When injecting a `@Resource private UserTransaction tx;`, a `TransactionReaper` terminates kills my `UserTransaction` after 5 minutes no matter what. Since it's a batch update, I need more than 5 minutes.
> Here is a simple piece of code that doesn't work:
> {code:java}
> @EJB private TestFiveMinuteBatch testFiveMinuteBatch;
> @Schedule(second="0", minute="8", hour="10", persistent=false) // 03:30 am (12:30 am CA ) every day
> public void updateTest() {
> testFiveMinuteBatch.test();
> }
> @Stateless
> @TransactionManagement(TransactionManagementType.BEAN)
> public class TestFiveMinuteBatch {
> @Resource private UserTransaction tx;
> public void test() {
> for ( int i=0; i < 6; ++i ) {
> System.out.println("Minute: " + i);
> try {
> Thread.sleep(60000);
> } catch (InterruptedException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
> }
> }
> }
> {code}
> After 5 minutes I get this warning:
> {noformat}
> 10:13:00,034 WARN [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffffac1f6209:-595568e4:57e80419:e in state RUN
> 10:13:00,039 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012121: TransactionReaper::doCancellations worker Thread[Transaction Reaper Worker 0,5,main] successfully canceled TX 0:ffffac1f6209:-595568e4:57e80419:e
> 10:13:00,130 INFO [stdout] (EJB default - 1) Minute: 5
> {noformat}
> After service terminates I get this error:
> {noformat}
> 10:14:00,131 WARN [com.arjuna.ats.arjuna] (EJB default - 1) ARJUNA012077: Abort called on already aborted atomic action 0:ffffac1f6209:-595568e4:57e80419:e
> 10:14:00,163 ERROR [org.jboss.as.ejb3.timer] (EJB default - 1) WFLYEJB0020: Error invoking timeout for timer: [id=8a8f4546-28d0-491e-85a6-f668f58ab5dc timedObjectId=opca-ear.opca-ejb.ScheduledService auto-timer?:true persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@31fe8c3e initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Mon Sep 26 10:08:00 PDT 2016 timerState=IN_TIMEOUT info=null]: javax.ejb.EJBTransactionRolledbackException: Transaction rolled back
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleEndTransactionException(CMTTxInterceptor.java:137)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:117)
> at org.jboss.as.ejb3.tx.TimerCMTTxInterceptor.endTransaction(TimerCMTTxInterceptor.java:67)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:279)
> 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.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:110)
> 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.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.ejb3.timerservice.TimedObjectInvokerImpl.callTimeout(TimedObjectInvokerImpl.java:99)
> at org.jboss.as.ejb3.timerservice.CalendarTimerTask.invokeBeanMethod(CalendarTimerTask.java:64)
> at org.jboss.as.ejb3.timerservice.CalendarTimerTask.callTimeout(CalendarTimerTask.java:53)
> at org.jboss.as.ejb3.timerservice.TimerTask.run(TimerTask.java:157)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl$Task$1.run(TimerServiceImpl.java:1215)
> at org.wildfly.extension.requestcontroller.RequestController$QueuedTask$1.run(RequestController.java:497)
> 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)
> Caused by: javax.transaction.RollbackException: WFLYEJB0447: Transaction 'TransactionImple < ac, BasicAction: 0:ffffac1f6209:-595568e4:57e80419:e status: ActionStatus.ABORTED >' was already rolled back
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:98)
> ... 38 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7212) Cannot use BMT in @Schedule service
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7212?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-7212:
--------------------------------------
So you don't want a transaction at all?
At the moment the updateTest() method is using CMT and it starts a transaction. If you don't want a transaction add @TransactionAttribute(NONE) to the @Schedule method, or make it into a BMT bean as well.
> Cannot use BMT in @Schedule service
> -----------------------------------
>
> Key: WFLY-7212
> URL: https://issues.jboss.org/browse/WFLY-7212
> Project: WildFly
> Issue Type: Feature Request
> Components: EE, EJB, Transactions
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Environment: Wildfly 10.1.0-Final. Windows 10. MySql 5.5.
> Reporter: Karl Nicholas
> Labels: arjuna, ejb, scheduled, scheduled_tasks, transaction
>
> When injecting a `@Resource private UserTransaction tx;`, a `TransactionReaper` terminates kills my `UserTransaction` after 5 minutes no matter what. Since it's a batch update, I need more than 5 minutes.
> Here is a simple piece of code that doesn't work:
> {code:java}
> @EJB private TestFiveMinuteBatch testFiveMinuteBatch;
> @Schedule(second="0", minute="8", hour="10", persistent=false) // 03:30 am (12:30 am CA ) every day
> public void updateTest() {
> testFiveMinuteBatch.test();
> }
> @Stateless
> @TransactionManagement(TransactionManagementType.BEAN)
> public class TestFiveMinuteBatch {
> @Resource private UserTransaction tx;
> public void test() {
> for ( int i=0; i < 6; ++i ) {
> System.out.println("Minute: " + i);
> try {
> Thread.sleep(60000);
> } catch (InterruptedException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
> }
> }
> }
> {code}
> After 5 minutes I get this warning:
> {noformat}
> 10:13:00,034 WARN [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffffac1f6209:-595568e4:57e80419:e in state RUN
> 10:13:00,039 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012121: TransactionReaper::doCancellations worker Thread[Transaction Reaper Worker 0,5,main] successfully canceled TX 0:ffffac1f6209:-595568e4:57e80419:e
> 10:13:00,130 INFO [stdout] (EJB default - 1) Minute: 5
> {noformat}
> After service terminates I get this error:
> {noformat}
> 10:14:00,131 WARN [com.arjuna.ats.arjuna] (EJB default - 1) ARJUNA012077: Abort called on already aborted atomic action 0:ffffac1f6209:-595568e4:57e80419:e
> 10:14:00,163 ERROR [org.jboss.as.ejb3.timer] (EJB default - 1) WFLYEJB0020: Error invoking timeout for timer: [id=8a8f4546-28d0-491e-85a6-f668f58ab5dc timedObjectId=opca-ear.opca-ejb.ScheduledService auto-timer?:true persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@31fe8c3e initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Mon Sep 26 10:08:00 PDT 2016 timerState=IN_TIMEOUT info=null]: javax.ejb.EJBTransactionRolledbackException: Transaction rolled back
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleEndTransactionException(CMTTxInterceptor.java:137)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:117)
> at org.jboss.as.ejb3.tx.TimerCMTTxInterceptor.endTransaction(TimerCMTTxInterceptor.java:67)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:279)
> 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.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:110)
> 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.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.ejb3.timerservice.TimedObjectInvokerImpl.callTimeout(TimedObjectInvokerImpl.java:99)
> at org.jboss.as.ejb3.timerservice.CalendarTimerTask.invokeBeanMethod(CalendarTimerTask.java:64)
> at org.jboss.as.ejb3.timerservice.CalendarTimerTask.callTimeout(CalendarTimerTask.java:53)
> at org.jboss.as.ejb3.timerservice.TimerTask.run(TimerTask.java:157)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl$Task$1.run(TimerServiceImpl.java:1215)
> at org.wildfly.extension.requestcontroller.RequestController$QueuedTask$1.run(RequestController.java:497)
> 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)
> Caused by: javax.transaction.RollbackException: WFLYEJB0447: Transaction 'TransactionImple < ac, BasicAction: 0:ffffac1f6209:-595568e4:57e80419:e status: ActionStatus.ABORTED >' was already rolled back
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:98)
> ... 38 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7212) Cannot use BMT in @Schedule service
by Karl Nicholas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7212?page=com.atlassian.jira.plugin.... ]
Karl Nicholas commented on WFLY-7212:
-------------------------------------
Been there, done that. I'd thought you'd recognize that there was no transaction, but I double checked anyway.
@Stateless
@TransactionManagement(TransactionManagementType.BEAN)
public class TestFiveMinuteBatch {
@Resource private UserTransaction tx;
public void test() {
try {
tx.setTransactionTimeout(600);
for ( int i=0; i < 6; ++i ) {
System.out.println("Minute: " + i);
Thread.sleep(60000);
}
} catch (SystemException | InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
> Cannot use BMT in @Schedule service
> -----------------------------------
>
> Key: WFLY-7212
> URL: https://issues.jboss.org/browse/WFLY-7212
> Project: WildFly
> Issue Type: Feature Request
> Components: EE, EJB, Transactions
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Environment: Wildfly 10.1.0-Final. Windows 10. MySql 5.5.
> Reporter: Karl Nicholas
> Labels: arjuna, ejb, scheduled, scheduled_tasks, transaction
>
> When injecting a `@Resource private UserTransaction tx;`, a `TransactionReaper` terminates kills my `UserTransaction` after 5 minutes no matter what. Since it's a batch update, I need more than 5 minutes.
> Here is a simple piece of code that doesn't work:
> {code:java}
> @EJB private TestFiveMinuteBatch testFiveMinuteBatch;
> @Schedule(second="0", minute="8", hour="10", persistent=false) // 03:30 am (12:30 am CA ) every day
> public void updateTest() {
> testFiveMinuteBatch.test();
> }
> @Stateless
> @TransactionManagement(TransactionManagementType.BEAN)
> public class TestFiveMinuteBatch {
> @Resource private UserTransaction tx;
> public void test() {
> for ( int i=0; i < 6; ++i ) {
> System.out.println("Minute: " + i);
> try {
> Thread.sleep(60000);
> } catch (InterruptedException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
> }
> }
> }
> {code}
> After 5 minutes I get this warning:
> {noformat}
> 10:13:00,034 WARN [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffffac1f6209:-595568e4:57e80419:e in state RUN
> 10:13:00,039 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012121: TransactionReaper::doCancellations worker Thread[Transaction Reaper Worker 0,5,main] successfully canceled TX 0:ffffac1f6209:-595568e4:57e80419:e
> 10:13:00,130 INFO [stdout] (EJB default - 1) Minute: 5
> {noformat}
> After service terminates I get this error:
> {noformat}
> 10:14:00,131 WARN [com.arjuna.ats.arjuna] (EJB default - 1) ARJUNA012077: Abort called on already aborted atomic action 0:ffffac1f6209:-595568e4:57e80419:e
> 10:14:00,163 ERROR [org.jboss.as.ejb3.timer] (EJB default - 1) WFLYEJB0020: Error invoking timeout for timer: [id=8a8f4546-28d0-491e-85a6-f668f58ab5dc timedObjectId=opca-ear.opca-ejb.ScheduledService auto-timer?:true persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@31fe8c3e initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Mon Sep 26 10:08:00 PDT 2016 timerState=IN_TIMEOUT info=null]: javax.ejb.EJBTransactionRolledbackException: Transaction rolled back
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleEndTransactionException(CMTTxInterceptor.java:137)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:117)
> at org.jboss.as.ejb3.tx.TimerCMTTxInterceptor.endTransaction(TimerCMTTxInterceptor.java:67)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:279)
> 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.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:110)
> 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.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.ejb3.timerservice.TimedObjectInvokerImpl.callTimeout(TimedObjectInvokerImpl.java:99)
> at org.jboss.as.ejb3.timerservice.CalendarTimerTask.invokeBeanMethod(CalendarTimerTask.java:64)
> at org.jboss.as.ejb3.timerservice.CalendarTimerTask.callTimeout(CalendarTimerTask.java:53)
> at org.jboss.as.ejb3.timerservice.TimerTask.run(TimerTask.java:157)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl$Task$1.run(TimerServiceImpl.java:1215)
> at org.wildfly.extension.requestcontroller.RequestController$QueuedTask$1.run(RequestController.java:497)
> 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)
> Caused by: javax.transaction.RollbackException: WFLYEJB0447: Transaction 'TransactionImple < ac, BasicAction: 0:ffffac1f6209:-595568e4:57e80419:e status: ActionStatus.ABORTED >' was already rolled back
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:98)
> ... 38 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6941) Split Weld subsystem into several modules
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-6941?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-6941:
--------------------------------------
I really doubt using a service loader at boot time will make any noticeable difference in performance.
> Split Weld subsystem into several modules
> -----------------------------------------
>
> Key: WFLY-6941
> URL: https://issues.jboss.org/browse/WFLY-6941
> Project: WildFly
> Issue Type: Feature Request
> Components: CDI / Weld
> Reporter: Martin Kouba
> Assignee: Martin Kouba
> Fix For: 11.0.0.Alpha1
>
>
> * split subsystem into core and optional modules (ejb, jpa, bean-validation, etc.)
> * define SPI
> * use {{ServiceLoader}} to load optional services
> This should allow Swarm to leave out optional dependencies.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1828) Make it easier to register add and remove handlers with customized definitions
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1828:
----------------------------------------
Summary: Make it easier to register add and remove handlers with customized definitions
Key: WFCORE-1828
URL: https://issues.jboss.org/browse/WFCORE-1828
Project: WildFly Core
Issue Type: Enhancement
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Tomaz Cerar
Priority: Minor
The nice way to build up a ResourceDefinition is with the Parameters object. And that works well with most add and remove handlers where the RD when building up the MRR generates a definition for the handlers.
But in cases where there needs to be some customization of the add description (e.g. deployment(-overlay) add where the content param can have fields that are not used in the content attribute) then the only option is in some way or other to override registerOperations. That or have the add OSH implement DescriptionProvider. Which we don't want. ;)
Perhaps add setAddDescription/setRemoveDescription to Parameters, or
{code}
public interface SelfDescibingOperationStepHandler extends OperationStepHandler {
OperationDefinition getDefinition();
}
{code}
Enhancing Parameters sound better.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (ELY-643) On the SSLContextBuilder support setUserCipherSuiteOrder
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-643:
------------------------------------
Summary: On the SSLContextBuilder support setUserCipherSuiteOrder
Key: ELY-643
URL: https://issues.jboss.org/browse/ELY-643
Project: WildFly Elytron
Issue Type: Feature Request
Components: SSL
Reporter: Darran Lofthouse
Assignee: Jan Kalina
Priority: Critical
Fix For: 1.1.0.Beta10
Currently we hard code this value to 'true' which should remain the default as the OpenSSL style cipher suite selection includes preferred mechanism ordering - however it should be possible to override this and set it to false.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1821) Failures in ModuleOpsCompletionTestCase
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1821?page=com.atlassian.jira.plugi... ]
Brian Stansberry resolved WFCORE-1821.
--------------------------------------
Resolution: Duplicate Issue
> Failures in ModuleOpsCompletionTestCase
> ---------------------------------------
>
> Key: WFCORE-1821
> URL: https://issues.jboss.org/browse/WFCORE-1821
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Reporter: Brian Stansberry
> Assignee: ehsavoie Hugonnet
>
> Failed tests:
> ModuleOpsCompletionTestCase.testModuleAddCompletionSuggestions:56->testSuggestion:146->testSuggestion:153 expected:<[org, ibm, io, javax, org, sun]> but was:<[ibm, io, javax, org, sun]>
> There's already a PR that's probably meant to fix this but it isn't passing CI. I'm going to @Ignore this test.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[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 commented on WFLY-7097:
-------------------------------------
[~honza889] We probably need to also modify /src/main/resources/subsystem-templates/elytron.xml which is used to build *-elytron.xml configuration files in WildFly. If you start the server using standalone-elytron.xml, the following exception occurs:
11:54:16,517 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131)
at org.jboss.as.server.ServerService.boot(ServerService.java:355)
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:302)
at java.lang.Thread.run(Thread.java:745)
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[342,17]
Message: WFLYCTL0197: Unexpected attribute 'roles' encountered
at org.jboss.as.controller.parsing.ParseUtils.unexpectedAttribute(ParseUtils.java:117)
at org.wildfly.extension.elytron.MapperParser.readConstantRoleMapper(MapperParser.java:1159)
at org.wildfly.extension.elytron.MapperParser.readMappers(MapperParser.java:206)
at org.wildfly.extension.elytron.ElytronSubsystemParser.readElement(ElytronSubsystemParser.java:120)
at org.wildfly.extension.elytron.ElytronSubsystemParser.readElement(ElytronSubsystemParser.java:72)
at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69)
at org.jboss.as.server.parsing.StandaloneXml_5.parseServerProfile(StandaloneXml_5.java:591)
at org.jboss.as.server.parsing.StandaloneXml_5.readServerElement(StandaloneXml_5.java:245)
at org.jboss.as.server.parsing.StandaloneXml_5.readElement(StandaloneXml_5.java:144)
at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107)
at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:49)
at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69)
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123)
... 3 more
> 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, 8 months
[JBoss JIRA] (WFLY-7210) Expose JAX-RS resources as children of the subsystem
by Guillermo González de Agüero (JIRA)
[ https://issues.jboss.org/browse/WFLY-7210?page=com.atlassian.jira.plugin.... ]
Guillermo González de Agüero commented on WFLY-7210:
----------------------------------------------------
But WFLY-7024 is just about adding new functionlity to the show-resources operation. What I'm requesting here is to make a "resources" element child of the JAX-RS subsystem
> Expose JAX-RS resources as children of the subsystem
> ----------------------------------------------------
>
> Key: WFLY-7210
> URL: https://issues.jboss.org/browse/WFLY-7210
> Project: WildFly
> Issue Type: Feature Request
> Components: REST
> Affects Versions: 10.1.0.Final
> Reporter: Guillermo González de Agüero
> Assignee: Stuart Douglas
> Attachments: hal-jaxrs.png
>
>
> Servlets, EJBs, WebSockets, JPA, etc expose its components as children of the subsystem in the management API. For example to list the stateless EJBs of a deployment:
> [standalone@localhost:9990 /] /deployment=cdivsejb.war/subsystem=ejb3:read-children-resources(child-type=stateless-session-bean)
> This makes it specially easy to navigate trough the web console (attached screenshot).
> To read JAX-RS resources, the command would be:
> [standalone@localhost:9990 /] /deployment=cdivsejb.war/subsystem=jaxrs:show-resources()
> I propose to make deprecate the show-resources operation and create a new "resources" child, containing the Rest resources.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (DROOLS-1198) NoClassDefFoundError when using str[endsWith] on a field that matches an imported class name
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1198?page=com.atlassian.jira.plugi... ]
Matteo Mortari commented on DROOLS-1198:
----------------------------------------
Just for sake of completeness, as I had the chance to got hold of a physical Mac, I tested this fix on Mac OSX with the original reproducer.
Please notice with reference to screenshots below, both of Mac OSX, this JIRA was reported against 6.4.0.Final, and the fix besides of master is also committed to 6.5.0.CR2.
With 6.4.0.Final the problem was:
!screenshot-640Final.png|thumbnail!
With the fix, using version 6.5.0.CR2:
!screenshot-fixed-650CR2andmaster.png|thumbnail!
This to demonstrate the fix also on a physical Mac with Mac OSX.
> NoClassDefFoundError when using str[endsWith] on a field that matches an imported class name
> --------------------------------------------------------------------------------------------
>
> Key: DROOLS-1198
> URL: https://issues.jboss.org/browse/DROOLS-1198
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.4.0.Final
> Reporter: Chris Austin
> Assignee: Mario Fusco
> Priority: Minor
> Fix For: 7.0.0.Beta2
>
> Attachments: DROOLS-1198-unabletoreproduce.zip, screenshot-640Final.png, screenshot-fixed-650CR2andmaster.png, screenshot-linux.png, screenshot-Mac.png
>
>
> This error was triggered when accessing the user field with str[endsWith] when user is null:
> java.lang.NoClassDefFoundError: mssp/io/model/user (wrong name: mssp/io/model/User)
> Condition that triggers the error:
> $a : Alert(user!=null, user str[endsWith] "$")
> This does not trigger the error:
> $a : Alert(user!=null, user matches ".+\\$")
> If I remove the import for the User class the error will not be triggered. As a workaround I've switched to using matches instead of str[endsWith], but I'd prefer to switch back.
> I did not experience this issue in 6.3.0-Final, so it appears to be a regression in 6.4.0-Final
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (DROOLS-1198) NoClassDefFoundError when using str[endsWith] on a field that matches an imported class name
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1198?page=com.atlassian.jira.plugi... ]
Matteo Mortari updated DROOLS-1198:
-----------------------------------
Attachment: screenshot-fixed-650CR2andmaster.png
> NoClassDefFoundError when using str[endsWith] on a field that matches an imported class name
> --------------------------------------------------------------------------------------------
>
> Key: DROOLS-1198
> URL: https://issues.jboss.org/browse/DROOLS-1198
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.4.0.Final
> Reporter: Chris Austin
> Assignee: Mario Fusco
> Priority: Minor
> Fix For: 7.0.0.Beta2
>
> Attachments: DROOLS-1198-unabletoreproduce.zip, screenshot-640Final.png, screenshot-fixed-650CR2andmaster.png, screenshot-linux.png, screenshot-Mac.png
>
>
> This error was triggered when accessing the user field with str[endsWith] when user is null:
> java.lang.NoClassDefFoundError: mssp/io/model/user (wrong name: mssp/io/model/User)
> Condition that triggers the error:
> $a : Alert(user!=null, user str[endsWith] "$")
> This does not trigger the error:
> $a : Alert(user!=null, user matches ".+\\$")
> If I remove the import for the User class the error will not be triggered. As a workaround I've switched to using matches instead of str[endsWith], but I'd prefer to switch back.
> I did not experience this issue in 6.3.0-Final, so it appears to be a regression in 6.4.0-Final
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (DROOLS-1198) NoClassDefFoundError when using str[endsWith] on a field that matches an imported class name
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1198?page=com.atlassian.jira.plugi... ]
Matteo Mortari updated DROOLS-1198:
-----------------------------------
Attachment: screenshot-640Final.png
> NoClassDefFoundError when using str[endsWith] on a field that matches an imported class name
> --------------------------------------------------------------------------------------------
>
> Key: DROOLS-1198
> URL: https://issues.jboss.org/browse/DROOLS-1198
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.4.0.Final
> Reporter: Chris Austin
> Assignee: Mario Fusco
> Priority: Minor
> Fix For: 7.0.0.Beta2
>
> Attachments: DROOLS-1198-unabletoreproduce.zip, screenshot-640Final.png, screenshot-linux.png, screenshot-Mac.png
>
>
> This error was triggered when accessing the user field with str[endsWith] when user is null:
> java.lang.NoClassDefFoundError: mssp/io/model/user (wrong name: mssp/io/model/User)
> Condition that triggers the error:
> $a : Alert(user!=null, user str[endsWith] "$")
> This does not trigger the error:
> $a : Alert(user!=null, user matches ".+\\$")
> If I remove the import for the User class the error will not be triggered. As a workaround I've switched to using matches instead of str[endsWith], but I'd prefer to switch back.
> I did not experience this issue in 6.3.0-Final, so it appears to be a regression in 6.4.0-Final
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JBJCA-1333) Add protection in DsXmlDeployer to prevent from loading xml resource
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1333?page=com.atlassian.jira.plugin... ]
Stefano Maestri reassigned JBJCA-1333:
--------------------------------------
Assignee: Stefano Maestri
> Add protection in DsXmlDeployer to prevent from loading xml resource
> --------------------------------------------------------------------
>
> Key: JBJCA-1333
> URL: https://issues.jboss.org/browse/JBJCA-1333
> Project: IronJacamar
> Issue Type: Enhancement
> Components: Deployer
> Affects Versions: 1.2.7.Final
> Reporter: COLLIGNON Thomas
> Assignee: Stefano Maestri
> Priority: Minor
> Fix For: 1.2.8.Final
>
>
> If we place a datasource.xml in a jar file, the class DsXmlDeployer will fail with "URI not hierarchical error", because it doesn't handle jar file.
> The goal of this issue is prevent for loading jar file in DsXmlDeployer.
> The second goal is to provide ability of overring DsXmlDeployer in custom deployer who extends this class.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JBJCA-1333) Add protection in DsXmlDeployer to prevent from loading xml resource
by COLLIGNON Thomas (JIRA)
COLLIGNON Thomas created JBJCA-1333:
---------------------------------------
Summary: Add protection in DsXmlDeployer to prevent from loading xml resource
Key: JBJCA-1333
URL: https://issues.jboss.org/browse/JBJCA-1333
Project: IronJacamar
Issue Type: Enhancement
Components: Deployer
Affects Versions: 1.2.7.Final
Reporter: COLLIGNON Thomas
Priority: Minor
Fix For: 1.2.8.Final
If we place a datasource.xml in a jar file, the class DsXmlDeployer will fail with "URI not hierarchical error", because it doesn't handle jar file.
The goal of this issue is prevent for loading jar file in DsXmlDeployer.
The second goal is to provide ability of overring DsXmlDeployer in custom deployer who extends this class.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JBJCA-1331) Use connection-url to get database connection when connection properties for datasource-class is empty
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1331?page=com.atlassian.jira.plugin... ]
Lin Gao resolved JBJCA-1331.
----------------------------
Resolution: Done
> Use connection-url to get database connection when connection properties for datasource-class is empty
> ------------------------------------------------------------------------------------------------------
>
> Key: JBJCA-1331
> URL: https://issues.jboss.org/browse/JBJCA-1331
> Project: IronJacamar
> Issue Type: Task
> Components: JDBC
> Affects Versions: WildFly/IronJacamar 1.3.4.Final, 1.2.7.Final
> Reporter: Lin Gao
> Assignee: Lin Gao
> Fix For: WildFly/IronJacamar 1.3.5.Final, 1.2.8.Final
>
>
> Fixes of JBJCA-1312 will fail the old configuration where the connection-url is used.
> In the compatibility point of view, we should try to use {{connection-url}} & {{driver-class}} to get the database connection if the connection properties are empty && datasource-class != null. A warning message should be printed to encourage users to use DataSource for database connection.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (ELY-631) Wrong description of missing target-name in simple-permission-mapper
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-631?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina edited comment on ELY-631 at 9/26/16 10:53 AM:
----------------------------------------------------------
The problem is:
* Subsystem does not know if Permission should have a name (depends on class name)
* The Permission doesnt know anything about subsystem attributes (like target-name)
Ideas:
* Catch IllegalArgumentException in subsystem and if message/attribute match "name" (Permission param), rewrite to "target-name" (attribute in subsystem)
** Problem: IllegalArgumentException has the error message only, only whole error message comparison possible now...
was (Author: honza889):
The problem is:
* Subsystem does not know if Permission should have a name (depends on class name)
* The Permission doesnt know anything about subsystem attributes (like target-name)
Ideas:
* Catch IllegalArgumentException in subsystem and if message/attribute match "name" (Permission param), rewrite to "target-name" (attribute in subsystem)
* Problem: IllegalArgumentException has the error message only, only whole error message comparison possible now...
> Wrong description of missing target-name in simple-permission-mapper
> --------------------------------------------------------------------
>
> Key: ELY-631
> URL: https://issues.jboss.org/browse/ELY-631
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta9
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
>
> In case when simple-permission-mapper cannot be added through CLI command due to missing target-name attribute, then IllegalArgumentException with wrong description is thrown. It says: "Parameter '*name*' may not be null". It should be "Parameter '*target-name*' may not be null".
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (ELY-631) Wrong description of missing target-name in simple-permission-mapper
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-631?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina edited comment on ELY-631 at 9/26/16 10:52 AM:
----------------------------------------------------------
The problem is:
* Subsystem does not know if Permission should have a name (depends on class name)
* The Permission doesnt know anything about subsystem attributes (like target-name)
Ideas:
* Catch IllegalArgumentException in subsystem and if message/attribute match "name" (Permission param), rewrite to "target-name" (attribute in subsystem)
* Problem: IllegalArgumentException has the error message only, only whole error message comparison possible now...
was (Author: honza889):
The problem is:
* Subsystem does not know if Permission should have a name (depends on class name)
* The Permission doesnt know anything about subsystem attributes (like target-name)
Ideas:
* Catch IllegalArgumentException in subsystem and if message/attribute match "name" (Permission param), rewrite to "target-name" (attribute in subsystem) ?
> Wrong description of missing target-name in simple-permission-mapper
> --------------------------------------------------------------------
>
> Key: ELY-631
> URL: https://issues.jboss.org/browse/ELY-631
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta9
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
>
> In case when simple-permission-mapper cannot be added through CLI command due to missing target-name attribute, then IllegalArgumentException with wrong description is thrown. It says: "Parameter '*name*' may not be null". It should be "Parameter '*target-name*' may not be null".
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (JBJCA-1332) not possible to set all-upper-case ActivationConfigProperty
by Martin Simka (JIRA)
Martin Simka created JBJCA-1332:
-----------------------------------
Summary: not possible to set all-upper-case ActivationConfigProperty
Key: JBJCA-1332
URL: https://issues.jboss.org/browse/JBJCA-1332
Project: IronJacamar
Issue Type: Bug
Components: Core
Affects Versions: WildFly/IronJacamar 1.3.4.Final
Reporter: Martin Simka
{code:java|title=MDB}
@MessageDriven(name = "LocalResendingMdbFromQueueToQueue",
activationConfig = {
@ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
@ActivationConfigProperty(propertyName = "destination", propertyValue = "jms/queue/InQueue"),
@ActivationConfigProperty(propertyName = "HA", propertyValue = "false")
})
@TransactionManagement(value = TransactionManagementType.CONTAINER)
@TransactionAttribute(value = TransactionAttributeType.REQUIRED)
public class LocalResendingMdbFromQueueToQueue implements MessageListener {
{code}
{{HA}} property is ignored because IJ can't find setter
{noformat}
14:39:18,434 WARN [org.jboss.as.ejb3] (MSC service thread 1-7) WFLYEJB0006: ActivationConfigProperty HA will be ignored since it is not allowed by resource adapter: activemq-ra
{noformat}
ActivationSpec class is https://github.com/apache/activemq-artemis/blob/master/artemis-ra/src/mai...
Setter for property {{HA}} is in parent class https://github.com/apache/activemq-artemis/blob/master/artemis-ra/src/mai...
It happens because [SimpleResourceAdapterRepository.java#L501|https://github.com/ironjacamar/...] converts the first character after "set" to lower case. But that is not sufficient.
According to JCA 1.7 specification ActivationSpec is JavaBean (spec. section 5.3.3) and JavaBean specification (spec. section 8.8) says
{quote}
Thus when we extract a property or event name from the middle of an existing Java name, we normally convert the first character to lower case. However to support the occasional use of all upper-case names, we check if the first two characters of the name are both upper case and if so leave it alone.
So for example,
"FooBah" becomes "fooBah"
"Z" becomes "z"
"URL" becomes "URL"
We provide a method Introspector.decapitalize which implements this conversion rule.
{quote}
Maybe IJ could leverage [Introspector|https://docs.oracle.com/javase/7/docs/api/java/beans/Introsp...] class
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1824) Can not parse object attributes that contains a Properties attribute
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1824?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-1824:
----------------------------------------
Assignee: Tomaz Cerar (was: Brian Stansberry)
Tomaz, can you have a look?
> Can not parse object attributes that contains a Properties attribute
> --------------------------------------------------------------------
>
> Key: WFCORE-1824
> URL: https://issues.jboss.org/browse/WFCORE-1824
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha8
> Reporter: Jeff Mesnil
> Assignee: Tomaz Cerar
>
> My resource defines an attribute which is a LIST of OBJECT that corresponds to a class (class name + module) and Properties that are passed to the created instance:
> {noformat}
> private static final String CLASS = "class";
> private static final String MODULE = "module";
> public static final PropertiesAttributeDefinition PROPERTIES = new PropertiesAttributeDefinition.Builder("properties", true)
> .setAllowExpression(true)
> .build();
> public static final ObjectTypeAttributeDefinition PROCESS_STATE_LISTENER = ObjectTypeAttributeDefinition.Builder.of("process-state-listener",
> SimpleAttributeDefinitionBuilder.create(CLASS, ModelType.STRING, false)
> .setAllowExpression(false)
> .build(),
> SimpleAttributeDefinitionBuilder.create(MODULE, ModelType.STRING, false)
> .setAllowExpression(false)
> .build(),
> PROPERTIES)
> .setRestartAllServices()
> .setAllowNull(true)
> .build();
> public static final AttributeDefinition PROCESS_STATE_LISTENERS = ObjectListAttributeDefinition.Builder.of("listeners", PROCESS_STATE_LISTENER)
> .setAllowNull(false)
> .setRuntimeServiceNotRequired()
> .build();
> {noformat}
> I can create the resource from the CLI:
> {noformat}
> /subsystem=core-management/service=process-state-listeners:add(listeners=[{class=org.foo.Listener, module=org.foo,, properties = {foo = true, bar = ${bar.prop:2}}}])
> {"outcome" => "success"}
> {noformat}
> And the resource and its attribute is properly marshalled to the XML configuration:
> {noformat}
> <process-state-listeners>
> <listeners>
> <process-state-listener class="org.foo.Listener" module="org.foo">
> <properties>
> <property name="foo" value="true"/>
> <property name="bar" value="${bar.prop:2}"/>
> </properties>
> </process-state-listener>
> </listeners>
> </process-state-listeners>
> {noformat}
> However the resource can not be parsed and it fails with the exception:
> {noformat}
> boss.as.server.parsing.StandaloneXml_5.readElement(StandaloneXml_5.java:144)
> at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107)
> at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:49)
> at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
> at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69)
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123)
> ... 3 more
> 09:45:00,537 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.{noformat}
> The code in org.jboss.as.controller.AttributeParser#parseElement:197 to parse a list of objects assumes that the object's value are all represented by XML attributes. In my case, that's not correct as the "properties" attribute is represented by XML elements.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6941) Split Weld subsystem into several modules
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-6941?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-6941:
------------------------------------
Are there specific concerns with performance based on changes to code? Or just general concern that splitting Weld to use different classloaders could introduce a performance regression?
> Split Weld subsystem into several modules
> -----------------------------------------
>
> Key: WFLY-6941
> URL: https://issues.jboss.org/browse/WFLY-6941
> Project: WildFly
> Issue Type: Feature Request
> Components: CDI / Weld
> Reporter: Martin Kouba
> Assignee: Martin Kouba
> Fix For: 11.0.0.Alpha1
>
>
> * split subsystem into core and optional modules (ejb, jpa, bean-validation, etc.)
> * define SPI
> * use {{ServiceLoader}} to load optional services
> This should allow Swarm to leave out optional dependencies.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1826) Tab completion don't return inner attributes
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1826?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise updated WFCORE-1826:
-----------------------------------------
Description:
*Description of problem:*
Tab completion returns wrong values
*How reproducible:*
Always
*Steps to Reproduce:*
{noformat}
/extension=org.wildfly.extension.elytron:add
/subsystem=elytron:add
reload
/subsystem=elytron/simple-permission-mapper=login-permission-mapper2:add(permission-mappings=[{permissions=[{class-name="org.wildfly.security.auth.permission.LoginPermission"}],<TAB>
{noformat}
*Actual results:*
{noformat}
/subsystem=elytron/simple-permission-mapper=login-permission-mapper2:add(permission-mappings=[{permissions=[{class-name="org.wildfly.security.auth.permission.LoginPermission"}],{
{noformat}
*Expected results:*
{noformat}
[standalone@localhost:9990 /] /subsystem=elytron/simple-permission-mapper=login-permission-mapper2:add(permission-mappings=[{permissions=[{class-name="org.wildfly.security.auth.permission.LoginPermission"}],
principals roles
[standalone@localhost:9990 /] /subsystem=elytron/simple-permission-mapper=login-permission-mapper2:add(permission-mappings=[{permissions=[{class-name="org.wildfly.security.auth.permission.LoginPermission"}],
{noformat}
> Tab completion don't return inner attributes
> --------------------------------------------
>
> Key: WFCORE-1826
> URL: https://issues.jboss.org/browse/WFCORE-1826
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
>
> *Description of problem:*
> Tab completion returns wrong values
> *How reproducible:*
> Always
> *Steps to Reproduce:*
> {noformat}
> /extension=org.wildfly.extension.elytron:add
> /subsystem=elytron:add
> reload
> /subsystem=elytron/simple-permission-mapper=login-permission-mapper2:add(permission-mappings=[{permissions=[{class-name="org.wildfly.security.auth.permission.LoginPermission"}],<TAB>
> {noformat}
> *Actual results:*
> {noformat}
> /subsystem=elytron/simple-permission-mapper=login-permission-mapper2:add(permission-mappings=[{permissions=[{class-name="org.wildfly.security.auth.permission.LoginPermission"}],{
> {noformat}
> *Expected results:*
> {noformat}
> [standalone@localhost:9990 /] /subsystem=elytron/simple-permission-mapper=login-permission-mapper2:add(permission-mappings=[{permissions=[{class-name="org.wildfly.security.auth.permission.LoginPermission"}],
> principals roles
> [standalone@localhost:9990 /] /subsystem=elytron/simple-permission-mapper=login-permission-mapper2:add(permission-mappings=[{permissions=[{class-name="org.wildfly.security.auth.permission.LoginPermission"}],
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1825) Tab completion throws IllegalArgumentException after two '{' characters and '=' character
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1825?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise updated WFCORE-1825:
-----------------------------------------
Description:
*Description of problem:*
This issue is similar like JBEAP-6043. Tab completion throws IllegalArgumentException after two '\{' characters and '=' character. Or tab completition returns unlimited count of ')' characters.
*How reproducible:*
Always
----
*1. Steps to Reproduce:*
{noformat}
Get fresh EAP.
./standalone.sh &
./jboss-cli.sh -c
/subsystem=elytron/simple-permission-mapper=login-permission-mapper2:add(permission-mappings=[{roles=[{role<TAB><TAB><TAB><TAB><TAB><TAB><TAB><TAB><TAB><TAB>
{noformat}
*1. Actual results:*
{noformat}
/subsystem=elytron/simple-permission-mapper=login-permission-mapper2:add(permission-mappings=[{roles=[{role))))))))))
{noformat}
----
*2. Steps to Reproduce:*
{noformat}
./standalone.sh -c standalone-elytron.xml &
./jboss-cli.sh -c
/subsystem=elytron/simple-permission-mapper=login-permission-mapper2:add(permission-mappings=[{roles=[{role=<TAB>
{noformat}
*2. Actual results:*
* java.lang.IllegalArgumentException
* Details:
{noformat}
[mkopecky@dhcp-10-40-5-171 bin]$ ./jboss-cli.sh -c
[standalone@localhost:9990 /] /subsystem=elytron/simple-permission-mapper=login-permission-mapper2:add(permission-mappings=[{roles=[{role=Exception in thread "Aesh Process Loop 30318020" java.lang.IllegalArgumentException
at org.jboss.dmr.ModelValue.getChild(ModelValue.java:115)
at org.jboss.dmr.ModelNode.get(ModelNode.java:861)
at org.jboss.as.cli.impl.ValueTypeCompleter$ValueTypeCallbackHandler.getCandidates(ValueTypeCompleter.java:475)
at org.jboss.as.cli.impl.ValueTypeCompleter.complete(ValueTypeCompleter.java:321)
at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:254)
at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:74)
at org.jboss.as.cli.CommandCompleter.doComplete(CommandCompleter.java:137)
at org.jboss.as.cli.CommandCompleter.complete(CommandCompleter.java:64)
at org.jboss.as.cli.impl.Console$Factory$1$1.complete(Console.java:143)
at org.jboss.aesh.console.AeshCompletionHandler.complete(AeshCompletionHandler.java:155)
at org.jboss.aesh.console.AeshInputProcessor.complete(AeshInputProcessor.java:427)
at org.jboss.aesh.console.AeshInputProcessor.parseOperation(AeshInputProcessor.java:165)
at org.jboss.aesh.console.Console.processInternalOperation(Console.java:773)
at org.jboss.aesh.console.Console.execute(Console.java:733)
at org.jboss.aesh.console.Console.access$900(Console.java:73)
at org.jboss.aesh.console.Console$6.run(Console.java:642)
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)
[mkopecky@dhcp-10-40-5-171 bin]$
{noformat}
> Tab completion throws IllegalArgumentException after two '{' characters and '=' character
> -----------------------------------------------------------------------------------------
>
> Key: WFCORE-1825
> URL: https://issues.jboss.org/browse/WFCORE-1825
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
>
> *Description of problem:*
> This issue is similar like JBEAP-6043. Tab completion throws IllegalArgumentException after two '\{' characters and '=' character. Or tab completition returns unlimited count of ')' characters.
> *How reproducible:*
> Always
> ----
> *1. Steps to Reproduce:*
> {noformat}
> Get fresh EAP.
> ./standalone.sh &
> ./jboss-cli.sh -c
> /subsystem=elytron/simple-permission-mapper=login-permission-mapper2:add(permission-mappings=[{roles=[{role<TAB><TAB><TAB><TAB><TAB><TAB><TAB><TAB><TAB><TAB>
> {noformat}
> *1. Actual results:*
> {noformat}
> /subsystem=elytron/simple-permission-mapper=login-permission-mapper2:add(permission-mappings=[{roles=[{role))))))))))
> {noformat}
> ----
> *2. Steps to Reproduce:*
> {noformat}
> ./standalone.sh -c standalone-elytron.xml &
> ./jboss-cli.sh -c
> /subsystem=elytron/simple-permission-mapper=login-permission-mapper2:add(permission-mappings=[{roles=[{role=<TAB>
> {noformat}
> *2. Actual results:*
> * java.lang.IllegalArgumentException
> * Details:
> {noformat}
> [mkopecky@dhcp-10-40-5-171 bin]$ ./jboss-cli.sh -c
> [standalone@localhost:9990 /] /subsystem=elytron/simple-permission-mapper=login-permission-mapper2:add(permission-mappings=[{roles=[{role=Exception in thread "Aesh Process Loop 30318020" java.lang.IllegalArgumentException
> at org.jboss.dmr.ModelValue.getChild(ModelValue.java:115)
> at org.jboss.dmr.ModelNode.get(ModelNode.java:861)
> at org.jboss.as.cli.impl.ValueTypeCompleter$ValueTypeCallbackHandler.getCandidates(ValueTypeCompleter.java:475)
> at org.jboss.as.cli.impl.ValueTypeCompleter.complete(ValueTypeCompleter.java:321)
> at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:254)
> at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:74)
> at org.jboss.as.cli.CommandCompleter.doComplete(CommandCompleter.java:137)
> at org.jboss.as.cli.CommandCompleter.complete(CommandCompleter.java:64)
> at org.jboss.as.cli.impl.Console$Factory$1$1.complete(Console.java:143)
> at org.jboss.aesh.console.AeshCompletionHandler.complete(AeshCompletionHandler.java:155)
> at org.jboss.aesh.console.AeshInputProcessor.complete(AeshInputProcessor.java:427)
> at org.jboss.aesh.console.AeshInputProcessor.parseOperation(AeshInputProcessor.java:165)
> at org.jboss.aesh.console.Console.processInternalOperation(Console.java:773)
> at org.jboss.aesh.console.Console.execute(Console.java:733)
> at org.jboss.aesh.console.Console.access$900(Console.java:73)
> at org.jboss.aesh.console.Console$6.run(Console.java:642)
> 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)
> [mkopecky@dhcp-10-40-5-171 bin]$
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-7209) Operation to list installed Resource Adapters
by Jesper Pedersen (JIRA)
[ https://issues.jboss.org/browse/WFLY-7209?page=com.atlassian.jira.plugin.... ]
Jesper Pedersen reassigned WFLY-7209:
-------------------------------------
Assignee: Stefano Maestri (was: Jesper Pedersen)
> Operation to list installed Resource Adapters
> ---------------------------------------------
>
> Key: WFLY-7209
> URL: https://issues.jboss.org/browse/WFLY-7209
> Project: WildFly
> Issue Type: Feature Request
> Components: JCA
> Reporter: Guillermo González de Agüero
> Assignee: Stefano Maestri
> Fix For: 10.1.0.Final
>
>
> Currently there's no way to list all the installed Resource Adapters. Only configured resource adapters can be queried. However, they are automatically enabled at deployment time.
> I propose to add a new operation to list installed RAs and their configuration, similar to the one available for JDBC drivers. This would allow HAL to provide a wizard of available options when configuring them.
> The command would be something like: /subsystem=resource-adapters:installed-resource-adapters-list()
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months