[
https://issues.jboss.org/browse/AS7-1994?page=com.atlassian.jira.plugin.s...
]
Stefano Maestri commented on AS7-1994:
--------------------------------------
<maeste> bstansberry: 2nd question have you time to discuss AS7-1994
<jbossbot> jira [AS7-1994] access to the ModelNodeRegistration during handling of an
operation and during deployment [Open (Unresolved) Task, Critical, Brian Stansberry]
https://issues.jboss.org/browse/AS7-1994<maeste> bstansberry: as jesper commented in
the issue we would need this runtime access/change to the model
<bstansberry> maeste: you want to do it?
<maeste> bstansberry: especially for ra (not ds) but also for ds would be a major
hack
<maeste> bstansberry: yup wy not. Just tell me if it has more or less priority of
AS7-925
<jbossbot> jira [AS7-925] Expose the transaction logs via the domain management API
[Open (Unresolved) Sub-task, Major, Stefano Maestri]
https://issues.jboss.org/browse/AS7-925
<bstansberry> maeste: elements of it have higher priority
<bstansberry> maeste: specifically...
<bstansberry> 1) ManagementResourceRegistration needs a removeSubmodel API
<bstansberry> 2) it should have a clone() method so the OperationContextImpl can
treat it the way it treats the Resource
<bstansberry> -- it clones before first write and then publishes the clone back to
the ModelController on success
<bstansberry> if the op fails, the clone just isn't published and there is no
need to clean up any changes made to the model (and now the registry)
<maeste> bstansberry: oki I'll have a look and back to you if I'll have
questions
<bstansberry> maeste: thanks!
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: Stefano Maestri
Priority: Critical
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