[JBoss JIRA] Created: (AS7-1994) access to the ModelNodeRegistration during handling of an operation and during deployment
7:11 p.m.
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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:11 p.m.
New subject: [JBoss JIRA] Commented: (AS7-1994) access to the ModelNodeRegistration during handling of an operation and during deployment
[
https://issues.jboss.org/browse/AS7-1994?page=com.atlassian.jira.plugin.s...
]
Stefano Maestri commented on AS7-1994:
--------------------------------------
Hi all,
I'm reporting here a discussion I had with Emanuel regarding this issue and the
implementation of JCA metrics. During the discussion I've recalled also the original
discussion, and our needs.
I'm sending this email mainly as reminder for me to discuss these points with Brian
after his and mine vacations
regard
S.
* pferraro_ (~pferraro(a)adsl-99-97-30-7.dsl.wlfrct.sbcglobal.net) has joined #jboss-as7
<emuckenhuber_> maeste: pong
* emuckenhuber_ is now known as emuckenhuber
<maeste> emuckenhuber_: Hi, I'm trying to implement our metrics. Just to recall
we need this issue Brian has resolved to implement them: AS7-772
<jbossbot> jira [AS7-772] Allow operation handlers to register child
ModelNodeRegistrations [Resolved (Done) Feature Request, Critical, Brian Stansberry]
https://issues.jboss.org/browse/AS7-772
<maeste> emuckenhuber: what I'm trying to do is:
* bbrowning (~bbrowning@redhat/jboss/bbrowning) has joined #jboss-as7
* ChanServ gives voice to bbrowning
<maeste> emuckenhuber:
https://github.com/maeste/jboss-as/commit/d08f758b39d6a83257745cf86fe9f7c...
<jbossbot> git [jboss-as] d08f758.. Stefano Maestri stats prototype
<maeste> emuckenhuber: but I'm getting this exception
<maeste> emuckenhuber: https://gist.github.com/1111413
<maeste> emuckenhuber: have you an idea what I'm doing wrong?
<emuckenhuber> maeste: yes
<maeste> emuckenhuber: sorry to ask you for a Brian's issue, but AFAIK Brian is
away until 11 August
<maeste> emuckenhuber: cool
<emuckenhuber> maeste: basically you would need to register the handlers inside that
operation
<maeste> emuckenhuber: yup, moreover after a service activated by this operation has
been started
<maeste> emuckenhuber: it's the reason because I've added a listener
<maeste> emuckenhuber: line 91
<emuckenhuber> maeste: no, i'm saying operations have to be registered as part
of operation handler itself
<emuckenhuber> which is basically the exception
<maeste> emuckenhuber: you have lost me
<emuckenhuber> actually all operation handlers should be registered as part of the
Extension
<maeste> emuckenhuber: oki, but it's what AS7-772 try to solve
<jbossbot> jira [AS7-772] Allow operation handlers to register child
ModelNodeRegistrations [Resolved (Done) Feature Request, Critical, Brian Stansberry]
https://issues.jboss.org/browse/AS7-772
<maeste> emuckenhuber: at least AFAI understood
<maeste> emuckenhuber: this is our original problem
<emuckenhuber> hmm, imho that does not make any sense
<maeste> emuckenhuber: we have to register operation (metics in this case) after a
datasource have been created
<emuckenhuber> well perhaps a bit
<emuckenhuber> anyway - you would have to register that as part of populateModel()
* asoldano is now known as asoldano_lunch
<maeste> emuckenhuber: because metrics are dynamic for us and need a concrete
instance of ResourceAdapter/DS
<emuckenhuber> yeah, but it basically does not really comply with how the management
model works
<maeste> emuckenhuber: there was a discussion on ML in May about that, and then
Brian created 772
<emuckenhuber> you remember the subject?
<maeste> emuckenhuber: discussion subject was "access to the
ModelNodeRegistration during handling of an operation and during deployment"
* kevinpollet (~kevinpoll(a)217.112.54.72) has joined #jboss-as7
* abstractj (~abstractj(a)186.202.49.66) has joined #jboss-as7
* hbraun (~hbraun(a)ppp-93-104-112-69.dynamic.mnet-online.de) has joined #jboss-as7
* hbraun has quit (Client Quit)
* miclorb_ has quit (Remote host closed the connection)
<emuckenhuber> maeste: hmm, ok that's an issue then
<maeste> emuckenhuber: so, basically you are saying it's not implented
<maeste> emuckenhuber: oki, I'll put down in my todo list
<maeste> emuckenhuber: better to wait for Brian, since I've discussed about that
a lot with him
<emuckenhuber> maeste: well i would not say 'not implemented' - we actually
have a check to prevent exactly this
<maeste> emuckenhuber: oki much stronger
<maeste> emuckenhuber:
<emuckenhuber> maeste: well perhaps you want to do a single operation handler which
gives you all the metrics for now?
<emuckenhuber> not sure how critical that is for the console work
<maeste> emuckenhuber: not possible, it was already done, but it doesn't work
<emuckenhuber> why?
<maeste> emuckenhuber: or better it works, but not as expected
<maeste> emuckenhuber: because sometimes some metrics are not available
<maeste> emuckenhuber: to be more precise...
<maeste> emuckenhuber: it's done and it's already part of the current
master
<emuckenhuber> maeste: PoolMetrics?
<maeste> emuckenhuber: but we would like to support a more complete metrics stuffs,
and moreover to don't depend on IJ impls, but just spi
<maeste> emuckenhuber: yup
<maeste> emuckenhuber: I've just put this new dynamic implementation in my todo
stack, waiting for 772. And today I had time to get into, but it's now clear that I
haven't understood what 772 really is
<maeste> emuckenhuber: anyway no rush for that, I can wait Brian...moreover I'll
be on PTO too next 2 weeks...I just have 1.5 day of work and my plate is full of other
things to cook
<emuckenhuber> maeste: ok
<maeste> emuckenhuber: thanks for your time
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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:11 p.m.
New subject: [JBoss JIRA] Commented: (AS7-1994) access to the ModelNodeRegistration during handling of an operation and during deployment
[
https://issues.jboss.org/browse/AS7-1994?page=com.atlassian.jira.plugin.s...
]
Stefano Maestri commented on AS7-1994:
--------------------------------------
Brian said:
Some thoughts before I start PTO again (I'm in the Beijing office today.)
The exception happens because the OperationContextImpl enforces only updating the resource
registry during stage MODEL. That's kind of arbitrary; I'll think about if it
could be relaxed.
It could be hacked around by not subclassing AbstractAddStepHandler but just implementing
it's logic directly and calling context.getResourceRegistrationForUpdate() in the
MODEL stage handler. Then use it later. Of course if I'd accept a patch with such a
hack I should just remove the check for stage MODEL.
The next question is the whole business of updating the resource registry from a service
listener. The important thing is that operations acquire an exclusive lock on the
ModelController. It's acquired when the first handler invokes any of the
OperationContext methods that indicate the handler is going to mutate the model, the
resource registry or the MSC services. (Read only ops don't acquired the lock.)
It's released when that handler returns from execute(). Any mutation of the
model/resource registry/MSC services must be done with that lock held. That semantic
*must* be enforced; no patch that violates that will be accepted.
This service listener approach doesn't necessarily violate that semantic. During stage
VERIFY the thread executing the operation will block until the MSC service container is
settled and all demanded services have started or failed. That *could* mean this listener
will have been invoked. What has to happen is some logic to make sure this listener
can't be invoked some other time. E.g. if the service is restarted; if the service is
ON-DEMAND and isn't demanded, etc. If any of those things happen the listener should
not mutate the registry.
Hmm, that leads to the question of how this stuff gets cleaned up; e.g. what if the
:reload operation is invoked? I think that should be ok, as the entire resource registry
gets rebuilt.
But, what's definitely missing is
ManagedResourceRegistration.removeSubModel()/removeMetric()/removeOperationHandler().
There's no way for a "remove" handler to delete this stuff!
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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:36 p.m.
New subject: [JBoss JIRA] (AS7-1994) access to the ModelNodeRegistration during handling of an operation and during deployment
[
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
10:42 p.m.
New subject: [JBoss JIRA] (AS7-1994) access to the ModelNodeRegistration during handling of an operation and during deployment
[
https://issues.jboss.org/browse/AS7-1994?page=com.atlassian.jira.plugin.s...
]
Brian Stansberry updated AS7-1994:
----------------------------------
Component/s: Domain Management
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
5:16 p.m.
New subject: [JBoss JIRA] (AS7-1994) access to the ModelNodeRegistration during handling of an operation and during deployment
[
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
5:16 p.m.
New subject: [JBoss JIRA] (AS7-1994) access to the ModelNodeRegistration during handling of an operation and during deployment
[
https://issues.jboss.org/browse/AS7-1994?page=com.atlassian.jira.plugin.s...
]
Jesper Pedersen updated AS7-1994:
---------------------------------
Priority: Critical (was: Major)
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
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
3:59 p.m.
New subject: [JBoss JIRA] (AS7-1994) access to the ModelNodeRegistration during handling of an operation and during deployment
[
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
3:59 p.m.
New subject: [JBoss JIRA] (AS7-1994) access to the ModelNodeRegistration during handling of an operation and during deployment
[
https://issues.jboss.org/browse/AS7-1994?page=com.atlassian.jira.plugin.s...
]
Stefano Maestri reassigned AS7-1994:
------------------------------------
Assignee: Stefano Maestri (was: Brian Stansberry)
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
4:21 a.m.
New subject: [JBoss JIRA] (AS7-1994) access to the ModelNodeRegistration during handling of an operation and during deployment
[
https://issues.jboss.org/browse/AS7-1994?page=com.atlassian.jira.plugin.s...
]
Brian Stansberry updated AS7-1994:
----------------------------------
Priority: Blocker (was: Critical)
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: Blocker
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
4534
days inactive
4594
days old
9 comments
7 participants
participants (7)
-
Brian Stansberry (Commented) (JIRA) -
Brian Stansberry (Updated) (JIRA)
-
Jesper Pedersen (Commented) (JIRA)
-
Jesper Pedersen (Updated) (JIRA)
-
Stefano Maestri (Assigned) (JIRA)
-
Stefano Maestri (Commented) (JIRA)
-
Stefano Maestri (JIRA)