[JBoss JIRA] (WFLY-2696) management audit settings: syslog protocol is lowercase while uppercase is expected
by Kyle Lape (JIRA)
[ https://issues.jboss.org/browse/WFLY-2696?page=com.atlassian.jira.plugin.... ]
Kyle Lape updated WFLY-2696:
----------------------------
Steps to Reproduce:
clean install using domain mode.
batch
{noformat}
/host=master/core-service=management/access=audit/syslog-handler=mysyslog:add(formatter=json-formatter)
/host=master/core-service=management/access=audit/syslog-handler=mysyslog/protocol=udp:add(host=localhost,port=514)
{noformat}
run-batch
{noformat}
/host=master/core-service=management/access=audit/logger=audit-log/handler=mysyslog:add()
{noformat}
and subsequently try to start an instance. This generates:
{noformat}
17:30:25,066 ERROR [org.jboss.as.controller.management-operation] (server-registration-threads - 1) JBAS014612: Operation ("register-server") failed - address: ([]): java.lang.IllegalArgumentException: No enum const class org.jboss.as.controller.audit.SyslogAuditLogHandler$Transport.udp
at java.lang.Enum.valueOf(Enum.java:214) [rt.jar:1.6.0_24]
at org.jboss.as.controller.audit.SyslogAuditLogHandler$Transport.valueOf(SyslogAuditLogHandler.java:315) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
at org.jboss.as.domain.management.audit.SyslogAuditLogProtocolResourceDefinition.createProtocolAddOperation(SyslogAuditLogProtocolResourceDefinition.java:128) [jboss-as-domain-management-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
at org.jboss.as.domain.management.audit.SyslogAuditLogProtocolResourceDefinition.createServerAddOperations(SyslogAuditLogProtocolResourceDefinition.java:107) [jboss-as-domain-management-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
at org.jboss.as.domain.management.audit.SyslogAuditLogHandlerResourceDefinition.createServerAddOperations(SyslogAuditLogHandlerResourceDefinition.java:105) [jboss-as-domain-management-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
at org.jboss.as.host.controller.ManagedServerOperationsFactory.addAuditLog(ManagedServerOperationsFactory.java:444)
at org.jboss.as.host.controller.ManagedServerOperationsFactory.getBootUpdates(ManagedServerOperationsFactory.java:227)
at org.jboss.as.host.controller.ManagedServerOperationsFactory.createBootUpdates(ManagedServerOperationsFactory.java:153)
at org.jboss.as.host.controller.mgmt.ServerToHostProtocolHandler$ServerRegistrationStepHandler.execute(ServerToHostProtocolHandler.java:219)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:607) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:485) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:282) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:277) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
at org.jboss.as.controller.ModelControllerImpl.executeReadOnlyOperation(ModelControllerImpl.java:164) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
at org.jboss.as.controller.AbstractControllerService.executeReadOnlyOperation(AbstractControllerService.java:303) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
at org.jboss.as.host.controller.DomainModelControllerService.access$700(DomainModelControllerService.java:140)
at org.jboss.as.host.controller.DomainModelControllerService$3.joinActiveOperation(DomainModelControllerService.java:515)
at org.jboss.as.host.controller.mgmt.ServerToHostProtocolHandler$ServerRegistrationRequestHandler$1.execute(ServerToHostProtocolHandler.java:180)
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [jboss-as-protocol-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [jboss-as-protocol-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) [rt.jar:1.6.0_24]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.6.0_24]
at java.lang.Thread.run(Thread.java:679) [rt.jar:1.6.0_24]
at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final-redhat-1.jar:2.1.1.Final-redhat-1]
{noformat}
The issue is simple:
{code:java}
package org.jboss.as.domain.management.audit;
public abstract class SyslogAuditLogProtocolResourceDefinition extends SimpleResourceDefinition {
...
public static ModelNode createProtocolAddOperation(final PathAddress protocolAddress, final ModelNode protocol){
ModelNode protocolAdd = Util.createAddOperation(protocolAddress);
protocolAdd.get(HOST.getName()).set(protocol.get(HOST.getName()));
protocolAdd.get(PORT.getName()).set(protocol.get(PORT.getName()));
SyslogAuditLogHandler.Transport transport = SyslogAuditLogHandler.Transport.valueOf(protocolAddress.getLastElement().getValue());
{code}
with:
{noformat}
protocolAddress = (org.jboss.as.controller.PathAddress) [
("core-service" => "management"),
("access" => "audit"),
("syslog-handler" => "mysyslog"),
("protocol" => "udp")
]
{noformat}
so "udp" is used... but the enum:
{code:java}
public enum Transport {
UDP,
TCP,
TLS
}
{code:java}
has an uppercase UDP.
The same issue happens in
{code:java}
public static void createServerAddOperations(final List<ModelNode> addOps, final PathAddress protocolAddress, final ModelNode protocol) {
addOps.add(createProtocolAddOperation(protocolAddress, protocol));
final SyslogAuditLogHandler.Transport transport = SyslogAuditLogHandler.Transport.valueOf(protocolAddress.getLastElement().getValue());
{code}
Solution: make uppercase:
{code:java}
SyslogAuditLogHandler.Transport.valueOf(protocolAddress.getLastElement().getValue().toUpperCase());
{code}
was:
clean install using domain mode.
batch
/host=master/core-service=management/access=audit/syslog-handler=mysyslog:add(formatter=json-formatter)
/host=master/core-service=management/access=audit/syslog-handler=mysyslog/protocol=udp:add(host=localhost,port=514)
run-batch
/host=master/core-service=management/access=audit/logger=audit-log/handler=mysyslog:add()
and subsequently try to start an instance. This generates:
17:30:25,066 ERROR [org.jboss.as.controller.management-operation] (server-registration-threads - 1) JBAS014612: Operation ("register-server") failed - address: ([]): java.lang.IllegalArgumentException: No enum const class org.jboss.as.controller.audit.SyslogAuditLogHandler$Transport.udp
at java.lang.Enum.valueOf(Enum.java:214) [rt.jar:1.6.0_24]
at org.jboss.as.controller.audit.SyslogAuditLogHandler$Transport.valueOf(SyslogAuditLogHandler.java:315) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
at org.jboss.as.domain.management.audit.SyslogAuditLogProtocolResourceDefinition.createProtocolAddOperation(SyslogAuditLogProtocolResourceDefinition.java:128) [jboss-as-domain-management-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
at org.jboss.as.domain.management.audit.SyslogAuditLogProtocolResourceDefinition.createServerAddOperations(SyslogAuditLogProtocolResourceDefinition.java:107) [jboss-as-domain-management-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
at org.jboss.as.domain.management.audit.SyslogAuditLogHandlerResourceDefinition.createServerAddOperations(SyslogAuditLogHandlerResourceDefinition.java:105) [jboss-as-domain-management-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
at org.jboss.as.host.controller.ManagedServerOperationsFactory.addAuditLog(ManagedServerOperationsFactory.java:444)
at org.jboss.as.host.controller.ManagedServerOperationsFactory.getBootUpdates(ManagedServerOperationsFactory.java:227)
at org.jboss.as.host.controller.ManagedServerOperationsFactory.createBootUpdates(ManagedServerOperationsFactory.java:153)
at org.jboss.as.host.controller.mgmt.ServerToHostProtocolHandler$ServerRegistrationStepHandler.execute(ServerToHostProtocolHandler.java:219)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:607) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:485) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:282) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:277) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
at org.jboss.as.controller.ModelControllerImpl.executeReadOnlyOperation(ModelControllerImpl.java:164) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
at org.jboss.as.controller.AbstractControllerService.executeReadOnlyOperation(AbstractControllerService.java:303) [jboss-as-controller-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
at org.jboss.as.host.controller.DomainModelControllerService.access$700(DomainModelControllerService.java:140)
at org.jboss.as.host.controller.DomainModelControllerService$3.joinActiveOperation(DomainModelControllerService.java:515)
at org.jboss.as.host.controller.mgmt.ServerToHostProtocolHandler$ServerRegistrationRequestHandler$1.execute(ServerToHostProtocolHandler.java:180)
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [jboss-as-protocol-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [jboss-as-protocol-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) [rt.jar:1.6.0_24]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.6.0_24]
at java.lang.Thread.run(Thread.java:679) [rt.jar:1.6.0_24]
at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final-redhat-1.jar:2.1.1.Final-redhat-1]
The issue is simple:
package org.jboss.as.domain.management.audit;
public abstract class SyslogAuditLogProtocolResourceDefinition extends SimpleResourceDefinition {
...
public static ModelNode createProtocolAddOperation(final PathAddress protocolAddress, final ModelNode protocol){
ModelNode protocolAdd = Util.createAddOperation(protocolAddress);
protocolAdd.get(HOST.getName()).set(protocol.get(HOST.getName()));
protocolAdd.get(PORT.getName()).set(protocol.get(PORT.getName()));
SyslogAuditLogHandler.Transport transport = SyslogAuditLogHandler.Transport.valueOf(protocolAddress.getLastElement().getValue());
with:
protocolAddress = (org.jboss.as.controller.PathAddress) [
("core-service" => "management"),
("access" => "audit"),
("syslog-handler" => "mysyslog"),
("protocol" => "udp")
]
so "udp" is used... but the enum:
public enum Transport {
UDP,
TCP,
TLS
}
has an uppercase UDP.
The same issue happens in
public static void createServerAddOperations(final List<ModelNode> addOps, final PathAddress protocolAddress, final ModelNode protocol) {
addOps.add(createProtocolAddOperation(protocolAddress, protocol));
final SyslogAuditLogHandler.Transport transport = SyslogAuditLogHandler.Transport.valueOf(protocolAddress.getLastElement().getValue());
Solution: make uppercase:
SyslogAuditLogHandler.Transport.valueOf(protocolAddress.getLastElement().getValue().toUpperCase());
> management audit settings: syslog protocol is lowercase while uppercase is expected
> -----------------------------------------------------------------------------------
>
> Key: WFLY-2696
> URL: https://issues.jboss.org/browse/WFLY-2696
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.CR1
> Environment: - 8.0.0 CR1 + latest code in master
> - domain mode
> Reporter: Tom Fonteyne
> Assignee: Tom Fonteyne
>
> Add a syslog handler to the audit settings of the management service of the domain controller, then start an instance. It fails to start with:
> JBAS014612: Operation ("register-server") failed - address: ([]): java.lang.IllegalArgumentException: No enum const class org.jboss.as.controller.audit.SyslogAuditLogHandler$Transport.udp
> at java.lang.Enum.valueOf(Enum.java:214)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (JGRP-1732) UNICAST/NAKACK: threads from the internal thread pool should not do work stealing
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1732?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1732.
----------------------------
Resolution: Done
> UNICAST/NAKACK: threads from the internal thread pool should not do work stealing
> ---------------------------------------------------------------------------------
>
> Key: JGRP-1732
> URL: https://issues.jboss.org/browse/JGRP-1732
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> In NAKACK\{2\} and UNICAST\{2,3\}, threads from all thread pools (regular, OOB and internal) add messages to the table, then grab as many (ordered) messages as possible from the table and pass them up.
> This could lead to the case where an internal thread passes up regular or OOB messages, which might block. There's a (small) chance that this exhausts the internal thread pool.
> Internal threads should therefore never block, and never steal work from other thread pools.
> SOLUTION:
> * An internal thread only adds the message to the table and passes it up if in order
> * If the internal message is OOB, it is passed up and then the thread returns
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (JGRP-1767) UNICAST3: processing of OOB messages and message batches
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1767?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1767.
----------------------------
Resolution: Done
> UNICAST3: processing of OOB messages and message batches
> --------------------------------------------------------
>
> Key: JGRP-1767
> URL: https://issues.jboss.org/browse/JGRP-1767
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> Currently, when OOB message batches are received, the following happens:
> * All messages from the batch are added to the table
> * We iterate through the batch and remove those message whose {{OOB_DELIVERED}} flag cannot be set (already processed and delivered by a different thread).
> * The batch is passed up
> * Then we try to remove as many messages from the table as possible and pass them up (as a batch again)
> ** Messages whose {{OOB_DELIVERED}} flag is set, are discarded
> This is a lot of work and we're accessing the table more than needed for OOB batches. A few things can be changed to make this more efficient:
> * The thread which processes a message ot message batch will deliver the message to the application if the message or batch hasn't been delivered yet
> ** Batch
> *** we only add those messages from list L to table T if they haven't yet been added
> *** Messages from L which couldn't be added to T are removed from L
> *** All messages from L are added to a new batch and that batch is then passed up (delivered)
> ** Single message
> *** If the message was added successfuly, we deliver it, else we drop it
> * When removing messages from the table ({{Table.removeMany()}}), we skip OOB messages. This is done with a new Table.add() method (including a filter)
> * Further optimization: when adding an OOB message to T, we add a reference to a static OOB message, so *all OOB messages in a table point to the same instance !* Since we skip OOB messages when removing messages, this doesn't matter. However, this reduces the memory needed by Table if there are many OOB messages
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (JGRP-1769) Table.add() with message list can lead to many resizings
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1769?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1769.
----------------------------
Resolution: Done
> Table.add() with message list can lead to many resizings
> --------------------------------------------------------
>
> Key: JGRP-1769
> URL: https://issues.jboss.org/browse/JGRP-1769
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.5
>
>
> Table maintains an array of arrays (a matrix) and needs to resize it when adding messages that would go beyond the capacity of the array.
> This is done when adding a message.
> However, when adding a *list of messages*, as we're adding messages individually, we compute the needed capacity and perform a resize if needed.
> This leads to possibly too much copying.
> SOLUTION:
> * When adding a list of messages, do the resizing (if needed) *before* adding messages individually
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (JGRP-1770) Table: null row when removing last element
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1770?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1770.
----------------------------
Resolution: Done
> Table: null row when removing last element
> ------------------------------------------
>
> Key: JGRP-1770
> URL: https://issues.jboss.org/browse/JGRP-1770
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> In Table.removeMany() when nulling the last column of a row, we don't null the entire row. The effect is that we have rows (arrays) with all columns being empty remain in memory, which wastes memory.
> Note that Table.purge() actually does null entire rows, this is called by
> * NAKACK2: here, method stable() triggered by STABLE calls {{Table.purge(seqno)}}, so we're nulling entire rows. This is not a problem.
> * UNICAST3 *sender entries*: here, reception of an ACK(seqno) also calls {{Table.purge(seqno)}}, so this is not an issue, either
> The only issue is UNICAST3 *receiver entries*: here, {{Table.purge()}} is never called; elements are only nulled, but not entire rows.
> SOLUTION:
> When {{Table.removeMany()}} nulls an element, if that element is tha last element of a row (index = {{elements_per_row -1}}, then null the entire row.
> EFFECT:
> There's less memory held in memory by UNICAST3 receiver entries
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (WFLY-2738) Deprecated resource is present in r-r-d of /subsystem=security/security-domain=*
by Harald Pehl (JIRA)
[ https://issues.jboss.org/browse/WFLY-2738?page=com.atlassian.jira.plugin.... ]
Harald Pehl updated WFLY-2738:
------------------------------
Description:
When executing
{code}
/subsystem=security/security-domain=*:read-resource-description(recursive-depth=2)
{code}
the acl subresource contains both the deprecated child-resource {{login-module}} and the new one called {{acl-module}}:
{code}
...
"acl" => {
"description" => "Access control list configuration. Configures a list of ACL modules to be used.",
"model-description" => {"classic" => {
"description" => "Access control list configuration. Configures a list of ACL modules to be used.",
...
"operations" => undefined,
"children" => {
"acl-module" => {
"description" => "ACL module",
"model-description" => {"*" => {
"description" => "List of authentication modules",
...
"operations" => undefined,
"children" => {}
}}
},
"login-module" => {
"description" => "Login module",
"model-description" => {"*" => undefined}
}
}
}}
},
...
{code}
However the deprecated subresource {{login-modules}} should only appear if setting {{include-aliases=true}}
was:
When executing
{code}
/subsystem=security/security-domain=*:read-resource-description(recursive-depth=2)
{code}
the acl subresource contains both the deprecated child-resource {{login-module}} and the new one called {{acl-module}}:
{code}
...
"acl" => {
"description" => "Access control list configuration. Configures a list of ACL modules to be used.",
"model-description" => {"classic" => {
"description" => "Access control list configuration. Configures a list of ACL modules to be used.",
...
"operations" => undefined,
"children" => {
"acl-module" => {
"description" => "ACL module",
"model-description" => {"*" => {
"description" => "List of authentication modules",
"operations" => undefined,
"children" => {}
}}
},
"login-module" => {
"description" => "Login module",
"model-description" => {"*" => undefined}
}
}
}}
},
...
{code}
However the deprecated subresource {{login-modules}} should only appear if setting {{include-aliases=true}}
> Deprecated resource is present in r-r-d of /subsystem=security/security-domain=*
> --------------------------------------------------------------------------------
>
> Key: WFLY-2738
> URL: https://issues.jboss.org/browse/WFLY-2738
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 8.0.0.CR1
> Reporter: Harald Pehl
> Assignee: Kabir Khan
> Priority: Minor
>
> When executing
> {code}
> /subsystem=security/security-domain=*:read-resource-description(recursive-depth=2)
> {code}
> the acl subresource contains both the deprecated child-resource {{login-module}} and the new one called {{acl-module}}:
> {code}
> ...
> "acl" => {
> "description" => "Access control list configuration. Configures a list of ACL modules to be used.",
> "model-description" => {"classic" => {
> "description" => "Access control list configuration. Configures a list of ACL modules to be used.",
> ...
> "operations" => undefined,
> "children" => {
> "acl-module" => {
> "description" => "ACL module",
> "model-description" => {"*" => {
> "description" => "List of authentication modules",
> ...
> "operations" => undefined,
> "children" => {}
> }}
> },
> "login-module" => {
> "description" => "Login module",
> "model-description" => {"*" => undefined}
> }
> }
> }}
> },
> ...
> {code}
> However the deprecated subresource {{login-modules}} should only appear if setting {{include-aliases=true}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (WFLY-2738) Deprecated resource is present in r-r-d of /subsystem=security/security-domain=*
by Harald Pehl (JIRA)
Harald Pehl created WFLY-2738:
---------------------------------
Summary: Deprecated resource is present in r-r-d of /subsystem=security/security-domain=*
Key: WFLY-2738
URL: https://issues.jboss.org/browse/WFLY-2738
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 8.0.0.CR1
Reporter: Harald Pehl
Assignee: Kabir Khan
Priority: Minor
When executing
{code}
/subsystem=security/security-domain=*:read-resource-description(recursive-depth=2)
{code}
the acl subresource contains both the deprecated child-resource {{login-module}} and the new one called {{acl-module}}:
{code}
...
"acl" => {
"description" => "Access control list configuration. Configures a list of ACL modules to be used.",
"model-description" => {"classic" => {
"description" => "Access control list configuration. Configures a list of ACL modules to be used.",
...
"operations" => undefined,
"children" => {
"acl-module" => {
"description" => "ACL module",
"model-description" => {"*" => {
"description" => "List of authentication modules",
"operations" => undefined,
"children" => {}
}}
},
"login-module" => {
"description" => "Login module",
"model-description" => {"*" => undefined}
}
}
}}
},
...
{code}
However the deprecated subresource {{login-modules}} should only appear if setting {{include-aliases=true}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (WFLY-2737) Application that deploys in 8.0.0.BETA does not deploy in 8.0.0.CR1
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2737?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar reassigned WFLY-2737:
---------------------------------
Assignee: Jozef Hartinger (was: Stuart Douglas)
> Application that deploys in 8.0.0.BETA does not deploy in 8.0.0.CR1
> -------------------------------------------------------------------
>
> Key: WFLY-2737
> URL: https://issues.jboss.org/browse/WFLY-2737
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: REST
> Affects Versions: 8.0.0.CR1
> Reporter: Stan Zelivinski
> Assignee: Jozef Hartinger
>
> We are building RESTFul applications using RESTEasy framework. All our applications deploy fine in Wildfly Beta 8.0.0.Beta. When we are trying to deploy the exact same applications in 8.0.0.CR1 we are getting the following exception:
> 16:27:44,276 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."TestControllerWebApp.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."TestControllerWebApp.war".WeldStartService: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000075: Normal scoped managed bean implementation class has a public field: [EnhancedAnnotatedFieldImpl] public org.jboss.resteasy.core.AcceptHeaderByFileSuffixFilter.languageMappings
> at org.jboss.weld.bean.ManagedBean.checkBeanImplementation(ManagedBean.java:218)
> at org.jboss.weld.bean.AbstractClassBean.internalInitialize(AbstractClassBean.java:74)
> at org.jboss.weld.bean.ManagedBean.internalInitialize(ManagedBean.java:96)
> at org.jboss.weld.bean.RIBean.initialize(RIBean.java:65)
> at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$5.doWork(ConcurrentBeanDeployer.java:114)
> at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$5.doWork(ConcurrentBeanDeployer.java:112)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25]
> at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25]
> ... 3 more
> We are not able to identify the cause for this. Please help.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (WFLY-2737) Application that deploys in 8.0.0.BETA does not deploy in 8.0.0.CR1
by Stan Zelivinski (JIRA)
Stan Zelivinski created WFLY-2737:
-------------------------------------
Summary: Application that deploys in 8.0.0.BETA does not deploy in 8.0.0.CR1
Key: WFLY-2737
URL: https://issues.jboss.org/browse/WFLY-2737
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: REST
Affects Versions: 8.0.0.CR1
Reporter: Stan Zelivinski
Assignee: Stuart Douglas
We are building RESTFul applications using RESTEasy framework. All our applications deploy fine in Wildfly Beta 8.0.0.Beta. When we are trying to deploy the exact same applications in 8.0.0.CR1 we are getting the following exception:
16:27:44,276 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."TestControllerWebApp.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."TestControllerWebApp.war".WeldStartService: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000075: Normal scoped managed bean implementation class has a public field: [EnhancedAnnotatedFieldImpl] public org.jboss.resteasy.core.AcceptHeaderByFileSuffixFilter.languageMappings
at org.jboss.weld.bean.ManagedBean.checkBeanImplementation(ManagedBean.java:218)
at org.jboss.weld.bean.AbstractClassBean.internalInitialize(AbstractClassBean.java:74)
at org.jboss.weld.bean.ManagedBean.internalInitialize(ManagedBean.java:96)
at org.jboss.weld.bean.RIBean.initialize(RIBean.java:65)
at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$5.doWork(ConcurrentBeanDeployer.java:114)
at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$5.doWork(ConcurrentBeanDeployer.java:112)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25]
at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25]
... 3 more
We are not able to identify the cause for this. Please help.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months