[
https://issues.jboss.org/browse/AS7-1994?page=com.atlassian.jira.plugin.s...
]
Jesper Pedersen commented on AS7-1994:
--------------------------------------
Datasources will have the same statistics definition since they share the same resource
adapter. However, it is up to the resource adapter to tell which statistics that are
supported. This is done through the JCA/SPI call that is available after the resource
adapter has been booted (non-static). Having a hard-code implementation in the code is a
major hack.
As for pure resource adapter deployments we don't know what they support before we
have the instance of the plugin - so those cases can't use the same hack.
Therefore we need a way to tell what we support after boot, and not through a hard coded
list.
access to the ModelNodeRegistration during handling of an operation
and during deployment
-----------------------------------------------------------------------------------------
Key: AS7-1994
URL:
https://issues.jboss.org/browse/AS7-1994
Project: Application Server 7
Issue Type: Task
Components: Domain Management
Affects Versions: 7.1.0.Alpha1
Reporter: Stefano Maestri
Assignee: Brian Stansberry
Fix For: 7.1.0.CR1
Hi All,
I'm trying to resume here the discussion I had yesterday on IRC with
Brian and Jesper.
Basically JCA needs to have and already deployed instance of
ResourceAdapter when adding its metrics and some operation. The reason
for that is because some operation and metrics availability are known
only at runtime, depending from RA status and/or vendor specific feature
known only.
Speaking from a Model point of view the basically issue is to have
access to the ModelNodeRegistration when the RA instance is created and
these runtime infos are available. There are 2 cases:
1) during handling ADD operation for a DataSource or special
ResourceAdapter creation withour rar deployment (like hornetQ).
2) during foo.rar deployment chain
We have also discussed where we can put these operation in the model
tree. Also in this case there are two possible places:
1) at subsystem level for special no-deployment RA (DataSources and
HornetQ atm). So we will obtain something like
/subsystem=datasource/data-source=myDS and /subsystem=hq/ra
2) at DUP level /deployment=foo.rar Having this deployment support we
can remove the current operation in /subsystem=resource-adapters that is
redudant, referring the same RA (or better a subset of deployed ones)
Hoping to have written all the matters discussed, feel free to integrate
and/or ask.
regards
S.
--
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