[JBoss JIRA] (WFCORE-862) MBeanServer returns MBean names that do not match filter
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-862?page=com.atlassian.jira.plugin... ]
James Perkins updated WFCORE-862:
---------------------------------
Fix Version/s: 2.0.0.CR1
(was: 2.0.0.Beta5)
> MBeanServer returns MBean names that do not match filter
> --------------------------------------------------------
>
> Key: WFCORE-862
> URL: https://issues.jboss.org/browse/WFCORE-862
> Project: WildFly Core
> Issue Type: Bug
> Components: JMX
> Affects Versions: 2.0.0.Alpha12
> Reporter: Thomas Diesler
> Assignee: Kabir Khan
> Fix For: 2.0.0.CR1
>
>
> This code
> {code}
> MBeanServer server = ManagementFactory.getPlatformMBeanServer();
> for (ObjectName oname : server.queryNames(new ObjectName("*:type=context,*"), null)) {
> System.out.println(oname);
> }
> {code}
> gives
> {code}
> 16:51:25,842 INFO [stdout] (pool-3-thread-1) org.apache.camel:context=swagger-test,type=context,name="swagger-test"
> 16:51:25,842 INFO [stdout] (pool-3-thread-1) jboss.jsr77:j2eeType=J2EEServer,name=default
> 16:51:25,843 INFO [stdout] (pool-3-thread-1) jboss.jsr77:j2eeType=JVM,name=default,J2EEServer=default
> 16:51:25,843 INFO [stdout] (pool-3-thread-1) jboss.jsr77:j2eeType=J2EEDomain,name=jboss.jsr77
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 8 months
[JBoss JIRA] (WFCORE-842) Rename CapabilityContext to CapabilityScope
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-842?page=com.atlassian.jira.plugin... ]
James Perkins updated WFCORE-842:
---------------------------------
Fix Version/s: 2.0.0.CR1
(was: 2.0.0.Beta5)
> Rename CapabilityContext to CapabilityScope
> -------------------------------------------
>
> Key: WFCORE-842
> URL: https://issues.jboss.org/browse/WFCORE-842
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 2.0.0.CR1
>
>
> I used the interface name "CapabilityContext" for the thing that defines the scope in which a capability is registered. Bad name, particularly now that the WFCORE-834 work has introduced a "CapabilityResolutionContext" object for storing temp data used during capability resolution. The 834 thing is much more of a context.
> So let's rename it to CapabilityScope.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 8 months
[JBoss JIRA] (WFCORE-840) Improve API on AttributeDefinitions where a capability is referenced.
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-840?page=com.atlassian.jira.plugin... ]
James Perkins updated WFCORE-840:
---------------------------------
Fix Version/s: 2.0.0.CR1
(was: 2.0.0.Beta5)
> Improve API on AttributeDefinitions where a capability is referenced.
> ---------------------------------------------------------------------
>
> Key: WFCORE-840
> URL: https://issues.jboss.org/browse/WFCORE-840
> Project: WildFly Core
> Issue Type: Sub-task
> Components: Domain Management
> Affects Versions: 2.0.0.Alpha11
> Reporter: Darran Lofthouse
> Assignee: Tomaz Cerar
> Fix For: 2.0.0.CR1
>
>
> Take the following method call defining an attribute: -
> {code}
> .setCapabilityReference(PROVIDERS_CAPABILITY, SASL_SERVER_FACTORY_CAPABILITY, true)
> {code}
> This definition says this attribute references something which provides the PROVIDERS_CAPABILITY.
> However it also states that the resource that contains this attributes provides the SASL_SERVER_FACTORY_CAPABILITY.
> Really what the resource provides is not directly related to this attribute definition.
> The following pull request has already improved on registering in advance what capability a resource can provide: -
> https://github.com/wildfly/wildfly-core/pull/909
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 8 months
[JBoss JIRA] (WFCORE-841) Patching module testsuite failure
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-841?page=com.atlassian.jira.plugin... ]
James Perkins updated WFCORE-841:
---------------------------------
Fix Version/s: 2.0.0.CR1
(was: 2.0.0.Beta5)
> Patching module testsuite failure
> ---------------------------------
>
> Key: WFCORE-841
> URL: https://issues.jboss.org/browse/WFCORE-841
> Project: WildFly Core
> Issue Type: Bug
> Components: Patching
> Environment: $ java -version
> java version "1.8.0_45"
> Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
> Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)
> OS X Yosemite 10.10.4
> Reporter: Brian Stansberry
> Assignee: Alexey Loubyansky
> Fix For: 2.0.0.CR1
>
>
> When running the core build locally , the 'patching' module testsuite fails:
> {code}
> -------------------------------------------------------
> T E S T S
> -------------------------------------------------------
> objc[58076]: Class JavaLaunchHelper is implemented in both /Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/jre/bin/java and /Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/jre/lib/libinstrument.dylib. One of the two will be used. Which one is undefined.
> Running org.jboss.as.patching.cli.ContentConflictsUnitTestCase
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.892 sec - in org.jboss.as.patching.cli.ContentConflictsUnitTestCase
> Running org.jboss.as.patching.cli.LocalPatchInfoPatchIdUnitTestCase
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.269 sec - in org.jboss.as.patching.cli.LocalPatchInfoPatchIdUnitTestCase
> Running org.jboss.as.patching.cli.PatchInspectUnitTestCase
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.044 sec <<< FAILURE! - in org.jboss.as.patching.cli.PatchInspectUnitTestCase
> testMain(org.jboss.as.patching.cli.PatchInspectUnitTestCase) Time elapsed: 0.044 sec <<< FAILURE!
> java.lang.AssertionError: expected:<{Type=one-off, Description=this is one-off patch 1, Identity name=product, Identity version=version, Patch ID=e7221af6-a05f-49f9-bf24-e40501b54db6, Link=http://test.one}> but was:<{}>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:144)
> at org.jboss.as.patching.cli.CLIPatchInfoUtil.assertPatchInfo(CLIPatchInfoUtil.java:76)
> at org.jboss.as.patching.cli.CLIPatchInfoUtil.assertPatchInfo(CLIPatchInfoUtil.java:57)
> at org.jboss.as.patching.cli.PatchInspectUnitTestCase.testMain(PatchInspectUnitTestCase.java:180)
> {code}
> If I clean and run the test by itself, it passes. It also passes on the CI jobs on brontes, but the log shows the tests excecute in a different order.
> Given all that, my expectation is that one of the two tests that run locally before the failing one is leaving some sort of mess behind. I've found that @Ignoring org.jboss.as.patching.cli.LocalPatchInfoPatchIdUnitTestCase solves the problem, so I will send up a PR that does that as a workaround.
> The problem does not occur with 2.0.0.Alpha11, and there are only two commits in master since then. One is an undertow upgrade, so it's almost certain the problem was introduced with the other: https://github.com/wildfly/wildfly-core/pull/904
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 8 months
[JBoss JIRA] (WFCORE-826) List-* operations should accept also objects as value
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-826?page=com.atlassian.jira.plugin... ]
James Perkins updated WFCORE-826:
---------------------------------
Fix Version/s: 2.0.0.CR1
(was: 2.0.0.Beta5)
> List-* operations should accept also objects as value
> -----------------------------------------------------
>
> Key: WFCORE-826
> URL: https://issues.jboss.org/browse/WFCORE-826
> Project: WildFly Core
> Issue Type: Sub-task
> Components: Domain Management
> Reporter: Tomaz Cerar
> Assignee: Tomaz Cerar
> Fix For: 2.0.0.CR1
>
>
> in case where list contains objects and not just simple types
> list operations complain:
> example:
> {noformat}
> [standalone@localhost:9990 /] /subsystem=messaging-activemq/server=default:list-add(name=incoming-interceptors, value={name=foo,module=bar})
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0097: Wrong type for value. Expected [STRING] but was OBJECT",
> "rolled-back" => true
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 8 months
[JBoss JIRA] (WFCORE-785) Improve capability related error messages
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-785?page=com.atlassian.jira.plugin... ]
James Perkins updated WFCORE-785:
---------------------------------
Fix Version/s: 2.0.0.CR1
(was: 2.0.0.Beta5)
> Improve capability related error messages
> -----------------------------------------
>
> Key: WFCORE-785
> URL: https://issues.jboss.org/browse/WFCORE-785
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Fix For: 2.0.0.CR1
>
>
> When operation handlers request non-existent capabilities, the error messages aren't particularly helpful. For example:
> /"WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0364: Capability 'org.wildfly.data-source.invalid' is unknown."
> This is largely because it's the CapabilityRegistry that throws the exceptions, and it doesn't have much context about why the capability is needed to use in a better error message.
> Likely solutions are:
> 1) If CapabilityRegistryImpl has more context than is being used, look into using it.
> 2) Provide more context to CapabilityRegistry (I don't much like this one; providing parameters to a call only for use in a failure message is smelly to me.)
> 3) Use a custom exception type when the capability is missing, instead of ISE, and have OperationContextImpl catch that and add contextual information.
> I expect 3) is the likely solution.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 8 months
[JBoss JIRA] (WFCORE-628) Support for 'query' operation on legacy slaves
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-628?page=com.atlassian.jira.plugin... ]
James Perkins updated WFCORE-628:
---------------------------------
Fix Version/s: 2.0.0.CR1
(was: 2.0.0.Beta5)
> Support for 'query' operation on legacy slaves
> ----------------------------------------------
>
> Key: WFCORE-628
> URL: https://issues.jboss.org/browse/WFCORE-628
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Priority: Critical
> Fix For: 2.0.0.CR1
>
>
> WFCORE-287 will introduce a new 'query' operation. But in a mixed domain, slaves running legacy versions will not understand that operation. So the console, when managing such a domain will either need to analyze the management API version of each host and not target 'query' ops to legacy hosts, or we need to figure out a way to emulate support on the DC.
> One thought I had was to use a transformer. My understanding of how query works is it's essentially a read-resource and then some post-processing is applied to filter the result. So my thought is an operation transformer can convert the query op to a read-resource op, which the slave will understand, and then a result transformer on the DC does the filtering work.
> There may of course be gotchas there.
> One issue I see is I think this query op is going to be a global op. I don't believe we currently have hooks for registering transformers for global ops. That is, there's nothing like the 'inherited' handling we use for registering the handler for the global op and then discovering it when resolving the operation name against child resource registrations.
> Another issue to remember is 'query' op will support wildcard addresses, so the result transformer will need to understand how to detect and deal with the different result format from a wildcard read-resource (result is a LIST of OBJECT) versus a simple read-resource (just an OBJECT).
> It's better if the filtering is done as soon as possible (to save the cost of transmitting data from servers to slaves to the DC just so the DC can filter) but for this mixed domain case I think it's ok to send the full read-resource result back to the DC.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 8 months
[JBoss JIRA] (WFCORE-621) Support legacy slaves when invoking wildcard reads in a domain
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-621?page=com.atlassian.jira.plugin... ]
James Perkins updated WFCORE-621:
---------------------------------
Fix Version/s: 2.0.0.CR1
(was: 2.0.0.Beta5)
> Support legacy slaves when invoking wildcard reads in a domain
> --------------------------------------------------------------
>
> Key: WFCORE-621
> URL: https://issues.jboss.org/browse/WFCORE-621
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Priority: Critical
> Fix For: 2.0.0.CR1
>
>
> This is a follow-on to WFCORE-282.
> The WFCORE-282 will not work for requests with address patterns /host=*/server=* or /host=somename/server=* if the host named 'somename' is running a WFCORE version prior to 1.0.0.CR1 (or whatever release first has WFCORE-282 introduced.)
> In particular, it won't work with slaves running EAP 6.x.
> The problem is with either of those address patterns the DC will send a request addressed to /host=somename/server=* to the slave, and the slave will not be able to handle it, as it won't have the WFCORE-282 logic that lets it identify the relevant servers and send requests on to them.
> Potentially this could be fixed by having the DC detect these patterns and not call /host=somename/server=*, instead adding a step to read the server child names from /host=somename and then call /host=somename/server=a, /host=somename/server=b, etc.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 8 months
[JBoss JIRA] (WFCORE-910) Reading metrics with dots in their names blows up
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-910?page=com.atlassian.jira.plugin... ]
James Perkins updated WFCORE-910:
---------------------------------
Fix Version/s: 2.0.0.CR1
(was: 2.0.0.Beta5)
> Reading metrics with dots in their names blows up
> -------------------------------------------------
>
> Key: WFCORE-910
> URL: https://issues.jboss.org/browse/WFCORE-910
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Affects Versions: 2.0.0.Beta4
> Reporter: Kabir Khan
> Assignee: Tomaz Cerar
> Priority: Blocker
> Fix For: 2.0.0.CR1
>
>
> When doing a :read-resource(include-runtime=true,recursive=true) this blows up. Debugging shows that to be because e.g. the resource /subsystem=jgroups/channel=ee/protocol=UDP contains metrics called things like
> {code}
> "timer.keep_alive_time" => {
> "type" => LONG,
> "description" => "Timeout in ms to remove idle threads from the timer pool",
> "expressions-allowed" => false,
> "nillable" => false,
> "access-type" => "metric",
> "storage" => "runtime"
> },
> "timer.max_threads" => {
> "type" => INT,
> "description" => "Max thread pool size for the timer thread pool",
> "expressions-allowed" => false,
> "nillable" => false,
> "access-type" => "metric",
> "storage" => "runtime"
> },
> "timer.min_threads" => {
> "type" => INT,
> "description" => "Minimum thread pool size for the timer thread pool",
> "expressions-allowed" => false,
> "nillable" => false,
> "access-type" => "metric",
> "storage" => "runtime"
> },
> {code}
> i.e. they have a dot in their name. So when the r-r handler wants to read the attributes it in effect tries to do the following demonstrated by CLI commands:
> {code}
> [standalone@localhost:9990 /] /subsystem=jgroups/channel=ee/protocol=UDP:read-attribute(name=timer
> timer.keep_alive_time timer.min_threads timer.rejection_policy timer.wheel_size timer_queue_size timer_threads
> timer.max_threads timer.queue_max_size timer.tick_time timer_class timer_tasks timer_type
> [standalone@localhost:9990 /] /subsystem=jgroups/channel=ee/protocol=UDP:read-attribute(name=timer.max_threads)
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0201: Unknown attribute 'timer'",
> "rolled-back" => true
> }
> {code}
> I see ReadResourceHandler has some stuff to extract the attribute name if 'extended syntax' is used. So we have two options:
> 1) Ban dots in metric/attribute names
> 2) Add a workaround to fall back. In other words if ReadAttributeHandler thinks extended syntax is being used, and cannot find the extracted 'timer' attribute, then try the full non-extracted name, e.g. timer.max_threads, and only then error.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 8 months