[JBoss JIRA] (SWITCHYARD-649) Fix TODO in BPEL module assembly
by Magesh Bojan (JIRA)
Magesh Bojan created SWITCHYARD-649:
---------------------------------------
Summary: Fix TODO in BPEL module assembly
Key: SWITCHYARD-649
URL: https://issues.jboss.org/browse/SWITCHYARD-649
Project: SwitchYard
Issue Type: Enhancement
Components: build, deployment
Affects Versions: 0.3
Reporter: Magesh Bojan
Assignee: Magesh Bojan
Fix For: 0.4
BPEL module assembly has these TODOs:
<!-- TODO: Tried to use 'org.jaxen' module, but got:
java.lang.ClassNotFoundException: org.w3c.dom.Node from [Module "org.jaxen:main" from local module loader
when running an example. org.w3c.dom.Node is part of the jvm rt.jar, so not sure why
it can't find this class.
<resource-root path="jaxen-1.1.1.jar"/>
-->
<!-- TODO: Tried to create separate module, but got:
java.lang.ClassNotFoundException: javax.xml.transform.sax.SAXTransformerFactory from [Module "net.sourceforge.saxon:main"
<resource-root path="saxonhe-9.2.1.5.jar"/>
-->
Remove this and move them to their own module.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (SWITCHYARD-647) Service metrics
by Gary Brown (JIRA)
Gary Brown created SWITCHYARD-647:
-------------------------------------
Summary: Service metrics
Key: SWITCHYARD-647
URL: https://issues.jboss.org/browse/SWITCHYARD-647
Project: SwitchYard
Issue Type: Feature Request
Reporter: Gary Brown
Will describe some of the features that are required in this area, but after discussion should probably be created as separate sub-tasks.
a) Service managed objects
Need to have an internal managed object structure for the switchyard service application representing the components of interest. Initially I think from a management/governance perspective, only the public provided/consumed interfaces are relevant, even though there may be multiple internal components that interact to implement the service - but that can be discussed.
Suggestion would be to have a hierarchy with the service containing both the provided and consumed interfaces, with each interface further containing its operations.
For each operation it should be possible to record invocation stats (e.g. number of invocations and min/avg/max response times) for both normal responses, aswell as fault responses - having the stats broken down per fault type.
It may also be useful to record stats against invocations that fail for technical reasons, e.g. communications failure or security.
b) RESTful service to provide access to the service managed object information
c) Optionally a JMX interface, to enable management products to access the information
d) RHQ/JON agent plugin, to periodically collect the service metric information, as well as providing auto-discovery capabilities for services, so that a user does not have to manually configure services into JON
e) The final aspect of this task would be to enable developers to define 'event hooks' upon which they can provide additional adhoc governance requirements - however this requirement is probably satisfied by the handler mechanism? Although possible we may wish to provide out of the box handlers geared to this task, possibly with a logging variation (and others??).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months