[JBoss JIRA] (WFLY-8238) Unable to undefine credential-reference
by Tomas Hofman (JIRA)
[ https://issues.jboss.org/browse/WFLY-8238?page=com.atlassian.jira.plugin.... ]
Tomas Hofman commented on WFLY-8238:
------------------------------------
Thanks [~brian.stansberry], that's what I suspected. I'm working on removing {{AlternativeAttributeCheckHandler}} and finding a sensible setting for affected attributes.
These are the affected attributes:
Bridge: discovery-group, static-connectors
ClusterConnection: discovery-group, allow-direct-connection-only, connector-refs
BroadcastGroup, DiscoveryGroup: socket-binding, jgroups-channel
LiveOnly, ReplicationSlave, SharedStoreSlave: scale-down-connectors, scale-down-discovery-group
ConnectionFactory, PooledConnectionFactory: discovery-group, connectors
All of those attributes are currently marked as optional, however in same cases the attributes are required during resource creation by a custom validation. In those cases I intend to change them to required.
> Unable to undefine credential-reference
> ---------------------------------------
>
> Key: WFLY-8238
> URL: https://issues.jboss.org/browse/WFLY-8238
> Project: WildFly
> Issue Type: Bug
> Components: JMS, Security
> Reporter: Claudio Miranda
> Assignee: Tomas Hofman
>
> A bridge is added and a credential-reference is set.
> However a "password" attribute cannot be set as the alternatives constraint validates the data, but the password attribute has a default value.
> Also neither credential-reference and password are required=true, so they may be undefined.
> {code}
> /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:add(discovery-group=mane,queue-name=DLQ,forwarding-address=DLQ)
> /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:write-attribute(name=credential-reference,value={clear-text=senha1})
> /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:undefine-attribute(name=credential-reference)
> {
> "outcome" => "failed",
> "failure-description" => {"domain-failure-description" => "WFLYMSGAMQ0069: Attribute (credential-reference) can not been undefined as the resource does not define any alternative to this attribute."},
> "rolled-back" => true
> }
> {code}
> The same problem, when user adds a bridge with a password and later wants to undefine it to add a credential-reference
> {code}
> /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:add(discovery-group=mane,queue-name=DLQ,forwarding-address=DLQ,password=senha1)
> /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:undefine-attribute(name=password)
> {
> "outcome" => "failed",
> "failure-description" => {"domain-failure-description" => "WFLYMSGAMQ0069: Attribute (password) can not been undefined as the resource does not define any alternative to this attribute."},
> "rolled-back" => true
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 3 months
[JBoss JIRA] (WFCORE-2348) Error while starting WildFly as service in domain mode using init scripts.
by Radovan Stancel (JIRA)
Radovan Stancel created WFCORE-2348:
---------------------------------------
Summary: Error while starting WildFly as service in domain mode using init scripts.
Key: WFCORE-2348
URL: https://issues.jboss.org/browse/WFCORE-2348
Project: WildFly Core
Issue Type: Bug
Components: Scripts
Affects Versions: 3.0.0.Alpha18
Environment: Fedora, RHEL
Reporter: Radovan Stancel
Assignee: Radovan Stancel
Priority: Minor
When starting WildFly as a service in domain mode using init scripts there appears in console.log error:
/usr/bin/dirname: unrecognized option '--domain-config=domain.xml'
Try '/usr/bin/dirname --help' for more information.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 3 months
[JBoss JIRA] (WFCORE-1563) Failed CLI batch command with "deploy --force" for replace deployment
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1563?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration updated WFCORE-1563:
--------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1417679
Bugzilla Update: Perform
> Failed CLI batch command with "deploy --force" for replace deployment
> ---------------------------------------------------------------------
>
> Key: WFCORE-1563
> URL: https://issues.jboss.org/browse/WFCORE-1563
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.1.0.Final, 3.0.0.Alpha1
> Reporter: ted won
> Assignee: ted won
> Priority: Minor
> Labels: cli, jboss
> Fix For: 3.0.0.Alpha2
>
> Attachments: jboss-ejb-in-ear.ear
>
>
> Using 'deploy --force' command on CLI batch mode fails and returns an error message: "Request is missing the address part."
> {code:title=Command}
> jboss-cli.sh --connect --controller=127.0.0.1:9999 --user=admin --password=xxx --file="deploy.cli"
> {code}
> {code:title=deploy.cli}
> batch
> deploy --force ./jboss-ejb-in-ear.ear
> run-batch
> {code}
> {panel:title=Full Error message}
> Failed to handle 'run-batch': org.jboss.as.cli.CommandFormatException: Request is missing the address part.: Request is missing the address part.
> or
> The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error): Request is missing the address part.
> {panel}
> {panel:title=Expected message}
> The batch executed successfully
> {panel}
> However, it's working in "WildFly 10 CLI interactive mode" and "JBoss AS 7 CLI batch" without error.
> There is no adding "address" key in buildDeploymentReplace() of DeployHandler like below.
> Even though on CLI batch mode it validates existence of "address" key in request with Util.validateRequest(), when 'run-batch' command execute in org.jboss.as.cli.handlers.batch.BatchRunHandler.doHandle()
> -------------------------------------------------------------------------------------------
> * First deploy: add by org.jboss.as.cli.handlers.DeployHandler.buildDeploymentAdd()
> {code}
> {
> "operation" => "add",
> "address" => {"deployment" => "jboss-ejb-in-ear.ear"},
> "content" => [{"bytes" => bytes {
> ...
> }}]
> }
> {code}
> -------------------------------------------------------------------------------------------
> * After deploy: replace by org.jboss.as.cli.handlers.DeployHandler.buildDeploymentReplace()
> {code}
> {
> "operation" => "full-replace-deployment",
> "name" => "jboss-ejb-in-ear.ear",
> "enabled" => true,
> "content" => [{"bytes" => bytes {
> ...
> }}]
> }
> {code}
> -------------------------------------------------------------------------------------------
> * Expected by org.jboss.as.cli.handlers.DeployHandler.buildDeploymentReplace()
> {code}
> {
> "operation" => "full-replace-deployment",
> "name" => "jboss-ejb-in-ear.ear",
> "address" => [],
> "enabled" => true,
> "content" => [{"bytes" => bytes {
> ...
> }}]
> }
> {code}
> -------------------------------------------------------------------------------------------
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 3 months
[JBoss JIRA] (WFLY-8275) 2PC Inflow transactions don't work for JTA
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-8275?page=com.atlassian.jira.plugin.... ]
Ondra Chaloupka commented on WFLY-8275:
---------------------------------------
This issue being fixed needs fix in wildfly transactional client which is part of version 1.0.0.Beta18
then wiring in connector subsystem needs to be done
and fix in Narayana to wiring from JCA works too.
> 2PC Inflow transactions don't work for JTA
> ------------------------------------------
>
> Key: WFLY-8275
> URL: https://issues.jboss.org/browse/WFLY-8275
> Project: WildFly
> Issue Type: Bug
> Components: JCA, Transactions
> Reporter: Ondra Chaloupka
> Assignee: Ondra Chaloupka
> Priority: Blocker
>
> Inflow transactions are initiated by an external enterprise information system (EIS). If a message arrive from the EIS in a transaction, the EAP should import the tx context (thru resource adapter (RAR)) and perform the business process on that message in the same transaction.
> In our test two participants are part of TM subordinate transaction driven by RAR and two phase commit (2PC) is expected to be processed by TM on those participants.
> It seems that since DR12 TM doesn't know about inflow tx and returns XA_RDONLY on prepare call. After that it ends up with XAException on commit call.
> {code}
> 2017-02-21 10:41:38,265 ERROR [org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit] (default-threads - 1) Can't run javax.resource.spi.XATerminator command based on message 'commit 1' XAException 'null' with error code 'XAER_INVAL'?: javax.transaction.xa.XAException
> at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.XATerminatorImple.commit(XATerminatorImple.java:98)
> at org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit.run(Unknown Source)
> at org.jboss.jca.core.workmanager.WorkWrapper.runWork(WorkWrapper.java:445)
> at org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:223)
> at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33)
> at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:808)
> at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45)
> at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:828)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
> Full log attached.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 3 months
[JBoss JIRA] (WFLY-8275) 2PC Inflow transactions don't work for JTA
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-8275?page=com.atlassian.jira.plugin.... ]
Ondra Chaloupka edited comment on WFLY-8275 at 3/2/17 6:12 AM:
---------------------------------------------------------------
This issue being fixed needs fix in wildfly transactional client which is part of version 1.0.0.Beta18
(see https://github.com/wildfly/wildfly-transaction-client/pull/14)
then wiring in connector subsystem needs to be done
and fix in Narayana to wiring from JCA works too.
was (Author: ochaloup):
This issue being fixed needs fix in wildfly transactional client which is part of version 1.0.0.Beta18
then wiring in connector subsystem needs to be done
and fix in Narayana to wiring from JCA works too.
> 2PC Inflow transactions don't work for JTA
> ------------------------------------------
>
> Key: WFLY-8275
> URL: https://issues.jboss.org/browse/WFLY-8275
> Project: WildFly
> Issue Type: Bug
> Components: JCA, Transactions
> Reporter: Ondra Chaloupka
> Assignee: Ondra Chaloupka
> Priority: Blocker
>
> Inflow transactions are initiated by an external enterprise information system (EIS). If a message arrive from the EIS in a transaction, the EAP should import the tx context (thru resource adapter (RAR)) and perform the business process on that message in the same transaction.
> In our test two participants are part of TM subordinate transaction driven by RAR and two phase commit (2PC) is expected to be processed by TM on those participants.
> It seems that since DR12 TM doesn't know about inflow tx and returns XA_RDONLY on prepare call. After that it ends up with XAException on commit call.
> {code}
> 2017-02-21 10:41:38,265 ERROR [org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit] (default-threads - 1) Can't run javax.resource.spi.XATerminator command based on message 'commit 1' XAException 'null' with error code 'XAER_INVAL'?: javax.transaction.xa.XAException
> at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.XATerminatorImple.commit(XATerminatorImple.java:98)
> at org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit.run(Unknown Source)
> at org.jboss.jca.core.workmanager.WorkWrapper.runWork(WorkWrapper.java:445)
> at org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:223)
> at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33)
> at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:808)
> at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45)
> at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:828)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
> Full log attached.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 3 months
[JBoss JIRA] (WFCORE-1351) FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager
by Ivo Studensky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1351?page=com.atlassian.jira.plugi... ]
Ivo Studensky commented on WFCORE-1351:
---------------------------------------
Except of WFNC-23 posted above, it works now. The testcase, however, contains permissions which are not needed in order to pass successfully on Security Manager. So I've filed PR to remove them.
> FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager
> ------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1351
> URL: https://issues.jboss.org/browse/WFCORE-1351
> Project: WildFly Core
> Issue Type: Bug
> Components: Remoting, Security
> Reporter: Ondrej Kotek
> Assignee: Ivo Studensky
> Priority: Critical
> Fix For: 3.0.0.Beta7
>
> Attachments: 1-no-createEndpoint-permission.stacktrace, 2-no-createXnioWorker-permission.stacktrace, 3-no-addConnectionProvider-permission.stacktrace, 4-no-accessDeclaredMembers-permission.stractrace, 5-no-suppressAccessChecks-permission.stracktrace
>
>
> # Running _NestedRemoteContextTestCase_ (from WildFly _testsuite/integration/basic_) with security manager, like
> {noformat}
> ./integration-tests.sh -Dts.basic -Dts.noSmoke -Dtest=NestedRemoteContextTestCase -Dsecurity.manager
> {noformat}
> results in exception:
> {noformat}
> java.io.IOException: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found
> {noformat}
> To make it work, permissions like following need to be added to _permissions.xml_ of _ejb.ear_:
> {noformat}
> new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/xnio/nio/main/*", "read"),
> new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/marshalling/river/main/*", "read"),
> new RemotingPermission("createEndpoint"),
> new RuntimePermission("createXnioWorker"),
> new RemotingPermission("addConnectionProvider"),
> new RuntimePermission("modifyThread"),
> new RuntimePermission("accessDeclaredMembers"),
> new ReflectPermission("suppressAccessChecks")
> {noformat}
> which is very confusing.
> Why do I need add seemingly unrelated permissions, like _FilePermission_ for XNIO and marshalling or _RuntimePermission_ for createXnioWorker? Such behavior should be fixed or properly documented.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 3 months
[JBoss JIRA] (WFLY-8275) 2PC Inflow transactions don't work for JTA
by Ondra Chaloupka (JIRA)
Ondra Chaloupka created WFLY-8275:
-------------------------------------
Summary: 2PC Inflow transactions don't work for JTA
Key: WFLY-8275
URL: https://issues.jboss.org/browse/WFLY-8275
Project: WildFly
Issue Type: Bug
Components: Transactions, JCA
Reporter: Ondra Chaloupka
Assignee: Tom Jenkinson
Priority: Blocker
Inflow transactions are initiated by an external enterprise information system (EIS). If a message arrive from the EIS in a transaction, the EAP should import the tx context (thru resource adapter (RAR)) and perform the business process on that message in the same transaction.
In our test two participants are part of TM subordinate transaction driven by RAR and two phase commit (2PC) is expected to be processed by TM on those participants.
It seems that since DR12 TM doesn't know about inflow tx and returns XA_RDONLY on prepare call. After that it ends up with XAException on commit call.
{code}
2017-02-21 10:41:38,265 ERROR [org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit] (default-threads - 1) Can't run javax.resource.spi.XATerminator command based on message 'commit 1' XAException 'null' with error code 'XAER_INVAL'?: javax.transaction.xa.XAException
at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.XATerminatorImple.commit(XATerminatorImple.java:98)
at org.jboss.as.test.jbossts.crashrec.jca.rar.TestResourceTxnWorkUnit.run(Unknown Source)
at org.jboss.jca.core.workmanager.WorkWrapper.runWork(WorkWrapper.java:445)
at org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:223)
at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33)
at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:808)
at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45)
at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:828)
at java.lang.Thread.run(Thread.java:745)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
{code}
Full log attached.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 3 months