[JBoss JIRA] (WFCORE-2830) Split testsuite/shared to distinguish things meant for sharing within the core testsuite from things usable in other projects
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2830?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2830:
-------------------------------------
Issue Type: Task (was: Bug)
> Split testsuite/shared to distinguish things meant for sharing within the core testsuite from things usable in other projects
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2830
> URL: https://issues.jboss.org/browse/WFCORE-2830
> Project: WildFly Core
> Issue Type: Task
> Components: Test Suite
> Reporter: Brian Stansberry
> Fix For: 4.0.0.Beta1
>
>
> The testsuite/shared module includes two conceptually different types of code:
> 1) Things that are meant to be usable across different modules in core's own testsuite.
> 2) Things that we are willing to support for use in other projects that rely on WildFly Core.
> Since the two things are mixed, we are essentially supporting externally things that are not intended for use outside core. And it makes it difficult to evaluate new additions to testsuite/shared, to see whether the addition is really relevant to core and to see whether proposed external use is something we want.
> The purpose of WildFly Core is not to be a provider of testsuite utilities. For anything we expose for external use, there should be a substantial code maintenance benefit that comes from sharing it, something beyond avoiding code duplication.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-2830) Split testsuite/shared to distinguish things meant for sharing within the core testsuite from things usable in other projects
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-2830:
----------------------------------------
Summary: Split testsuite/shared to distinguish things meant for sharing within the core testsuite from things usable in other projects
Key: WFCORE-2830
URL: https://issues.jboss.org/browse/WFCORE-2830
Project: WildFly Core
Issue Type: Bug
Components: Test Suite
Reporter: Brian Stansberry
Fix For: 4.0.0.Beta1
The testsuite/shared module includes two conceptually different types of code:
1) Things that are meant to be usable across different modules in core's own testsuite.
2) Things that we are willing to support for use in other projects that rely on WildFly Core.
Since the two things are mixed, we are essentially supporting externally things that are not intended for use outside core. And it makes it difficult to evaluate new additions to testsuite/shared, to see whether the addition is really relevant to core and to see whether proposed external use is something we want.
The purpose of WildFly Core is not to be a provider of testsuite utilities. For anything we expose for external use, there should be a substantial code maintenance benefit that comes from sharing it, something beyond avoiding code duplication.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-2829) Expose the ProcessType via the ManagementResourceRegistration
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2829?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2829:
-------------------------------------
Issue Type: Enhancement (was: Bug)
> Expose the ProcessType via the ManagementResourceRegistration
> -------------------------------------------------------------
>
> Key: WFCORE-2829
> URL: https://issues.jboss.org/browse/WFCORE-2829
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> An Extension needs to be usable both on a HostController (for registering the subsystem management model for use in domain profiles) and on a server. But the API exposed by the Extension can differ in the two cases, as there are no runtime services behind a domain profile resource, while there usually are behind a server resource. So the Extension implementation needs to behave differently depending on the type of process it is running in.
> To support this, the ExtensionContext provided to the Extension exposes the ProcessType. But this isn't particularly friendly, as that forces the Extension impl to provide that ProcessType to its ResourceDefinition impls, and those are typically created in a tree with the Extension impl only creating the root. So lots of custom constructors passing a ProcessType down the tree.
> If ManagementResourceRegistration exposed the ProcessType, then the ResourceDefinition impls could directly read it when deciding what attributes/operations/children/notifications to register.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-2829) Expose the ProcessType via the ManagementResourceRegistration
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2829?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-2829:
------------------------------------------
WFCORE-2829 is important for the WFCORE-389 use cases as we want to make it easy for extension authors to decide whether or not to register an operation. In particular we don't want ops being registered on the profile that aren't really suitable just because it is too difficult to turn off such registration.
> Expose the ProcessType via the ManagementResourceRegistration
> -------------------------------------------------------------
>
> Key: WFCORE-2829
> URL: https://issues.jboss.org/browse/WFCORE-2829
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> An Extension needs to be usable both on a HostController (for registering the subsystem management model for use in domain profiles) and on a server. But the API exposed by the Extension can differ in the two cases, as there are no runtime services behind a domain profile resource, while there usually are behind a server resource. So the Extension implementation needs to behave differently depending on the type of process it is running in.
> To support this, the ExtensionContext provided to the Extension exposes the ProcessType. But this isn't particularly friendly, as that forces the Extension impl to provide that ProcessType to its ResourceDefinition impls, and those are typically created in a tree with the Extension impl only creating the root. So lots of custom constructors passing a ProcessType down the tree.
> If ManagementResourceRegistration exposed the ProcessType, then the ResourceDefinition impls could directly read it when deciding what attributes/operations/children/notifications to register.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-2829) Expose the ProcessType via the ManagementResourceRegistration
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-2829:
----------------------------------------
Summary: Expose the ProcessType via the ManagementResourceRegistration
Key: WFCORE-2829
URL: https://issues.jboss.org/browse/WFCORE-2829
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
An Extension needs to be usable both on a HostController (for registering the subsystem management model for use in domain profiles) and on a server. But the API exposed by the Extension can differ in the two cases, as there are no runtime services behind a domain profile resource, while there usually are behind a server resource. So the Extension implementation needs to behave differently depending on the type of process it is running in.
To support this, the ExtensionContext provided to the Extension exposes the ProcessType. But this isn't particularly friendly, as that forces the Extension impl to provide that ProcessType to its ResourceDefinition impls, and those are typically created in a tree with the Extension impl only creating the root. So lots of custom constructors passing a ProcessType down the tree.
If ManagementResourceRegistration exposed the ProcessType, then the ResourceDefinition impls could directly read it when deciding what attributes/operations/children/notifications to register.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (LOGTOOL-101) Exception transformation
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-101?page=com.atlassian.jira.plugi... ]
James Perkins updated LOGTOOL-101:
----------------------------------
Fix Version/s: 2.1.0.Alpha3
> Exception transformation
> ------------------------
>
> Key: LOGTOOL-101
> URL: https://issues.jboss.org/browse/LOGTOOL-101
> Project: Log Tool
> Issue Type: Feature Request
> Reporter: David Lloyd
> Assignee: James Perkins
> Fix For: 2.1.0.Alpha3
>
>
> I'd like to be able to transform an exception message. What this means is, create a new exception, embed its message in my message, and copy its stack trace to mine.
> Something like this:
> {code}
> @Message(id = 1234, "Binding to %s failed")
> IOException bindFailed(SocketAddress bindAddress, @TransformException IOException cause)
> {code}
> This would yield a message like: "Binding to 1.2.3.4/1234 failed: Address already in use". Note the addition of the ": " and the source string.
> Note that I can almost do this now, except that there's no way to copy the exception stack:
> {code}
> @Message(id = 1234, "Binding to %s failed: %s")
> IOException bindFailed(SocketAddress bindAddress, IOException cause)
> {code}
> An alternative approach is to add an annotation for copying the stack trace:
> {code}
> @Message(id = 1234, "Binding to %s failed")
> IOException bindFailed(SocketAddress bindAddress, @CopyStackFrom IOException cause)
> {code}
> Note that in this case the original exception message is lost. The next variant would preserve the message:
> {code}
> @Message(id = 1234, "Binding to %s failed: %s")
> IOException bindFailed(SocketAddress bindAddress, IOException cause, @CopyStackFrom IOException cause2)
> {code}
> And now to eliminate the duplication:
> {code}
> @Message(id = 1234, "Binding to %s failed: %s")
> IOException bindFailed(SocketAddress bindAddress, @CopyStackFrom @Pos(2) IOException cause)
> {code}
> Note that I don't recall if @Pos is 1- or 0-based, so I guessed.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (LOGTOOL-124) Ability to provide exception producer
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-124?page=com.atlassian.jira.plugi... ]
James Perkins updated LOGTOOL-124:
----------------------------------
Fix Version/s: 2.1.0.Alpha3
> Ability to provide exception producer
> -------------------------------------
>
> Key: LOGTOOL-124
> URL: https://issues.jboss.org/browse/LOGTOOL-124
> Project: Log Tool
> Issue Type: Feature Request
> Reporter: David Lloyd
> Priority: Minor
> Fix For: 2.1.0.Alpha3
>
>
> Sometimes you must use the same exception message for many different types of exception. It would be nice if you could give a parameter which can produce an exception, like this:
> {code}
> public interface MyLogs {
> // ...
> @Message(id = 1234, "The operation failed due to %s")
> <T extends Throwable> T operationFailed(@Producer Function<String, T> fn, String thing);
> }
> {code}
> And later at usage:
> {code}
> // ...
> throw MyLogs.log.operationFailed(IOException::new, "thingy");
> {code}
> A valid function parameter must return a type which is equal or assignable to the return type, and is assignable to Throwable. Other than that, it can be treated the same as as if you were dealing with a constructor class that has exactly one constructor, using the same matching/inference logic, meaning you could also accept BiFunction which accepts two arguments.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (HAWKULARQE-71) Test Hawkular Java Agent
by Sunil kondkar (JIRA)
[ https://issues.jboss.org/browse/HAWKULARQE-71?page=com.atlassian.jira.plu... ]
Sunil kondkar commented on HAWKULARQE-71:
-----------------------------------------
EAP6 is not discovered in CFME when installed on openshift with below image:
brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/jboss-eap-6/eap64-openshift:1.5
Reference bug: https://bugzilla.redhat.com/show_bug.cgi?id=1452118
> Test Hawkular Java Agent
> ------------------------
>
> Key: HAWKULARQE-71
> URL: https://issues.jboss.org/browse/HAWKULARQE-71
> Project: Hawkular QE
> Issue Type: Task
> Reporter: Hayk Hovsepyan
> Assignee: Sunil kondkar
> Priority: Minor
>
> There is a new Java Agent (HJA) that you can run in any JVM (including
> but not limited to EAP-based projects). You do so by passing in a
> "-javaagent" command line option to your JVM (e.g. java
> -javaagent=hawkular-javaagent.jar=config=config.yaml -jar my-app.jar
> ...yadda...). There are two additional properties you must set in
> standalone.conf if you want to run it inside an EAP JVM. The README will
> have the details.
> This new HJA is configured with a yaml file that largely mimics all the
> standalone.xml data that HWFA has. There is no ${x} support in the YAML
> file right now.
> This new HJA can talk to any EAP or WildFly server over the DMR management
> API. It can do deployments to your EAP/WildFly servers and monitoring of
> EAP/WildFly subsystems just like HWFA can.
> This new HJA can talk to any JMX server just like HWFA can (it will talk to
> the local MBeanServer or, if remotely monitoring a JMX server, it will talk
> to it over Jolokia/REST API).
> This new HJA can NOT run directly inside of a Host Controller due to
> https://issues.jboss.org/browse/WFCORE-2526 - however, you can run HJA
> externally in its own JVM (e.g. java -jar hawkular-javaagent.jar
> config=config.yaml) and have its config.yaml point to a remote Host
> Controller and you'll get the same functionality.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month