[JBoss JIRA] (WFLY-6527) Cannot lookup RemoteConnectionFactory using https-remoting
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-6527?page=com.atlassian.jira.plugin.... ]
David Lloyd resolved WFLY-6527.
-------------------------------
Fix Version/s: 11.0.0.Final
Resolution: Done
> Cannot lookup RemoteConnectionFactory using https-remoting
> ----------------------------------------------------------
>
> Key: WFLY-6527
> URL: https://issues.jboss.org/browse/WFLY-6527
> Project: WildFly
> Issue Type: Bug
> Components: Remoting
> Affects Versions: 10.0.0.Final
> Environment: RedHat Linux, Java 1.8
> Reporter: George Turner
> Assignee: David Lloyd
> Fix For: 11.0.0.Final
>
>
> I have successfully configured the system for two way ssl. I can connect to a topic from a standalone client, but I cannot connect with the same code from an EJB client using the following:
> Properties props = new Properties();
> props.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");
> ctx = new InitialContext(props);
> ConnectionFactory cf = (ConnectionFactory) ctx.lookup("jms/RemoteConnectionFactory");
> It seems to "attach" the stateless bean to the first remote instance and then the second remote instance lookup fails. I have tried using the EJBClientContext properties (as used for EJB lookups) but no help. There is VERY little documentation about using https-remoting.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-6540) Batch thread pool keepAlive setting seems to be ignored
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-6540?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFLY-6540:
-----------------------------------
This should be fixed as of 12.
> Batch thread pool keepAlive setting seems to be ignored
> -------------------------------------------------------
>
> Key: WFLY-6540
> URL: https://issues.jboss.org/browse/WFLY-6540
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Affects Versions: 10.0.0.Final
> Reporter: Martin Kouba
> Assignee: James Perkins
>
> Maybe I'm missing something but although the default _keepAlive_ is set to 30 seconds, the threads seem to run indefinitely - see also steps to reproduce.
> Snippet from the default config file:
> {code}
> <thread-pool name="batch">
> <max-threads count="10"/>
> <keepalive-time time="30" unit="seconds"/>
> </thread-pool>
> {code}
> Anyway, the {{UnboundedQueueThreadPoolService}}, or the underlying {{JBossThreadPoolExecutor}} respectively, used by the Batch subsystem is using the same {{corePoolSize}} and {{maximumPoolSize}} and it seems the core threads are not allowed to time out, i.e. {{org.jboss.threads.JBossThreadPoolExecutor.setAllowCoreThreadTimeout(boolean)}} is not used.
> Moreover, a {{JBossThreadPoolExecutor.setAllowCoreThreadTimeout(boolean)}} invocation would probably result in an infinite loop:
> {code}
> public void setAllowCoreThreadTimeout(final boolean allow) {
> setAllowCoreThreadTimeout(allow);
> }
> {code}
> should be replaced with:
> {code}
> public void setAllowCoreThreadTimeout(final boolean allow) {
> allowCoreThreadTimeOut(allow);
> }
> {code}
> Given that {{JBossThreadPoolExecutor}} is used by more subsystems this issue may affect other subsystems as well.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-1372) CompositeIndexProcessor::calculateModuleIndex does not respect import filters
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1372?page=com.atlassian.jira.plugi... ]
David Lloyd commented on WFCORE-1372:
-------------------------------------
TBH I'm wondering why we manually iterate all the modules for this. {{Module.iterateResources()}} is already recursive to dependencies. [~swd847] do you know we're doing this?
> CompositeIndexProcessor::calculateModuleIndex does not respect import filters
> -----------------------------------------------------------------------------
>
> Key: WFCORE-1372
> URL: https://issues.jboss.org/browse/WFCORE-1372
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Reporter: Alessio Soldano
> Assignee: David Lloyd
>
> I have a deployment whose manifest declares
> {noformat}Dependencies: org.foo annotations{noformat}
> What I'm trying to do with the org.foo module is basically filtering (and exposing) a subset of the org.apache.cxf.impl module. To achieve that, I have the following module.xml:
> {noformat}
> <module xmlns="urn:jboss:module:1.3" name="org.foo">
> <resources>
> </resources>
> <dependencies>
> <module name="org.apache.cxf.impl" services="import">
> <imports>
> <include path="META-INF/cxf"/>
> <include path="META-INF"/>
> <include path="org/apache/cxf/sts"/>
> <include path="org/apache/cxf/sts/**"/>
> <include path="org/apache/cxf/ws/security/sts/**"/>
> </imports>
> <exports>
> <include path="META-INF/cxf"/>
> <include path="META-INF"/>
> <include path="org/apache/cxf/sts"/>
> <include path="org/apache/cxf/sts/**"/>
> <include path="org/apache/cxf/ws/security/sts/**"/>
> </exports>
> </module>
> <module name="asm.asm" />
> <module name="javax.api" />
> <module name="javax.annotation.api" />
> <module name="javax.validation.api"/>
> <module name="javax.jms.api" />
> <module name="javax.jws.api" />
> <module name="javax.mail.api" />
> <module name="javax.resource.api" />
> <module name="javax.servlet.api" />
> <module name="javax.wsdl4j.api" />
> <module name="javax.xml.bind.api" services="import"/>
> <module name="com.fasterxml.jackson.jaxrs.jackson-jaxrs-json-provider"/>
> <module name="com.sun.xml.bind" services="import"/>
> <module name="javax.xml.soap.api" />
> <module name="javax.xml.stream.api" />
> <module name="javax.xml.ws.api" />
> <module name="javax.ws.rs.api" />
> <module name="org.apache.commons.lang" />
> <module name="org.apache.httpcomponents"/>
> <module name="org.apache.neethi" />
> <module name="org.apache.velocity" />
> <module name="org.apache.xml-resolver" />
> <module name="org.apache.ws.xmlschema" />
> <module name="org.apache.ws.security" />
> <module name="org.apache.santuario.xmlsec" />
> <module name="org.codehaus.jettison" />
> <module name="org.codehaus.woodstox" />
> <module name="org.joda.time" />
> <module name="org.opensaml" />
> </dependencies>
> </module>
> {noformat}
> The problem I'm having is that the composite annotation index that's attached to my deployment includes annotations from org.apache.cxf.impl module classes that are not included in the imports/exports above.
> To me, this is due to the CompositeIndexProcessor::calculateModuleIndex(Module module) method that uses PathFilters.getDefaultImportFilter() (instead of my filters) for adding stuff to the index.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (DROOLS-1825) [Guided Decision Table] Ability to change HIT policy in a decision table anytime
by Matthew Stevens (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1825?page=com.atlassian.jira.plugi... ]
Matthew Stevens commented on DROOLS-1825:
-----------------------------------------
In our BAA call this morning, a requirement came up to change Hit Policy while authoring a GDT. Is this something we should prioritize?
[~ibek] [~Rikkola] [~manstis] [~porcelli]
> [Guided Decision Table] Ability to change HIT policy in a decision table anytime
> --------------------------------------------------------------------------------
>
> Key: DROOLS-1825
> URL: https://issues.jboss.org/browse/DROOLS-1825
> Project: Drools
> Issue Type: Enhancement
> Components: Guided Decision Table Editor
> Affects Versions: 7.1.0.Beta2
> Reporter: Ivo Bek
> Assignee: Toni Rikkola
> Priority: Critical
> Labels: UX, UXTeam
> Attachments: DROOLS-1825 (Parent Rule).png, DecisionTable1.png, DecisionTable2.png, GDTAnalysis(a)2x.png, GDTColumns(a)2x.png
>
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> Today, it's possible to set 1 of 5 HIT policies when we create a new guided decision table. However, the user might not know which HIT policy he/she should use at this early beginning. Therefore, it should be possible to set the policy to None when we create a new guided decision table and set the HIT policy later after we add columns and rows, fill in some data and see and decide based on the created table how the rules should behave using the HIT policy.
> Thus, it should be possible to change HIT policy in a decision table anytime.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (DROOLS-1825) [Guided Decision Table] Ability to change HIT policy in a decision table anytime
by Matthew Stevens (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1825?page=com.atlassian.jira.plugi... ]
Matthew Stevens updated DROOLS-1825:
------------------------------------
Labels: UX UXTeam (was: UX)
> [Guided Decision Table] Ability to change HIT policy in a decision table anytime
> --------------------------------------------------------------------------------
>
> Key: DROOLS-1825
> URL: https://issues.jboss.org/browse/DROOLS-1825
> Project: Drools
> Issue Type: Enhancement
> Components: Guided Decision Table Editor
> Affects Versions: 7.1.0.Beta2
> Reporter: Ivo Bek
> Assignee: Toni Rikkola
> Priority: Critical
> Labels: UX, UXTeam
> Attachments: DROOLS-1825 (Parent Rule).png, DecisionTable1.png, DecisionTable2.png, GDTAnalysis(a)2x.png, GDTColumns(a)2x.png
>
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> Today, it's possible to set 1 of 5 HIT policies when we create a new guided decision table. However, the user might not know which HIT policy he/she should use at this early beginning. Therefore, it should be possible to set the policy to None when we create a new guided decision table and set the HIT policy later after we add columns and rows, fill in some data and see and decide based on the created table how the rules should behave using the HIT policy.
> Thus, it should be possible to change HIT policy in a decision table anytime.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (ELY-1533) Prevent SNAPSHOT versions of json-smart from being downloaded when building Elytron
by Farah Juma (JIRA)
Farah Juma created ELY-1533:
-------------------------------
Summary: Prevent SNAPSHOT versions of json-smart from being downloaded when building Elytron
Key: ELY-1533
URL: https://issues.jboss.org/browse/ELY-1533
Project: WildFly Elytron
Issue Type: Task
Components: Build
Reporter: Farah Juma
Assignee: Farah Juma
Current output when building:
{code}
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building WildFly Elytron 1.2.2.Final
[INFO] ------------------------------------------------------------------------
Downloading from central: https://repo.maven.apache.org/maven2/net/minidev/json-smart/maven-metadat...
Downloading from jboss-public-repository-group: http://repository.jboss.org/nexus/content/groups/public/net/minidev/json-...
Downloading from public-jboss: https://repository.jboss.org/nexus/content/groups/public-jboss/net/minide...
Downloaded from jboss-public-repository-group: http://repository.jboss.org/nexus/content/groups/public/net/minidev/json-... (313 B at 519 B/s)
Downloaded from central: https://repo.maven.apache.org/maven2/net/minidev/json-smart/maven-metadat... (849 B at 693 B/s)
Downloaded from public-jboss: https://repository.jboss.org/nexus/content/groups/public-jboss/net/minide... (849 B at 611 B/s)
Downloading from public-jboss: https://repository.jboss.org/nexus/content/groups/public-jboss/net/minide...
Downloading from jboss-public-repository-group: http://repository.jboss.org/nexus/content/groups/public/net/minidev/json-...
Downloaded from jboss-public-repository-group: http://repository.jboss.org/nexus/content/groups/public/net/minidev/json-... (1.2 kB at 3.2 kB/s)
Downloading from public-jboss: https://repository.jboss.org/nexus/content/groups/public-jboss/net/minide...
Downloading from jboss-public-repository-group: http://repository.jboss.org/nexus/content/groups/public/net/minidev/minid...
Downloaded from jboss-public-repository-group: http://repository.jboss.org/nexus/content/groups/public/net/minidev/minid... (598 B at 2.1 kB/s)
Downloading from jboss-public-repository-group: http://repository.jboss.org/nexus/content/groups/public/net/minidev/acces...
Downloading from public-jboss: https://repository.jboss.org/nexus/content/groups/public-jboss/net/minide...
Downloaded from jboss-public-repository-group: http://repository.jboss.org/nexus/content/groups/public/net/minidev/acces... (1.2 kB at 4.2 kB/s)
[INFO]
[INFO] --- maven-dependency-plugin:3.0.2:tree (default-cli) @ wildfly-elytron ---
[INFO] org.wildfly.security:wildfly-elytron:jar:1.2.2.Final
[INFO] +- org.jboss.logging:jboss-logging:jar:3.3.1.Final:compile
[INFO] +- org.jboss.logging:jboss-logging-annotations:jar:2.1.0.Final:provided
[INFO] +- org.jboss.logging:jboss-logging-processor:jar:2.1.0.Final:provided
[INFO] | \- org.jboss.jdeparser:jdeparser:jar:2.0.2.Final:provided
[INFO] +- org.jboss.logmanager:jboss-logmanager:jar:2.0.6.Final:provided
[INFO] +- org.jboss.modules:jboss-modules:jar:1.6.0.Final:provided (optional)
[INFO] +- org.kohsuke.metainf-services:metainf-services:jar:1.7:provided (optional)
[INFO] +- org.wildfly.client:wildfly-client-config:jar:1.0.0.Final:provided
[INFO] +- org.wildfly.common:wildfly-common:jar:1.2.0.Final:compile
[INFO] +- org.jboss.spec.javax.security.jacc:jboss-jacc-api_1.5_spec:jar:1.0.1.Final:provided
[INFO] | \- org.jboss.spec.javax.servlet:jboss-servlet-api_3.1_spec:jar:1.0.0.Final:provided
[INFO] +- org.jboss.spec.javax.json:jboss-json-api_1.0_spec:jar:1.0.0.Final:provided
[INFO] +- org.jboss.threads:jboss-threads:jar:2.2.1.Final:provided
[INFO] +- org.apache.directory.api:api-asn1-api:jar:1.0.0-M23:test
[INFO] | +- org.apache.directory.api:api-i18n:jar:1.0.0-M23:test
[INFO] | \- org.slf4j:slf4j-api:jar:1.7.7:test
[INFO] +- org.apache.directory.api:api-asn1-ber:jar:1.0.0-M23:test
[INFO] | \- org.apache.directory.api:api-util:jar:1.0.0-M23:test
[INFO] +- org.apache.directory.api:api-ldap-codec-core:jar:1.0.0-M23:test
[INFO] | +- org.apache.mina:mina-core:jar:2.0.7:test
[INFO] | +- commons-lang:commons-lang:jar:2.6:test
[INFO] | \- commons-collections:commons-collections:jar:3.2.1:test
[INFO] +- org.apache.directory.api:api-ldap-codec-standalone:jar:1.0.0-M23:test
[INFO] | +- org.apache.directory.api:api-ldap-net-mina:jar:1.0.0-M23:test
[INFO] | \- org.apache.directory.api:api-ldap-extras-codec:jar:1.0.0-M23:test
[INFO] +- org.apache.directory.api:api-ldap-extras-codec-api:jar:1.0.0-M23:test
[INFO] +- org.apache.directory.api:api-ldap-model:jar:1.0.0-M23:test
[INFO] | \- antlr:antlr:jar:2.7.7:test
[INFO] +- org.apache.directory.jdbm:apacheds-jdbm1:jar:2.0.0-M2:test
[INFO] +- org.apache.directory.server:apacheds-core-api:jar:2.0.0-M17:test
[INFO] | +- commons-io:commons-io:jar:2.4:test
[INFO] | +- org.apache.directory.server:apacheds-core-constants:jar:2.0.0-M17:test
[INFO] | +- org.apache.directory.server:apacheds-i18n:jar:2.0.0-M17:test
[INFO] | +- org.apache.directory.api:api-ldap-client-api:jar:1.0.0-M23:test
[INFO] | | \- commons-pool:commons-pool:jar:1.6:test
[INFO] | +- org.apache.directory.api:api-ldap-extras-aci:jar:1.0.0-M23:test
[INFO] | +- org.apache.directory.api:api-ldap-extras-util:jar:1.0.0-M23:test
[INFO] | +- org.apache.directory.api:api-ldap-schema-data:jar:1.0.0-M23:test
[INFO] | \- net.sf.ehcache:ehcache-core:jar:2.4.4:test
[INFO] +- org.apache.directory.server:apacheds-core-annotations:jar:2.0.0-M17:test
[INFO] | +- org.apache.directory.server:apacheds-core:jar:2.0.0-M17:test
[INFO] | | +- org.apache.directory.server:apacheds-interceptors-admin:jar:2.0.0-M17:test
[INFO] | | +- org.apache.directory.server:apacheds-interceptors-authn:jar:2.0.0-M17:test
[INFO] | | +- org.apache.directory.server:apacheds-interceptors-number:jar:2.0.0-M17:test
[INFO] | | +- org.apache.directory.server:apacheds-interceptors-authz:jar:2.0.0-M17:test
[INFO] | | +- org.apache.directory.server:apacheds-interceptors-changelog:jar:2.0.0-M17:test
[INFO] | | +- org.apache.directory.server:apacheds-interceptors-collective:jar:2.0.0-M17:test
[INFO] | | +- org.apache.directory.server:apacheds-interceptors-event:jar:2.0.0-M17:test
[INFO] | | +- org.apache.directory.server:apacheds-interceptors-exception:jar:2.0.0-M17:test
[INFO] | | +- org.apache.directory.server:apacheds-interceptors-journal:jar:2.0.0-M17:test
[INFO] | | +- org.apache.directory.server:apacheds-interceptors-normalization:jar:2.0.0-M17:test
[INFO] | | +- org.apache.directory.server:apacheds-interceptors-operational:jar:2.0.0-M17:test
[INFO] | | +- org.apache.directory.server:apacheds-interceptors-referral:jar:2.0.0-M17:test
[INFO] | | +- org.apache.directory.server:apacheds-interceptors-schema:jar:2.0.0-M17:test
[INFO] | | +- org.apache.directory.server:apacheds-interceptors-subtree:jar:2.0.0-M17:test
[INFO] | | \- org.apache.directory.server:apacheds-interceptors-trigger:jar:2.0.0-M17:test
[INFO] | | \- org.apache.directory.api:api-ldap-extras-trigger:jar:1.0.0-M23:test
[INFO] | +- org.apache.directory.server:apacheds-core-shared:jar:2.0.0-M17:test
[INFO] | +- org.apache.directory.server:apacheds-ldif-partition:jar:2.0.0-M17:test
[INFO] | +- org.apache.directory.server:apacheds-jdbm-partition:jar:2.0.0-M17:test
[INFO] | | \- org.apache.directory.server:apacheds-core-avl:jar:2.0.0-M17:test
[INFO] | +- org.apache.directory.server:apacheds-xdbm-partition:jar:2.0.0-M17:test
[INFO] | \- org.apache.directory.server:apacheds-mavibot-partition:jar:2.0.0-M17:test
[INFO] +- org.apache.directory.server:apacheds-interceptor-kerberos:jar:2.0.0-M17:test
[INFO] +- org.apache.directory.server:apacheds-kerberos-codec:jar:2.0.0-M17:test
[INFO] +- org.apache.directory.server:apacheds-protocol-kerberos:jar:2.0.0-M17:test
[INFO] | \- org.apache.directory.server:apacheds-protocol-shared:jar:2.0.0-M17:test
[INFO] +- org.apache.directory.server:apacheds-protocol-ldap:jar:2.0.0-M17:test
[INFO] | +- org.apache.directory.api:api-ldap-extras-sp:jar:1.0.0-M23:test
[INFO] | \- bouncycastle:bcprov-jdk15:jar:140:test
[INFO] +- org.apache.directory.mavibot:mavibot:jar:1.0.0-M5:test
[INFO] +- org.jboss.logmanager:log4j-jboss-logmanager:jar:1.1.4.Final:test
[INFO] +- org.jboss.slf4j:slf4j-jboss-logmanager:jar:1.0.3.GA:test
[INFO] +- junit:junit:jar:4.12:test
[INFO] | \- org.hamcrest:hamcrest-core:jar:1.3:test
[INFO] +- org.jmockit:jmockit:jar:1.33:test
[INFO] +- org.hsqldb:hsqldb:jar:2.4.0:test
[INFO] +- org.glassfish:javax.json:jar:1.0.4:test
[INFO] +- com.nimbusds:nimbus-jose-jwt:jar:4.39.2:test
[INFO] | +- com.github.stephenc.jcip:jcip-annotations:jar:1.0-1:test
[INFO] | \- net.minidev:json-smart:jar:2.3:test (version selected from constraint [1.3.1,2.3])
[INFO] | \- net.minidev:accessors-smart:jar:1.2:test
[INFO] | \- org.ow2.asm:asm:jar:5.0.4:test
[INFO] \- com.squareup.okhttp3:mockwebserver:jar:3.8.1:test
[INFO] +- com.squareup.okhttp3:okhttp:jar:3.8.1:test
[INFO] | \- com.squareup.okio:okio:jar:1.13.0:test
[INFO] \- org.bouncycastle:bcprov-jdk15on:jar:1.50:test
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 4.935 s
[INFO] Finished at: 2018-03-01T09:10:19-08:00
[INFO] Final Memory: 22M/187M
[INFO] ------------------------------------------------------------------------
{code}
To fix this, we need to exclude json-smart from nimbus-jose-jwt and add an explicit dependency on it.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-2423) Elytron resources runtime updates without reload
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2423?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-2423:
------------------------------------------
I just rejected WFCORE-1953. :)
> Elytron resources runtime updates without reload
> ------------------------------------------------
>
> Key: WFCORE-2423
> URL: https://issues.jboss.org/browse/WFCORE-2423
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.0.Beta7
> Reporter: Martin Choma
> Assignee: Dmitrii Tikhomirov
>
> When updating elytron resources, server ends up in {{reload-required}} state. For example
> {code}
> [standalone@localhost:9990 /] /subsystem=elytron/kerberos-security-factory=krbSF:write-attribute(name=debug, value=true)
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> {code}
> Make it possible for all (most - some may be impossible) resources to support runtime updates.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-1953) Elytron allow-resource-service-restart=true handling
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1953?page=com.atlassian.jira.plugi... ]
Brian Stansberry resolved WFCORE-1953.
--------------------------------------
Resolution: Won't Do
I'm rejecting this. See comments in https://issues.jboss.org/browse/JBEAP-10168.
I oppose supporting allow-resource-service-restart=true in the elytron subsystem. Restarting a service that is close to the root of the service dependency graph is going to have a practical effect little different from a reload.
I don't think we should expend energy adding support for it anywhere at all. It's a power user thing without enough practical benefit to justify the cost to implement and the fragility that results.
Also, in a cloud world, config changes are made as part of the image build and then the updated image is rolled out to the pods. Trying to make a reload go away means we are spending our energy on non-cloud use cases. (And even in bare metal uses cases people are often unwilling to live update a production server.)
Note that the UnsupportedOperationException has been fixed in a different issue.
> Elytron allow-resource-service-restart=true handling
> ----------------------------------------------------
>
> Key: WFCORE-1953
> URL: https://issues.jboss.org/browse/WFCORE-1953
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha11
> Reporter: Martin Choma
>
> Elytron can not handle {{allow-resource-service-restart=true}} header properly on many places.
> For example if I try to update http-authentication-factory with {{allow-resource-service-restart=true}} header, I get
> {code}
> [standalone@localhost:9990 /] /subsystem=elytron/http-authentication-factory=application-http-authentication:write-attribute(name=http-server-mechanism-factory, value=global){allow-resource-service-restart=true}
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.UnsupportedOperationException",
> "rolled-back" => true
> }
> {code}
> And exception in server log
> {code:title=server.log}
> 11:22:20,312 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("write-attribute") failed - address: ([
> ("subsystem" => "elytron"),
> ("http-authentication-factory" => "application-http-authentication")
> ]): java.lang.UnsupportedOperationException
> at org.jboss.as.controller.RestartParentWriteAttributeHandler.recreateParentService(RestartParentWriteAttributeHandler.java:145)
> at org.jboss.as.controller.RestartParentWriteAttributeHandler.recreateParentService(RestartParentWriteAttributeHandler.java:126)
> at org.jboss.as.controller.RestartParentWriteAttributeHandler.applyUpdateToRuntime(RestartParentWriteAttributeHandler.java:72)
> at org.jboss.as.controller.AbstractWriteAttributeHandler$1.execute(AbstractWriteAttributeHandler.java:104)
> 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}
> Similar behaviour can be seen in:
> * {{kerberos-security-factory}}
> * {{filesystem-realm}}
> * {{constant-principal-decoder}}
> On the other hand I don't see this issue in {{security-domain}}
> Possible solutions:
> * restart services
> ** possibility of reload big part of server anyway; either management part or application part
> * live updates
> ** if resource would accept runtime updates resource won't need to reload
> ** most user friendly, most work
> ** tracked as own issue JBEAP-6961
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months