[Design of Management Features on JBoss] - JBAS-6689 add support for activation policy metadata on Mana
by charles.crouch＠jboss.com
Starting this thread to discuss how best to address the issues brought up in the http://jira.jboss.com/jira/browse/JBAS-6689. We can certainly discuss what we want to do in the future but I think the immediate priority is what can be done for the 5.1.CR1.
So starting off I'm not sure adding support for activation policy to the JBAS layer and the console is not practical in the current timeframe (Scott/Emanuel can you comment on the JBAS side?). Even if support was added to JBAS as Ian describes in 6689, there is currently no way for the console to indicate that value A of a property is whats currently running and value B is what will be running after a restart.
Looking at the troublesome properties...
11:11:42,488 WARN [QueueService] Clustered can only be changed when destination is stopped
11:11:42,488 WARN [QueueService] PageSize can only be changed when destination is stopped
11:11:42,488 WARN [QueueService] Cannot change the value of associated server's ObjectName after initialization!
11:11:42,488 WARN [QueueService] FullSize can only be changed when destination is stopped
11:11:42,488 WARN [QueueService] Cannot change the value of the JNDI name after initialization!
11:11:42,488 WARN [QueueService] DownCacheSize can only be changed when destination is stopped
>From the above its clear that JNDI name and ObjectName should be readonly from the console perspective. In addition having looked at http://jira.jboss.com/jira/browse/JBMESSAGING-1368
and http://jira.jboss.com/jira/browse/JBMESSAGING-1235 its clear that the "Clustered" property is effectively readonly too. [In fact it worse than that since you need to make updates to the JBM_POSTOFFICE table if you want to change this value, but making something readonly is about as far as we can go right now].
That leaves PageSize, FullSize and DownCacheSize properties which require the destination to be stopped in order for the change to be successfully applied. I don't think the current situation is tenable, i.e. a user tries to change the PageSize property when the queue is running and the profile service responds back with success and when the console queries the ManagedComponent its gets the new value, which does *not* reflect what is actually running in the JBAS instance.
I think the least that can be done here is to have the profile service return back failure from the update if the values we supplied it didn't actually get applied (Is it possible for the profile service to query the underlying component to check that the suggested updates have been applied?).
Further if I'm not changing PageSize, FullSize and DownCacheSize properties, but one of the properties which can be updated fine while the destination is running, then I should clearly not get any sort of warning or failure.
Regardless of what we ultimately end up doing in the short term I think the JBM1.4 destinations provide an excellent example of the sort of configurations we're going to need to support in the future.
Cheers
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4221699#4221699
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4221699
14 years
[Design of Management Features on JBoss] - Re: JBAS-6672, null values and defaults
by charles.crouch＠jboss.com
Ok, just to make sure we're all clear on the use cases the console needs to support, I've described them below. The *how* part, is up for more discussion.
1) user doesn't want to specify a particular value for a configuration property, they are happy to take the server default value (which itself may change over time).
So if todays default is 20, we can't store 20 as the value of the property, since tomorrow the default may be 30, and the user has specified that they wish to always take the server default, regardless of what that is.
2) the user wants to specify a particular value for a configuration property. This is the typical scenario, e.g. a user enters in the jndiName for a datasource.
3) user wants to explicitly specify that a value is empty for a configuration property, they don't want to user the server default. For example the server default for "new-connection-sql" on a Datsource could be ";". So if the user leaves that value unset thats what the Datasource will use, however if the user explicitly sets the value to null (or empty string) then they are saying they don't want any SQL run on new connections.
Thanks
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4221693#4221693
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4221693
14 years
[Design of JBoss Build System] - Build system goals
by pgier
Build System Goals
This is an attempt at setting a more well defined direction for the build system within JBoss. Up until now the goals of jboss builds have been vaguely defined as "reproducible builds" and "migrate to maven". So the goal is to first figure out what reproducible builds really means and create a clear direction by opening up the discussion. Hopefully this will get everyone on the same page and make it easier to understand why certain changes take place and how the small changes fit into the bigger picture.
Reproducible builds
Maven in general takes the approach that release builds need to be reproducible, and snapshot builds do not. It seems clear that being able to reproduce just release builds is not enough for the needs of the JBoss projects. It should be easy to track down any build, including snapshots and determine how they were built (what svn revision, maven version, java version, etc), and use this information to re-run the same build.
The ideal solution for this would allow a build to be run, on hudson for example, and deployed to the snapshots server. With nothing more than a pointer (url? artifact/groupId/version?) to the pom and the jar(s) on the snapshot server, Hudson should be able to re-run the same build using the same version of maven, java, the OS, and the same svn revision as the original build.
In order to accomplish this, the first thing that needs to be done is to record the necessary information during a build (MRELEASE-352). This should be done during an early stage (validate?) of the build. The information should then be recorded somewhere that it can later be accessed, possibly as a separate file, or possibly in the jar manifest. The svn revision can be gathered from the existing buildnumber-maven-plugin. The svn revision then becomes available through a property.
The second step involves changes to Hudson. Hudson would need the ability to read the build information and automatically set up an environment similar to what was used in the original build. Then the correct svn revision would be checked out and the project could be rebuilt. As a final step, Hudson would compare the generated artifacts to those in the repository and give information about whether they match.
Keeping dependencies up to date and in sync during development
There is a constant struggle to keep dependencies up to date while developing. The maven model of using snapshots has several problems, and doing tagged releases for every build is not practical. The ideal solution would allow the developer to easily choose between development snapshot dependencies and more stable release versions.
There is currently some work being done on the versions maven plugin that might help to make it a little easier to keep dependencies up to date. There is a goal to search for newer versions of dependencies and update the pom accordingly.
It would also be useful to be able to easily compare dependency versions between two projects (JBBUILD-512). This would allow component developers (ejb3 for example) to quickly compare the versions of their dependencies to those of another project such as JbossAS. In the future this type of feature might be integrated into IDE plugins.
Dependency Resolution
In order for builds to be completely reproducible, dependencies must be resolved in exactly the same way from one invocation to the next. This can be an issue when the artifacts are not ordered in the same way for each build. Maven is currently undergoing changes in its dependency resolution component. It is likely that changes in dependency resolution will continue for some time to come, so this requires that we must track what version of maven was used to build the application, and require that this same version be used to reproduce the same build.
Maven has limited support for version ranges, but it is not practical for the pom of a released project to include any version ranges. Because if the pom does contain ranges, then any change in the repository could mean a change in the build. So either a snapshot of the repository would have to be saved, or all ranges would have to be resolved to the actual version used.
Simple/reliable release process
The ideal solution would be to have two options available at any given time: a completely automated release using Hudson (or a local developer workstation when needed), or a more manual step by step process that allows the developer more fine grained control over the release process.
One of the problems with the current release plugin is that a "dryRun" release build is not exactly the same as a "prepare", and a "prepare"; build is not exactly the same as a "perform". And occasionally a successful dry run or prepare step can still result in a failed perform.
Comments/Feedback are welcome as always!
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4221642#4221642
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4221642
14 years