[
https://issues.jboss.org/browse/AS7-1994?page=com.atlassian.jira.plugin.s...
]
Brian Stansberry commented on AS7-1994:
---------------------------------------
For the Datasource case, does StatisticsPlugin have a field that forms a natural key?
Looking at
https://github.com/maeste/jboss-as/commit/d08f758b39d6a83257745cf86fe9f7c...,
the concern I have is it appears you are modifying a generic resource registration by
adding instance-specific metrics.
So, the management interface for /subsystem=datasources/datasource=* has one set of
attributes and ops, /subsystem=datasources/datasource=myDS has another set (a superset if
we could make that work) and /subsystem=datasources/datasource=anotherDS has a 3rd set.
It's almost like an abstract superclass and concrete subclasses.
That might be possible, but I don't much like the idea that a resource's
definition changes.
Something like /subsystem=datasources/datasource=myDS/statistics-provider=oracle and
/subsystem=datasources/datasource=myDS/statistics-provider=postgres sounds nicer. The
statistics-provider level works like "subsystem" works.
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
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