[JBoss JIRA] (WFCORE-2886) remove-handler operation succeeds when removing non-existent handler
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2886?page=com.atlassian.jira.plugi... ]
James Perkins commented on WFCORE-2886:
---------------------------------------
Scratch that, I read it wrong. Sorry not the resource the handler itself does not exist. I guess not failing, the current behavior, makes the most sense really. Having it fail could potentially break scripts. I don't *think* a user could care if the handler didn't exist they're trying to remove. The end goal is to not have the handler in the list and that is accomplished if the handler doesn't exist.
> remove-handler operation succeeds when removing non-existent handler
> --------------------------------------------------------------------
>
> Key: WFCORE-2886
> URL: https://issues.jboss.org/browse/WFCORE-2886
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: Michal Petrov
> Assignee: Michal Petrov
>
> When trying to remove a handler that doesn't exist the operation should fail. E.g.
> {code}
> /subsystem=logging/root-logger=ROOT:remove-handler(name="ABC")
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFCORE-2886) remove-handler operation succeeds when removing non-existent handler
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2886?page=com.atlassian.jira.plugi... ]
James Perkins commented on WFCORE-2886:
---------------------------------------
Unless I'm missing something this already fails in WildFly Core:
{code}
[standalone@localhost:9990 /] /subsystem=logging/root-logger=ROOT:remove-handler(name=FILE)
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0216: Management resource '[
(\"subsystem\" => \"logging\"),
(\"root-logger\" => \"ROOT\")
]' not found",
"rolled-back" => true
}
{code}
> remove-handler operation succeeds when removing non-existent handler
> --------------------------------------------------------------------
>
> Key: WFCORE-2886
> URL: https://issues.jboss.org/browse/WFCORE-2886
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: Michal Petrov
> Assignee: Michal Petrov
>
> When trying to remove a handler that doesn't exist the operation should fail. E.g.
> {code}
> /subsystem=logging/root-logger=ROOT:remove-handler(name="ABC")
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (ELY-1151) Empty authorization name for Digest mechanism causes authentication fail
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1151?page=com.atlassian.jira.plugin.s... ]
Jan Kalina reopened ELY-1151:
-----------------------------
> Empty authorization name for Digest mechanism causes authentication fail
> ------------------------------------------------------------------------
>
> Key: ELY-1151
> URL: https://issues.jboss.org/browse/ELY-1151
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta38
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Blocker
> Fix For: 1.1.0.Beta44
>
>
> SASL specification says about Authorization Identity String [1]:
> {quote}
> If the authorization identity string is absent, the client is requesting to act as the identity the server associates with the client's credentials. *An empty string is equivalent to an absent authorization identity.*
> {quote}
> In case when authentication configuration includes empty name for authorization name then authentication fail. In correct behavior authentication name should be used if authorization name is empty string.
> It is caused by passing empty {{defaultName}} to {{NameCallback}} constructor which results to {{IllegalArgumentException}}. Condition in [2] checks only non-null value of {{authorizationId}} but it seems it should also check empty name.
> It can be reproduced with correctly set wildfly-config.xml (i.e. configuration where authentication succeed) - in case {{set-authorization-name}} element with empty string is added to this configuration file then authentication starts to fail.
> The same issue can occurs for every supported SASL mechanism. In needs to be revisited.
> We request blocker flag since current behavior violates SASL specification.
> [1] https://tools.ietf.org/html/rfc4422#section-3.4.1
> [2] https://github.com/wildfly-security/wildfly-elytron/blob/596f25e853c8fbae...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFCORE-2885) list-remove operation succeeds when removing non-existent item
by Michal Petrov (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2885?page=com.atlassian.jira.plugi... ]
Michal Petrov commented on WFCORE-2885:
---------------------------------------
As I said there are some remove-* operations that do fail (e.g. "remove-namespace") and some that don't. With WFCORE-2880 filed I wasn't sure what is the intended behavior of these.
> list-remove operation succeeds when removing non-existent item
> --------------------------------------------------------------
>
> Key: WFCORE-2885
> URL: https://issues.jboss.org/browse/WFCORE-2885
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Michal Petrov
> Assignee: Michal Petrov
>
> When removing an item from a list the operation should fail if the item doesn't exist. E.g.
> {code}
> /subsystem=logging/root-logger=ROOT:list-remove(name=handlers,value="ABC")
> {code}
> the operation already fails when using an invalid index.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFCORE-2626) Network interface selection criteria is not working for a duplicate IP addresses but one is down
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2626?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-2626:
-------------------------------------------------
Radovan STANCEL <rstancel(a)redhat.com> changed the Status of [bug 1442325|https://bugzilla.redhat.com/show_bug.cgi?id=1442325] from POST to MODIFIED
> Network interface selection criteria is not working for a duplicate IP addresses but one is down
> ------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2626
> URL: https://issues.jboss.org/browse/WFCORE-2626
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Environment: On Fedora 24 KVM instance, I added 2 extra NICs those are recognized as ens9 and ens10. Both have 192.168.1.1 but one is down.
> {code}
> # ip address show
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> valid_lft forever preferred_lft forever
> inet6 ::1/128 scope host
> valid_lft forever preferred_lft forever
> 2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
> link/ether 52:54:00:ca:86:e2 brd ff:ff:ff:ff:ff:ff
> inet 192.168.122.117/24 brd 192.168.122.255 scope global dynamic ens3
> valid_lft 3483sec preferred_lft 3483sec
> inet6 fe80::782d:5d87:243d:917f/64 scope link
> valid_lft forever preferred_lft forever
> 3: ens9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
> link/ether 52:54:00:ee:c6:16 brd ff:ff:ff:ff:ff:ff
> inet 192.168.1.1/24 scope global ens9
> valid_lft forever preferred_lft forever
> 4: ens10: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
> link/ether 52:54:00:52:78:ca brd ff:ff:ff:ff:ff:ff
> inet 192.168.1.1/24 scope global ens10
> valid_lft forever preferred_lft forever
> {code}
> Reporter: Osamu Nagano
> Assignee: Brian Stansberry
> Fix For: 3.0.0.Beta16
>
>
> In the standalone.xml, there are {{<up/>}} criterion which is sufficient to identify a unique NIC under the environment described above.
> {code}
> <interfaces>
> <interface name="management">
> <up/>
> <inet-address value="${jboss.bind.address.management:127.0.0.1}"/>
> </interface>
> <interface name="public">
> <up/>
> <inet-address value="${jboss.bind.address:127.0.0.1}"/>
> </interface>
> </interfaces>
> {code}
> But it says "ambiguous". WildFly 10.1.0.Final doesn't show this error.
> {code}
> # $JBOSS_HOME/bin/standalone.sh -b 192.168.1.1 -bmanagement=192.168.1.1
> ...
> 04:38:52,839 WARN [org.jboss.as.controller] (MSC service thread 1-3) WFLYCTL0023: Value '192.168.1.1' for interface selection criteria 'inet-address' is ambiguous, as more than one address or network interface available on the machine matches it. Because of this ambiguity,
> no address will be selected as a match. Matching addresses: [/192.168.1.1]. Matching network interfaces: [ens9, ens10].
> 04:38:52,840 WARN [org.jboss.as.controller] (MSC service thread 1-4) WFLYCTL0023: Value '192.168.1.1' for interface selection criteria 'inet-address' is ambiguous, as more than one address or network interface available on the machine matches it. Because of this ambiguity,
> no address will be selected as a match. Matching addresses: [/192.168.1.1]. Matching network interfaces: [ens9, ens10].
> 04:38:52,840 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.network.public: org.jboss.msc.service.StartException in service jboss.network.public: WFLYSRV0082: failed to resolve interface public
> at org.jboss.as.server.services.net.NetworkInterfaceService.start(NetworkInterfaceService.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)
> 04:38:52,841 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.network.management: org.jboss.msc.service.StartException in service jboss.network.management: WFLYSRV0082: failed to resolve interface management
> at org.jboss.as.server.services.net.NetworkInterfaceService.start(NetworkInterfaceService.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)
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFLY-8458) NPE when MBean does not have no-arg constructor
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-8458?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-8458:
-----------------------------------------------
Radovan STANCEL <rstancel(a)redhat.com> changed the Status of [bug 1436390|https://bugzilla.redhat.com/show_bug.cgi?id=1436390] from POST to MODIFIED
> NPE when MBean does not have no-arg constructor
> -----------------------------------------------
>
> Key: WFLY-8458
> URL: https://issues.jboss.org/browse/WFLY-8458
> Project: WildFly
> Issue Type: Bug
> Components: JMX, Server
> Affects Versions: 11.0.0.Alpha1
> Reporter: Chao Wang
> Assignee: Chao Wang
> Fix For: 11.0.0.Beta1
>
>
> NPE when MBean does not have no-arg constructor, it should log an error message indicating the issue rather than NPE
> {code}
> 15:05:48,605 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."jboss-helloworld-dynamicmbean-helloworld-mbean-service.sar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."jboss-helloworld-dynamicmbean-helloworld-mbean-service.sar".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment "jboss-helloworld-dynamicmbean-helloworld-mbean-service.sar"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:172)
> 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.lang.IllegalArgumentException: WFLYSAR0004: Class not instantiated
> at org.jboss.as.service.ReflectionUtils.newInstance(ReflectionUtils.java:133)
> at org.jboss.as.service.ParsedServiceDeploymentProcessor.newInstance(ParsedServiceDeploymentProcessor.java:283)
> at org.jboss.as.service.ParsedServiceDeploymentProcessor.addServices(ParsedServiceDeploymentProcessor.java:129)
> at org.jboss.as.service.ParsedServiceDeploymentProcessor.deploy(ParsedServiceDeploymentProcessor.java:118)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:165)
> ... 5 more
> Caused by: java.lang.NullPointerException
> at org.jboss.as.service.ReflectionUtils.newInstance(ReflectionUtils.java:131)
> ... 9 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFCORE-2886) remove-handler operation succeeds when removing non-existent handler
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2886?page=com.atlassian.jira.plugi... ]
Brian Stansberry edited comment on WFCORE-2886 at 5/30/17 11:00 AM:
--------------------------------------------------------------------
This probably shouldn't fail either (i.e. same thinking as WFCORE-2885); if it does it is a likely regression. Please get an opinion from [~jamezp].
was (Author: brian.stansberry):
This probably shouldn't fail either; if it does it is a likely regression. Please get an opinion from [~jamezp].
> remove-handler operation succeeds when removing non-existent handler
> --------------------------------------------------------------------
>
> Key: WFCORE-2886
> URL: https://issues.jboss.org/browse/WFCORE-2886
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: Michal Petrov
> Assignee: Michal Petrov
>
> When trying to remove a handler that doesn't exist the operation should fail. E.g.
> {code}
> /subsystem=logging/root-logger=ROOT:remove-handler(name="ABC")
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFLY-8860) Add optional module dependency for org.springframework.spring to org.apache.cxf.impl
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-8860?page=com.atlassian.jira.plugin.... ]
Brian Stansberry reassigned WFLY-8860:
--------------------------------------
Component/s: Web Services
Assignee: Alessio Soldano (was: Jason Greene)
> Add optional module dependency for org.springframework.spring to org.apache.cxf.impl
> ------------------------------------------------------------------------------------
>
> Key: WFLY-8860
> URL: https://issues.jboss.org/browse/WFLY-8860
> Project: WildFly
> Issue Type: Enhancement
> Components: Web Services
> Reporter: James Netherton
> Assignee: Alessio Soldano
>
> Similar to WFLY-5532, for our [Camel integration|https://github.com/wildfly-extras/wildfly-camel] the camel-cxf component calls into cxf for Spring namespace handlers. Module {{org.apache.cxf.impl}} exposes a number of resources which have their own Spring namespace handlers. When accessing them (E.g {{org/apache/cxf/transport/http/spring/NamespaceHandler}}), I get:
> {code}
> Caused by: java.lang.NoClassDefFoundError: Failed to link org/apache/cxf/transport/http/spring/NamespaceHandler (Module "org.apache.cxf.impl:main" from local module loader @4c75cab9 (finder: local module finder @1ef7fe8e (roots: /home/james/Projects/git/fork/wildfly-camel/itests/standalone/basic/target/wildfly-10.1.0.Final/modules,/home/james/Projects/git/fork/wildfly-camel/itests/standalone/basic/target/wildfly-10.1.0.Final/modules/system/layers/fuse,/home/james/Projects/git/fork/wildfly-camel/itests/standalone/basic/target/wildfly-10.1.0.Final/modules/system/layers/base))): org/springframework/beans/factory/xml/NamespaceHandlerSupport
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:446)
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:274)
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:78)
> at org.jboss.modules.Module.loadModuleClass(Module.java:606)
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93)
> at org.springframework.util.ClassUtils.forName(ClassUtils.java:250)
> at org.springframework.beans.factory.xml.DefaultNamespaceHandlerResolver.resolve(DefaultNamespaceHandlerResolver.java:125)
> ... 19 more
> {code}
> Please can we add an optional dependency for {{org.springframework.spring}} to {{org.apache.cxf.impl}}.
> Cross ref here: https://github.com/wildfly-extras/wildfly-camel/issues/1897
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months