[ https://jira.jboss.org/browse/JBAS-8222?page=com.atlassian.jira.plugin.sy... ] Jason Greene updated JBAS-8222: ------------------------------- Parent: (was: JBAS-8172) Issue Type: Task (was: Sub-task) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBAS-8222?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated JBAS-8222: ----------------------------------- Fix Version/s: 7.0.0.Beta3 (was: 7.0.0.CR1) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBAS-8222?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated JBAS-8222: ----------------------------------- Fix Version/s: 7.0.0.CR1 (was: 7.0.0.Beta4) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-501?page=com.atlassian.jira.plugin.sy... ] Jason Greene updated AS7-501: ----------------------------- Fix Version/s: 7.1.0.Beta1 (was: 7.1.0.Alpha1) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-501?page=com.atlassian.jira.plugin.sy... ] Brian Stansberry resolved AS7-501. ---------------------------------- Fix Version/s: No Release (was: 7.1.0.CR1) Resolution: Won't Fix Following discussion with Stefano Maestre, we decided the benefits of doing this vs simply using system properties were not enough to justify the effort, at least at this time. Following is the discussion we had where we discussed an approach, and outlined its benefits. Perhaps could be useful if someday we decided to pursue this: <maeste2> bstansberry: I wonder if these undocumented generic properties (that JBossTS map to system propeerties) have to be specified in tx subsystem or if we can make anew subsystem for generic properties (not only for tx) <maeste2> bstansberry: in second case we have 2 plus IMHO <maeste2> bstansberry: an xsd documenting the xml sturcture and a subsystem to manage via console <maeste2> bstansberry: #2 the ability to add here some special properties also during EAP phase <maeste2> bstansberry: sincee we are going to use a generic API for this properties/values <maeste2> bstansberry: JBossTS (or other services needing special props) can just depends on this subsystem's service <maeste2> bstansberry: opinion? * bstansberry is pondering this a bit <bstansberry> maeste2: the entire use case goes beyond subsystems though, so this would almost be a core item <bstansberry> maeste2: so to register a handler, that would really be another high-level part of what an Extension does bstansberry> maeste2: so we'd add something in SubsystemRegistration? <bstansberry> maeste2: I'd been thinking to just use system properties, but your ideas have gotten me intrigued <bstansberry> maeste: looking at <property-group subsystem="blah"><property name="blah">value</property><property-group> ... <bstansberry> I see two theoretically benefits over simple system properties <bstansberry> one is if "value" had some more structure, wasn't just a string <bstansberry> but TBH I doubt that's practical, since this needs to be generic <maeste> bstansberry: yup <bstansberry> the other is the subsystem="blah" bit <bstansberry> which is an example of providing some scope to the property <maeste> bstansberry: even if we can use an attribute called type and we can validate against it <maeste> bstansberry: it's not more structure, but it still a plus against system property <maeste> bstansberry: another benefit is that they are manageable (at least theoretically) <bstansberry> maeste: well, system properties are manageable too <maeste> bstansberry: but they haven't custom handlers <bstansberry> maeste: right <bstansberry> that was the intriguing part <maeste> bstansberry: theoretically they could be runtime manageble <maeste> bstansberry: why can't be an OperationStepHandler? <bstansberry> maeste: I guess it can be <bstansberry> maeste: there's an ordering issue <bstansberry> any OSH will only be registered after the relevant extension is added <bstansberry> but all the extension properties have to be evaluated before any subsystem is added <bstansberry> otherwise the subsystem can start without knowing the value <maeste> sure <bstansberry> maeste: so that just means 1) this would have to be a core thing, not a subsystem and 2) in the boot handling its operations have to come before the subsystem ones <bstansberry> maeste: so that's solvable <bstansberry> maeste: we'd also need to add that outside subsystems <maeste> it's a different approach in model, but we are still saying that there are properties scoped at subsystem level <bstansberry> e.g. for core stuff bstansberry> TBH I really dislike adding that to every subsystem though <maeste> oki <bstansberry> I've had way too much experience with what it takes to add some new capability to every subsystem <maeste> returning to ordering issue <bstansberry> that's solvable pretty easily <maeste> oki <bstansberry> just put this new element in the xsd after extension and before subsystem <bstansberry> before profile <maeste> gotcha <bstansberry> maeste: it just took me a bit to realize that <maeste> a bit more for me <bstansberry> maeste: so the advantages of this are 1) runtime handling and 2) scoping <bstansberry> i.e. a finer scope than the entire server <bstansberry> which is the scope of a system property <bstansberry> how about <property-group scope="subsystem=datasource/datasource=blah"><property name="blah">value</property><property-group> ? <bstansberry> scope or "address" or something <maeste> bstansberry: cool <bstansberry> maeste: that starts to make scoping a real benefit <maeste> bstansberry: where type reflect DMR ones and make possible to add a validator on the property? <bstansberry> maeste: so it could be <property name="blah" type="OBJECT">{"foo"="bar","an-int"=2}</property> <bstansberry> maeste: continuing to brainstorm a bit <maeste> bstansberry: sure <bstansberry> get rid of the subsystem OSH part, other than the core <bstansberry> just create the service <bstansberry> at boot, subsystems use the service <bstansberry> plus, they can register with that service for notifications <bstansberry> register an impl of some listener API <maeste> oki <bstansberry> then if there is a change after boot, the core OSH that handles that change invokes a method on the service, which notifies <bstansberry> gets back a result, e.g. if restart is required, or OFE or something <bstansberry> that results in zero changes to any subsystem that can't actually handle an extension property <maeste> ok, but in that way properties can' change rutime, right? <maeste> *can't <bstansberry> maeste: yeah, they can <bstansberry> the core OSH invokes a method on this service <bstansberry> which in turn notifies any registered subsystem listeners <maeste> bstansberry: oki, so it will be the listener to handle changes. ok I've got you * bstansberry recognizes that is far from completely thought through!!! <bstansberry> maeste: we could do much the same thing with system properties though <maeste> bstansberry: putting this service in the middle <bstansberry> right <bstansberry> except... <maeste> bstansberry: yup I was thinking the same thing...except scope <bstansberry> pushing notifications for system properties bypasses the JDK security checks -- 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