[JBoss JIRA] (WFCORE-2876) runtime-failure-causes-rollback does not seem to have effect when configured in model
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2876?page=com.atlassian.jira.plugi... ]
Miroslav Novak updated WFCORE-2876:
-----------------------------------
Steps to Reproduce:
Steps to reproduce:
{code}
git clone git://git.app.eng.bos.redhat.com/jbossqe/eap-tests-hornetq.git
cd eap-tests-hornetq/scripts/
git checkout master
groovy -DEAP_VERSION=7.1.0.DR19 PrepareServers7.groovy
export WORKSPACE=$PWD
export JBOSS_HOME_1=$WORKSPACE/server1/jboss-eap
export JBOSS_HOME_2=$WORKSPACE/server2/jboss-eap
export JBOSS_HOME_3=$WORKSPACE/server3/jboss-eap
export JBOSS_HOME_4=$WORKSPACE/server4/jboss-eap
cd ../jboss-hornetq-testsuite/
mvn clean test -Dtest=ReplicatedColocatedClusterFailoverTestCase#testFailbackWithMdbsShutdown -DfailIfNoTests=false -Deap=7x | tee log
{code}
There is 2nd test which is deploying MDB using CLI {{deploy}} command and shows that MDB is awakens on node 2 once Artemis live activates and deploys queues/connection factories:
ReplicatedColocatedClusterFailoverTestCase#testFailbackWithMdbsShutdownDeployUsingCLI
> runtime-failure-causes-rollback does not seem to have effect when configured in model
> -------------------------------------------------------------------------------------
>
> Key: WFCORE-2876
> URL: https://issues.jboss.org/browse/WFCORE-2876
> Project: WildFly Core
> Issue Type: Bug
> Components: Deployment Scanner
> Affects Versions: 3.0.0.Beta21
> Reporter: Miroslav Novak
> Assignee: ehsavoie Hugonnet
>
> This is follow up on discussion in WFCORE-1912. There is difference in behavior if deployment is deployed like:
> {code}deploy ~/tmp/mdb1.jar --unmanaged --headers={rollback-on-runtime-failure=false}{code}
> and if it's deployed by copying to deployments directory and setting {{rollback-on-runtime-failure=false}} in model:
> {code}
> /subsystem=deployment-scanner/scanner=default:write-attribute(name=runtime-failure-causes-rollback,value=false)
> {code}
> If it's deployed by the 1st way using CLI {{deploy}} command then If deployment is missing some dependencies (like connection factories, queues/topics) and those are added later then deployment is able recover from it and start working without need to reload/restart server or redeploy.
> However if it's deployed the 2nd way then deployment does not recover when missing dependencies are added. It looks like attribute {{runtime-failure-causes-rollback}} does not have the effect in this case.
> This is causing problems when Artemis is configured in colocated HA topology with replicated journal where it takes some time for Artemis to activate but deployment which depends on some connection factories and queues has already tried to deploy. We need deployment to recover from this situation automatically. Restart/Reload will not help in this case as it would end up in the same situation. Only manual redeploy will help which is a workaround.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (WFCORE-2879) UnrecoverableKeyException: Cannot recover key when using Credential Reference
by Martin Choma (JIRA)
Martin Choma created WFCORE-2879:
------------------------------------
Summary: UnrecoverableKeyException: Cannot recover key when using Credential Reference
Key: WFCORE-2879
URL: https://issues.jboss.org/browse/WFCORE-2879
Project: WildFly Core
Issue Type: Bug
Components: Security
Reporter: Martin Choma
Assignee: Darran Lofthouse
Priority: Blocker
Unable to configure ssl using credential reference.
{code:server.log}
08:00:24,687 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service org.wildfly.core.management.security.realm.ManagementWebRealmCr.key-manager: org.jboss.msc.service.StartException in service org.wildfly.core.management.security.realm.ManagementWebRealmCr.key-manager: WFLYDM0018: Unable to start service
at org.jboss.as.domain.management.security.AbstractKeyManagerService.start(AbstractKeyManagerService.java:91)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
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.security.UnrecoverableKeyException: Cannot recover key
at sun.security.provider.KeyProtector.recover(KeyProtector.java:328)
at sun.security.provider.JavaKeyStore.engineGetKey(JavaKeyStore.java:146)
at sun.security.provider.JavaKeyStore$JKS.engineGetKey(JavaKeyStore.java:56)
at sun.security.provider.KeyStoreDelegator.engineGetKey(KeyStoreDelegator.java:96)
at sun.security.provider.JavaKeyStore$DualFormatJKS.engineGetKey(JavaKeyStore.java:70)
at java.security.KeyStore.getKey(KeyStore.java:1023)
at sun.security.ssl.SunX509KeyManagerImpl.<init>(SunX509KeyManagerImpl.java:133)
at sun.security.ssl.KeyManagerFactoryImpl$SunX509.engineInit(KeyManagerFactoryImpl.java:70)
at javax.net.ssl.KeyManagerFactory.init(KeyManagerFactory.java:256)
at org.jboss.as.domain.management.security.AbstractKeyManagerService.createKeyManagers(AbstractKeyManagerService.java:136)
at org.jboss.as.domain.management.security.AbstractKeyManagerService.start(AbstractKeyManagerService.java:89)
... 5 more
08:00:24,692 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0006: Undertow HTTPS listener https listening on 127.0.0.1:8443
08:00:24,696 INFO [org.jboss.ws.common.management] (MSC service thread 1-4) JBWS022052: Starting JBossWS 5.1.8.Final-redhat-1 (Apache CXF 3.1.11.redhat-1)
08:00:24,702 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
("core-service" => "management"),
("security-realm" => "ManagementWebRealmCr")
]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.core.management.security.realm.ManagementWebRealmCr.key-manager" => "WFLYDM0018: Unable to start service
Caused by: java.security.UnrecoverableKeyException: Cannot recover key"}}
{code}
When I use {{key-password}} instead of {{key-password-credential-reference}} I am able to make it work.
{code}
/core-service=management/security-realm=ManagementWebRealmCr/server-identity=ssl:add(keystore-path=server.keystore, keystore-relative-to=jboss.server.config.dir,keystore-password-credential-reference={clear-text=123456}, key-password=123456)
{code}
Note, I also get UnrecoverableKeyException: Cannot recover key when I don't specify key-password nor key-password-credential-reference.
{code}
/core-service=management/security-realm=ManagementWebRealmCr/server-identity=ssl:add(keystore-path=server.keystore, keystore-relative-to=jboss.server.config.dir,keystore-password-credential-reference={clear-text=123456})
{code}
In legacy if {{key-password}} is ommitted {{keystore-password}} is used instead.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (ELY-1206) Elytron Audit Logging's rotating-file-audit-log throws IllegalArgumentException if suffix property is not specified
by Yeray Borges (JIRA)
[ https://issues.jboss.org/browse/ELY-1206?page=com.atlassian.jira.plugin.s... ]
Yeray Borges moved JBEAP-11182 to ELY-1206:
-------------------------------------------
Project: WildFly Elytron (was: JBoss Enterprise Application Platform)
Key: ELY-1206 (was: JBEAP-11182)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: (was: Security)
Affects Version/s: 1.1.0.Beta47
(was: 7.1.0.DR17)
> Elytron Audit Logging's rotating-file-audit-log throws IllegalArgumentException if suffix property is not specified
> -------------------------------------------------------------------------------------------------------------------
>
> Key: ELY-1206
> URL: https://issues.jboss.org/browse/ELY-1206
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta47
> Reporter: Yeray Borges
> Assignee: Yeray Borges
> Priority: Critical
>
> {{rotating-file-audit}} throws {{IllegalArgumentException}} if user tries to add a new {{rotating-audit-file}} and does not specify {{suffix}} property.
> Steps to reproduce: {{/subsystem=elytron/rotating-file-audit-log=rotating-audit:add(path=rotating-audit.log)}}
> Following output is given in jboss-cli
> {code}
> {
> "outcome" => "failed",
> "failure-description" => {"WFLYCTL0080: Failed services" => {"org.wildfly.security.security-event-listener.rotating-audit" => "Failed to start service
> Caused by: java.lang.IllegalArgumentException: Illegal pattern character 'n'"}},
> "rolled-back" => true
> }
> {code}
> and following one in server log:
> {code}
> 12:45:41,381 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service org.wildfly.security.security-event-listener.rotating-audit: org.jboss.msc.service.StartException in service org.wildfly.security.security-event-listener.rotating-audit: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978)
> 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: Illegal pattern character 'n'
> at java.text.SimpleDateFormat.compile(SimpleDateFormat.java:826)
> at java.text.SimpleDateFormat.initialize(SimpleDateFormat.java:634)
> at java.text.SimpleDateFormat.<init>(SimpleDateFormat.java:605)
> at java.text.SimpleDateFormat.<init>(SimpleDateFormat.java:580)
> at org.wildfly.security.audit.RotatingFileAuditEndpoint$Builder.setSuffix(RotatingFileAuditEndpoint.java:289)
> at org.wildfly.extension.elytron.AuditResourceDefinitions$2.lambda$getValueSupplier$2(AuditResourceDefinitions.java:235)
> at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> ... 3 more
> 12:45:41,382 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 5) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("rotating-file-audit-log" => "rotating-audit")
> ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.security.security-event-listener.rotating-audit" => "Failed to start service
> Caused by: java.lang.IllegalArgumentException: Illegal pattern character 'n'"}}
> {code}
> Note: there is an easy workaround - if user specifies {{suffix}} property then adding a new {{rotating-audit-file}} works fine, e.g. {{/subsystem=elytron/rotating-file-audit-log=rotating-audit:add(path=rotating-audit.log,suffix=y-M-d)}} passes successfully.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (ELY-1206) Elytron Audit Logging's rotating-file-audit-log throws IllegalArgumentException if suffix property is not specified
by Yeray Borges (JIRA)
[ https://issues.jboss.org/browse/ELY-1206?page=com.atlassian.jira.plugin.s... ]
Yeray Borges updated ELY-1206:
------------------------------
Git Pull Request: (was: https://github.com/wildfly/wildfly-core/pull/2425)
> Elytron Audit Logging's rotating-file-audit-log throws IllegalArgumentException if suffix property is not specified
> -------------------------------------------------------------------------------------------------------------------
>
> Key: ELY-1206
> URL: https://issues.jboss.org/browse/ELY-1206
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta47
> Reporter: Yeray Borges
> Assignee: Yeray Borges
> Priority: Critical
>
> {{rotating-file-audit}} throws {{IllegalArgumentException}} if user tries to add a new {{rotating-audit-file}} and does not specify {{suffix}} property.
> Steps to reproduce: {{/subsystem=elytron/rotating-file-audit-log=rotating-audit:add(path=rotating-audit.log)}}
> Following output is given in jboss-cli
> {code}
> {
> "outcome" => "failed",
> "failure-description" => {"WFLYCTL0080: Failed services" => {"org.wildfly.security.security-event-listener.rotating-audit" => "Failed to start service
> Caused by: java.lang.IllegalArgumentException: Illegal pattern character 'n'"}},
> "rolled-back" => true
> }
> {code}
> and following one in server log:
> {code}
> 12:45:41,381 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service org.wildfly.security.security-event-listener.rotating-audit: org.jboss.msc.service.StartException in service org.wildfly.security.security-event-listener.rotating-audit: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978)
> 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: Illegal pattern character 'n'
> at java.text.SimpleDateFormat.compile(SimpleDateFormat.java:826)
> at java.text.SimpleDateFormat.initialize(SimpleDateFormat.java:634)
> at java.text.SimpleDateFormat.<init>(SimpleDateFormat.java:605)
> at java.text.SimpleDateFormat.<init>(SimpleDateFormat.java:580)
> at org.wildfly.security.audit.RotatingFileAuditEndpoint$Builder.setSuffix(RotatingFileAuditEndpoint.java:289)
> at org.wildfly.extension.elytron.AuditResourceDefinitions$2.lambda$getValueSupplier$2(AuditResourceDefinitions.java:235)
> at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> ... 3 more
> 12:45:41,382 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 5) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("rotating-file-audit-log" => "rotating-audit")
> ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.security.security-event-listener.rotating-audit" => "Failed to start service
> Caused by: java.lang.IllegalArgumentException: Illegal pattern character 'n'"}}
> {code}
> Note: there is an easy workaround - if user specifies {{suffix}} property then adding a new {{rotating-audit-file}} works fine, e.g. {{/subsystem=elytron/rotating-file-audit-log=rotating-audit:add(path=rotating-audit.log,suffix=y-M-d)}} passes successfully.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (WFCORE-389) Alllow non persistent configuration(runtime) changes for server groups and domain using CLI
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-389?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-389:
------------------------------------
Fix Version/s: 3.0.0.Beta24
(was: 3.0.0.CR1)
> Alllow non persistent configuration(runtime) changes for server groups and domain using CLI
> -------------------------------------------------------------------------------------------
>
> Key: WFCORE-389
> URL: https://issues.jboss.org/browse/WFCORE-389
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Shay Matasaro
> Assignee: Brian Stansberry
> Labels: EAP, domain-mode
> Fix For: 3.0.0.Beta24
>
>
> Using the CLI , It is currently not possible to make runtime config changes to multiple servers , unless you are using a roll-out plan
> One example is the ability to disable a mod-cluster context on multiple servers at once.
> Since this operation does not affect the persistent server config it is currently not supported.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (WFLY-8854) Clean up managed domain handling of messaging-activemq broadcast-group and cluster-connection runtime-only ops
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-8854:
--------------------------------------
Summary: Clean up managed domain handling of messaging-activemq broadcast-group and cluster-connection runtime-only ops
Key: WFLY-8854
URL: https://issues.jboss.org/browse/WFLY-8854
Project: WildFly
Issue Type: Sub-task
Components: JMS
Reporter: Brian Stansberry
Assignee: Jeff Mesnil
Subtask for the following items from the parent issue:
{quote}
8) The messaging-activemq broadcast-group resource has problematic 'start' and 'stop' ops. These are not registered as runtime-only, but they are. They are registered on the profile resource and are not read-only, so the DC rolls them out to the domain. So, they are pre-existing ops that break the no-runtime-only-on-profile rule that WFCORE-389 is about rescinding. We have two
options here:
a) remove these ops on the profile as violations of the no-runtime-only-on-profile rule. This would be a breaking change. But it may be the correct thing to do anyway if it is unsafe to invoke these on the profile and have that roll out to all servers.
b) Correct the description of these to declare runtime-only.
{quote}
Task for this is to make a decision.
{quote}
9) The messaging-activemq broadcast-group resource also has problematic a get-connector-pairs-as-json op. This is a read-only op so it currently will not roll out. It will also fail if executed against the profile resource, as it fails if there is no activemq server present. So, the options here are:
a) Remove the op from the profile resource. It never worked anyway.
b) Allow them to roll out. This would be new behavior though.
c) Add OperationEntry.Flag.HOST_CONTROLLER_ONLY to the operation definition to prevent that rollout.
IMHO option c) is kind of silly, leaving a broken op in place, but it's a valid "emergency" step to prevent roll out inadvertently being turned on while a decision between a) and b) is made. So that's what will be done as part of this work.
{quote}
As part of the parent task, option c) will be put in place. Task here is to decide final resolution.
{quote}
10) The messaging-activemq cluster-connection resource has problematic 'start' and 'stop' ops. These are not registered as runtime-only, but they are. They are registered on the profile resource and are not read-only, so the DC rolls them out to the domain. So, they are pre-existing ops that break the no-runtime-only-on-profile rule that WFCORE-389 is about rescinding. We have two
options here:
a) remove these ops on the profile as violations of the no-runtime-only-on-profile rule. This would be a breaking change. But it may be the correct thing to do anyway if it is unsafe to invoke these on the profile and have that roll out to all servers.
b) Correct the description of these to declare runtime-only.
{quote}
Nothing was done re: this in the parent task.
{quote}
11) The messaging-activemq cluster-connection resource also has problematic a get-nodes op. This is a read-only op so it currently will not roll out. It will also fail if executed against the profile resource, as it fails if there is no activemq server present. So, the options here are:
a) Remove the op from the profile resource. It never worked anyway.
b) Allow them to roll out. This would be new behavior though.
c) Add OperationEntry.Flag.HOST_CONTROLLER_ONLY to the operation definition to prevent that rollout.
IMHO option c) is kind of silly, leaving a broken op in place, but it's a valid "emergency" step to prevent roll out inadvertently being turned on while a decision between a) and b) is made. So that's what will be done as part of this work.
{quote}
As part of the parent task, option c) will be put in place. Task here is to decide final resolution.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (WFLY-8853) CachedConnectionManager custom operations are read-only
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-8853:
--------------------------------------
Summary: CachedConnectionManager custom operations are read-only
Key: WFLY-8853
URL: https://issues.jboss.org/browse/WFLY-8853
Project: WildFly
Issue Type: Sub-task
Components: JCA
Reporter: Brian Stansberry
Assignee: Brian Stansberry
*CRITICAL: DO NOT IMPLEMENT THIS IF WFCORE-2828 IS NOT IN PLACE.* Otherwise existing behavior will regress.
Subtask for the following item from the parent issue:
{quote}
JcaCachedConnectionManagerDefinition.CcmOperations has two operations that are not declared to be read-only that are registered on the profile resource. So these are pre-existing ops that break the no-runtime-only-on-profile rule that WFCORE-389 is about rescinding. A twist with these is they seem to actually be read-only and should be described as such. But if we do that we must implement WFCORE-2858 to avoid breaking existing behavior.
{quote}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (WFLY-8852) Clean up managed domain handling of the transaction subsystem's 'probe' operation
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-8852:
--------------------------------------
Summary: Clean up managed domain handling of the transaction subsystem's 'probe' operation
Key: WFLY-8852
URL: https://issues.jboss.org/browse/WFLY-8852
Project: WildFly
Issue Type: Sub-task
Components: Transactions
Reporter: Brian Stansberry
Assignee: Tom Jenkinson
Subtask for this item from the parent issue:
{quote}
The transaction subsystem's "probe" operation. A read-only, runtime-only op registered on the profile resource but which is functionally a no-op if invoked on the profile resource. But WFCORE-2858 would mean this now gets rolled out to all servers in the domain that use the profile, triggering an actual probe on all. So, if we do WFCORE-2858 we could:
a) Accept this, and let the op roll out. That should be an RFE though, with analysis that rolling it out would be harmless.
b) Remove the op from the profile. It never did anything useful (just a no-op that isn't rolled out) so removing it is only
a semi-breaking change.
c) Add OperationEntry.Flag.HOST_CONTROLLER_ONLY to the operation definition to prevent that rollout.
Choice c) would let WFCORE-2858 go forward and preserve the status quo for this op, with a) and b) still options for the future, so that's what will be done as part of this work.
{quote}
The parent issue will do choice c); this issue is to decide the final status.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (WFLY-8851) Clean up managed domain handling of JSFImplListHandler
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-8851:
--------------------------------------
Summary: Clean up managed domain handling of JSFImplListHandler
Key: WFLY-8851
URL: https://issues.jboss.org/browse/WFLY-8851
Project: WildFly
Issue Type: Sub-task
Components: JSF
Reporter: Brian Stansberry
Assignee: Farah Juma
Subtask for this item from the parent issue:
{quote}
The JSF subsystem's "list-active-jsf-impl" op. A read-only, runtime-only op that does runtime work (scanning modules) in Stage.MODEL on the profile resource. Lots of rules being broken! What this op does now if invoked against the profile is tell you what jsf impls are present on the DC. Which is not the same thing as telling you what impls are present on "the domain" since different hosts in the domain can have different sets of modules. So the op needs a rethink.
a) If we correct the Stage.MODEL problem, we can't do WFCORE-2849. So we need to choose between the two.
b) If we do WFCORE-2858, this op will now start getting rolled out to the domain servers resulting in getting data from all servers. This is arguably the correct behavior, as now the user learns the true situation in the domain, not just on the DC. But if we decide we don't want that we'll need to add OperationEntry.Flag.HOST_CONTROLLER_ONLY to the operation definition to prevent that rollout.
c) If we do roll it out to the servers we can consider having it no longer do runtime work on the profile; i.e. don't analyze the DC, just the servers. That would remove the conflict with WFCORE-2849, but would be an incompatible change in behavior. I find it hard to believe anyone would be using this op in scripts though; not against the profile.
d) We could just stop registering it on the profile, but that's a loss of functionality.
Choice b) would let WFCORE-2858 go forward and preserve the status quo for this op, with a) c) and d) still options for the future.
{quote}
The parent task is going to do choice b) as a temp thing; this task is decide about the rest.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months