September 2012 - jboss-dev-forums

[JBoss AS 7 Development] - Single Installation Patching

by Emanuel Muckenhuber

Emanuel Muckenhuber [https://community.jboss.org/people/emuckenhuber] modified the document: "Single Installation Patching" To view the document, visit: https://community.jboss.org/docs/DOC-47500 -------------------------------------------------------------- This article outlines design notes for the single instance patching feature being developed for AS 7.2. The 7.2 version of the feature will be apply to apply a patch to a single installation of the AS (i.e. a single unzip of the AS distribution.) That single installation may be being used for a standalone server or for a managed domain Host Controller and servers. However, the 7.2 version will not support coordinated patching by the patching tool of multiple installation in a managed domain. The user can of course independently patch multiple installation in a domain, coordinating the application of those patches themselves. The basic patching process will consist of: 1. The user obtains a patch file. 2. The user uses the CLI tool to connect to a standalone server or Host Controller that is running on the installation that is to be patched.1. The server or Host Controller may be running in admin-only mode or running normally. However, some patches may not be able to be applied if the target process isn't running in admin-only mode 3. The user invokes a command on the CLI providing the location of the patch file. The CLi invokes an operation(s) on the target process telling it to stage the patch. 4. The target process stages the patch by applying the patch contents to the filesystem.1. The changes made to the filesystem during staging should not affect the running operation of the server. If this is not possible, the server should reject the patch with an error message indicating that it needs to be placed in admin-only mode before applying the patch. 5. The user uses the CLI tool to restart the target process. Upon restart the staged patch is visible in the runtime. Patches can also be rolled back: 1. The user can use the CLI tool to instruct the target process to revert a patch. 2. Patch reversion results in changes to the filesystem that are staged in the same manner as what is done with a patch installation.1. The changes made to the filesystem during patch rollback staging should not affect the running operation of the server. If this is not possible, the server should reject the patch rollback with an error message indicating that it needs to be placed in admin-only mode before rolling back the patch. 3. The user uses the CLI tool to restart the target process. Upon restart the rolled back patch is no longer visible in the runtime. h1. Patch File A patch file is a zip archive that contains a patch.xml file that is used to describe the patch along with the updated modules, OSGi bundles and miscellaneous files that comprise the patch. It's structure is as follows: + META-INF ++ patch.xml + modules ++ patch modules in the same structure as they appear the modules dir in the normal AS dist + bundles ++ patch bundles in the same structure as they appear the bundles dir in the normal AS dist + misc ++ misc files that need to be updated, organized in a directory structure that matches the directory structure of the AS dist h3. The patch.xml File The patch.xml file describes the patch. It includes basic information about the patch along with metadata about the modules, bundles and misc files in the patch. h5. Basic patch metadata * The name of the patch * The type of the patch (one-off vs cumulative, etc -- TODO list all) * The version to which the patch applies * A text description of the patch * TODO others h5. Module metadata * The name of the module * The slot of the module * The hash of the module.xml file of the previous version of the module. Not present if the relevant module did not exist in the version being patched. h5. Removed module metadata Identifies modules that were available in the version being patched but which should no longer be accessible once the patch is applied * The name of the removed module * The slot of the removed module h5. Bundle metadata * TODO anything? h5. Removed bundle metadata Identifies bundles that were available in the version being patched but which should no longer be accessible once the patch is applied * The name of the removed bundle h5. Misc file metadata * The path of the misc file, relative to the root of the AS distribution * The hash of the version of the file that was in the version being patched. Not present if the relevant file did not exist in the version being patched. * A boolean indicator as to whether the file is in active use by a non-admin-mode Host Controller or server h5. Removed misc file metadata Identifies misc files that were available in the version being patched but which should no longer be accessible once the patch is applied * The path of the misc file, relative to the root of the AS distribution * A boolean indicator as to whether the file is in active use by a non-admin-mode Host Controller or server h2. Patch Staging The target process when it applies a patch will create a patches directory directly underneath the root of the AS distribution. As with other directories, the location of this directory can be controlled via a system property passed to the JVM at process launch. Before patch staging begins, a check is made as to whether the target process is in admin-only mode. If it is not, and an unresolvable conflict is detected between a module, bundle or miscellaneous file contained in the patch and a user-modification of the corresponding item in the installation being patched, the patch staging process will be aborted with an error message. See "Patch Conflict Detection" below. h4. Modules Patch modules will be staged by copying them to a patch-specific subdirectory of the patches directory. Information about the location of this directory will be stored in a location visible to the module loader used by JBoss Modules at boot. This patch-specific subdirectory is not visible to the module loader currently in use by the target process. TODO describe check for user-modified modules. Information about removed modules will also be stored in a location visible to the boot module loader at next boot. h4. Bundles Patch bundes will be staged by copying them to a patch-specific subdirectory of the patches directory. This patch-specific subdirectory is not visible to the OSGi subsystem currently in use by the target process. Information about removed bundles will also be stored in a location visible to the OSGi subsystem at next boot. h4. Misc files Misc files are staged by copying them directly to their normal location on the filesystem. A copy of the existing file at that location will be stored in the patch-specific subdirectory of the patches directory. TODO describe check for user-modified misc files. h4. Configuration files Patches will not modify the configuration files of the target process. Configuration patching will not be supported in this version of the feature (and may never be supported.) Configuration files belong to the user. However, a copy of all existing configuration files will be made in a patch-specific subdirectory of the patches directory. During patch rollback, these configuration files will be restored. This backup is necessary because once the patch is applied to the runtime, any management operation that results in persistence of the configuration will use the xml schemas associated with the patched version of the core AS and any subsystems. If the patch is reverted, those schemas may not be intelligible to the version of the code to which the runtime has been reverted. h2. Patch Application TODO h2. Rollback Staging To do a patch rollback, the target process must be placed in admin-only mode. TODO h4. Modules TODO h4. Bundles TODO h4. Misc Files The backup copies of the miscellaneous files stored during the "Patch Staging" process will be restored to their normal locations. Any misc files that were added as part of the "Patch Staging" process (i.e. those that were new in the patch) will be removed. TODO h4. Configuration The backup copies of the configuration files stored during the "Patch Staging" process will be restored. *+Any configuration changes made while the patch was in place will be lost.+* TODO h2. Rollback Application TODO Issue: the client tool (i.e. CLI) may need to be able to roll back a patch itself, not relying on the target process to do it. This is because a failed patch may leave the target process in a state such that it is unable to respond to commands from the CLI. This capability will not work remotely -- the CLI process will need to be running on the same machine as the installation being patched, and running under a user account with the necessary filesystem permissions to update the filesystem. h2. Patch Conflict Detection At the beginning of the patch staging process, a check will be made for conflicts between the patch and any user modifications to the same item. The user when executing the patch command can provide information to guide the tool in resolving conflicts. Any conflicts that cannot be resolved will result in the patch staging being aborted with no changes to the filesystem. Conflict types are: * Modules. If the patch is updating an existing module, the patch.xml file will include the hash of the existing module's module.xml file. The patching process will hash the current module.xml file to check for modifications. If any affected module is found to have been modified, the patch command will have to have been provided with a parameter indicating that "overriding" modified modules is ok. No option will be given to optionally override some modules and leave others unmodified. If the user wishes to retain some modification they made to module.xml, they will need to make an equivalent change to the module.xml in the patch module. The sole purpose of this "module conflict detection" is to provide information to users. * Bundles: TODO * Misc files: If the patch is updating an existing misc file, the patch.xml file will include the hash of the existing ile. The patching process will hash the current file to check for modifications. If any affected file is found to have been modified, the patch command will have to have been provided with a permission indicating that "overriding" modified modules is ok. These permissions can come in two forms:* A global permission to update all misc files, provided as a param to the CLI tools patching command * A file containing a list of paths (relative to $JBOSS_HOME) for which update permission is granted. The patching feature will also include a command that can apply this conflict detection process and provide a report of conflicts. Users can use this command to check for conflicts in advance. TODO describe how this will work for patch rollback. h2. Patch Generation Tool * Accepts basic metadata along with the location of a distribution of the new version along with a distribution of the old version* Also includes details on any misc files that are expected to be in active use * Generates a patch.xml file * Can generate a full patch file * Optional: Can be run from inside the bin/ dir of the full distribution of the new version and if provided with the patch.xml file can generate a patch file from the contents of the full dist* Idea here is the patch.xml file could be distributed as part of the new version and the user could use it to generate patch h3. *Directory structure* ${JBOSS_HOME} | |-- bin |-- bundles | `-- org/jboss/as/osgi |-- docs |-- modules | |-- org/jboss/as/... | `-- org/jboss/as/server/main/module.xml |-- patches (overlay directory) | |-- patch01 | | |-- bundles | | | `-- org/jboss/as/osgi/configadmin/main | | `-- modules | | | `-- org/jboss/as/server/main/module.xml | |-- patch02 | | |-- bundles | | | `-- org/jboss/as/osgi/configadmin/main | | `-- modules | | | `-- org/jboss/as/server/main/module.xml | `-- .metadata | |-- cumulative (links to given patchId) | |-- references [patch01, patch02] (list of one-off patches ) | `-- history (rollback information for a patch) | |-- patch01 | | |-- cumulative (previous cp) | | `-- misc | `-- patch02 | |-- cumulative (previous cp) | `-- misc | |-- jboss-modules.jar `-- loader.jar (boot module-loader) -------------------------------------------------------------- Comment by going to Community [https://community.jboss.org/docs/DOC-47500] Create a new document in JBoss AS 7 Development at Community [https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]

11 years, 7 months

1
0
0 / 0

Re: [jboss-dev-forums] [JBoss AS 7 Development] - Single Installation Patching

by Brian Stansberry

Brian Stansberry [https://community.jboss.org/people/brian.stansberry] commented on the document "Single Installation Patching" To view all comments on this document, visit: https://community.jboss.org/docs/DOC-47500#comment-10766 -------------------------------------------------- Yes, I want to support some side operations to report on patching history. Exactly what, TBD. :) Re: attaching .cli files for pre/post action, can you file a feature request JIRA? I like the idea. I have my doubts it will make it in the first iteration of this feature, but you never know, and in any case I think it's a very good idea. --------------------------------------------------

11 years, 7 months

1
0
0 / 0

[JBoss AS 7 Development] - Single Installation Patching

by Brian Stansberry

Brian Stansberry [https://community.jboss.org/people/brian.stansberry] modified the document: "Single Installation Patching" To view the document, visit: https://community.jboss.org/docs/DOC-47500 -------------------------------------------------------------- This article outlines design notes for the single instance patching feature being developed for AS 7.2. The 7.2 version of the feature will be apply to apply a patch to a single installation of the AS (i.e. a single unzip of the AS distribution.) That single installation may be being used for a standalone server or for a managed domain Host Controller and servers. However, the 7.2 version will not support coordinated patching by the patching tool of multiple installation in a managed domain. The user can of course independently patch multiple installation in a domain, coordinating the application of those patches themselves. The basic patching process will consist of: 1. The user obtains a patch file. 2. The user uses the CLI tool to connect to a standalone server or Host Controller that is running on the installation that is to be patched.1. The server or Host Controller may be running in admin-only mode or running normally. However, some patches may not be able to be applied if the target process isn't running in admin-only mode 3. The user invokes a command on the CLI providing the location of the patch file. The CLi invokes an operation(s) on the target process telling it to stage the patch. 4. The target process stages the patch by applying the patch contents to the filesystem.1. The changes made to the filesystem during staging should not affect the running operation of the server. If this is not possible, the server should reject the patch with an error message indicating that it needs to be placed in admin-only mode before applying the patch. 5. The user uses the CLI tool to restart the target process. Upon restart the staged patch is visible in the runtime. Patches can also be rolled back: 1. The user can use the CLI tool to instruct the target process to revert a patch. 2. Patch reversion results in changes to the filesystem that are staged in the same manner as what is done with a patch installation.1. The changes made to the filesystem during patch rollback staging should not affect the running operation of the server. If this is not possible, the server should reject the patch rollback with an error message indicating that it needs to be placed in admin-only mode before rolling back the patch. 3. The user uses the CLI tool to restart the target process. Upon restart the rolled back patch is no longer visible in the runtime. h1. Patch File A patch file is a zip archive that contains a patch.xml file that is used to describe the patch along with the updated modules, OSGi bundles and miscellaneous files that comprise the patch. It's structure is as follows: + META-INF ++ patch.xml + modules ++ patch modules in the same structure as they appear the modules dir in the normal AS dist + bundles ++ patch bundles in the same structure as they appear the bundles dir in the normal AS dist + misc ++ misc files that need to be updated, organized in a directory structure that matches the directory structure of the AS dist h3. The patch.xml File The patch.xml file describes the patch. It includes basic information about the patch along with metadata about the modules, bundles and misc files in the patch. h5. Basic patch metadata * The name of the patch * The type of the patch (one-off vs cumulative, etc -- TODO list all) * The version to which the patch applies * A text description of the patch * TODO others h5. Module metadata * The name of the module * The slot of the module * The hash of the module.xml file of the previous version of the module. Not present if the relevant module did not exist in the version being patched. h5. Removed module metadata Identifies modules that were available in the version being patched but which should no longer be accessible once the patch is applied * The name of the removed module * The slot of the removed module h5. Bundle metadata * TODO anything? h5. Removed bundle metadata Identifies bundles that were available in the version being patched but which should no longer be accessible once the patch is applied * The name of the removed bundle h5. Misc file metadata * The path of the misc file, relative to the root of the AS distribution * The hash of the version of the file that was in the version being patched. Not present if the relevant file did not exist in the version being patched. * A boolean indicator as to whether the file is in active use by a non-admin-mode Host Controller or server h5. Removed misc file metadata Identifies misc files that were available in the version being patched but which should no longer be accessible once the patch is applied * The path of the misc file, relative to the root of the AS distribution * A boolean indicator as to whether the file is in active use by a non-admin-mode Host Controller or server h2. Patch Staging The target process when it applies a patch will create a patches directory directly underneath the root of the AS distribution. As with other directories, the location of this directory can be controlled via a system property passed to the JVM at process launch. Before patch staging begins, a check is made as to whether the target process is in admin-only mode. If it is not, and an unresolvable conflict is detected between a module, bundle or miscellaneous file contained in the patch and a user-modification of the corresponding item in the installation being patched, the patch staging process will be aborted with an error message. See "Patch Conflict Detection" below. h4. Modules Patch modules will be staged by copying them to a patch-specific subdirectory of the patches directory. Information about the location of this directory will be stored in a location visible to the module loader used by JBoss Modules at boot. This patch-specific subdirectory is not visible to the module loader currently in use by the target process. TODO describe check for user-modified modules. Information about removed modules will also be stored in a location visible to the boot module loader at next boot. h4. Bundles Patch bundes will be staged by copying them to a patch-specific subdirectory of the patches directory. This patch-specific subdirectory is not visible to the OSGi subsystem currently in use by the target process. Information about removed bundles will also be stored in a location visible to the OSGi subsystem at next boot. h4. Misc files Misc files are staged by copying them directly to their normal location on the filesystem. A copy of the existing file at that location will be stored in the patch-specific subdirectory of the patches directory. TODO describe check for user-modified misc files. h4. Configuration files Patches will not modify the configuration files of the target process. Configuration patching will not be supported in this version of the feature (and may never be supported.) Configuration files belong to the user. However, a copy of all existing configuration files will be made in a patch-specific subdirectory of the patches directory. During patch rollback, these configuration files will be restored. This backup is necessary because once the patch is applied to the runtime, any management operation that results in persistence of the configuration will use the xml schemas associated with the patched version of the core AS and any subsystems. If the patch is reverted, those schemas may not be intelligible to the version of the code to which the runtime has been reverted. h2. Patch Application TODO h2. Rollback Staging To do a patch rollback, the target process must be placed in admin-only mode. TODO h4. Modules TODO h4. Bundles TODO h4. Misc Files The backup copies of the miscellaneous files stored during the "Patch Staging" process will be restored to their normal locations. Any misc files that were added as part of the "Patch Staging" process (i.e. those that were new in the patch) will be removed. TODO h4. Configuration The backup copies of the configuration files stored during the "Patch Staging" process will be restored. *+Any configuration changes made while the patch was in place will be lost.+* TODO h2. Rollback Application TODO Issue: the client tool (i.e. CLI) may need to be able to roll back a patch itself, not relying on the target process to do it. This is because a failed patch may leave the target process in a state such that it is unable to respond to commands from the CLI. This capability will not work remotely -- the CLI process will need to be running on the same machine as the installation being patched, and running under a user account with the necessary filesystem permissions to update the filesystem. h2. Patch Conflict Detection At the beginning of the patch staging process, a check will be made for conflicts between the patch and any user modifications to the same item. The user when executing the patch command can provide information to guide the tool in resolving conflicts. Any conflicts that cannot be resolved will result in the patch staging being aborted with no changes to the filesystem. Conflict types are: * Modules. If the patch is updating an existing module, the patch.xml file will include the hash of the existing module's module.xml file. The patching process will hash the current module.xml file to check for modifications. If any affected module is found to have been modified, the patch command will have to have been provided with a parameter indicating that "overriding" modified modules is ok. No option will be given to optionally override some modules and leave others unmodified. If the user wishes to retain some modification they made to module.xml, they will need to make an equivalent change to the module.xml in the patch module. The sole purpose of this "module conflict detection" is to provide information to users. * Bundles: TODO * Misc files: If the patch is updating an existing misc file, the patch.xml file will include the hash of the existing ile. The patching process will hash the current file to check for modifications. If any affected file is found to have been modified, the patch command will have to have been provided with a permission indicating that "overriding" modified modules is ok. These permissions can come in two forms:* A global permission to update all misc files, provided as a param to the CLI tools patching command * A file containing a list of paths (relative to $JBOSS_HOME) for which update permission is granted. The patching feature will also include a command that can apply this conflict detection process and provide a report of conflicts. Users can use this command to check for conflicts in advance. TODO describe how this will work for patch rollback. h2. Patch Generation Tool * Accepts basic metadata along with the location of a distribution of the new version along with a distribution of the old version* Also includes details on any misc files that are expected to be in active use * Generates a patch.xml file * Can generate a full patch file * Optional: Can be run from inside the bin/ dir of the full distribution of the new version and if provided with the patch.xml file can generate a patch file from the contents of the full dist* Idea here is the patch.xml file could be distributed as part of the new version and the user could use it to generate patch -------------------------------------------------------------- Comment by going to Community [https://community.jboss.org/docs/DOC-47500] Create a new document in JBoss AS 7 Development at Community [https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]

11 years, 7 months

1
0
0 / 0

Community Updates, September 20 - September 27

by JBoss Community

=============================================================== Community Updates for September 20 - September 27 =============================================================== You haven't set a status update. Log in and set your status at: https://community.jboss.org. Your Content * testing the new list server [https://community.jboss.org/thread/127309] was viewed 13,189 times and replied to by 3 people * No Link to Jboss Nukes [https://community.jboss.org/thread/90785] was viewed 111,418 times and replied to by 3 people Your Connections - Activity by people you are following You don't have any connections yet. Find people and connect! [https://community.jboss.org/people/] Popular Content - The content that is most viewed and participated in * Open Session in View [https://community.jboss.org/docs/DOC-13954] * Sessions and transactions [https://community.jboss.org/docs/DOC-13951] * Data Source Configuration in AS 7 [https://community.jboss.org/docs/DOC-16657] * JBoss Tools 3.3 and Developer Studio 5.0 Final Release! [https://community.jboss.org/community/tools/blog/2012/06/21/jboss-tools-3...] * JBoss Tools 4 [https://community.jboss.org/community/tools/blog/2012/09/17/the-return-of...] * Spring and JBoss AS7 (Part 1) : Getting Started [https://community.jboss.org/blogs/mariusb/2011/07/13/spring-and-jboss-as7...] * Re: java.net.BindException: Address already in use: JVM_Bind [https://community.jboss.org/message/747101#747101] * Re: Jboss 7.1.2.Final is only for EAP? [https://community.jboss.org/message/761730#761730] * Re: HTTPS on JBoss AS 7 - truststore configuration [https://community.jboss.org/message/746287#746287] Tips and tricks - Reply Using Email Stuck without web access? In a hurry? You can respond to Community discussions by using the reply feature of your email client. Just reply to the email notification that you'd like to respond to, type up your reply, and hit send. Your reply will show up in Community momentarily. Find out more. Not interested in these emails anymore, or want to change how often they come? Update your email preferences by visiting: https://community.jboss.org/user-notification-preferences!input.jspa

11 years, 7 months

1
0
0 / 0

[jBPM Development] - Query regarding assignment of multiple users(comma seperated) to a user task node

by Sachin Chandra

Sachin Chandra [https://community.jboss.org/people/chandrasachin16] created the discussion "Query regarding assignment of multiple users(comma seperated) to a user task node" To view the discussion, visit: https://community.jboss.org/message/761924#761924 -------------------------------------------------------------- I had a query regarding assignment of users to a user task node in aprocess . The document at this url http://docs.jboss.org/jbpm/v5.3/userguide/ch.human-tasks.html http://docs.jboss.org/jbpm/v5.3/userguide/ch.human-tasks.html says we can use comma seperated users in ActorId field if we want a particular user task node to be executed by multiple users. I tried with the same (using a comma) ActorId as (krisv,mary) but to my surprise now both the users are unable to execute the node .I tried to login with both the users but none of the users are able to execute the user task node. Can anybody who has tried this help me out. Regards Sachin -------------------------------------------------------------- Reply to this message by going to Community [https://community.jboss.org/message/761924#761924] Start a new discussion in jBPM Development at Community [https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]

11 years, 7 months

1
0
0 / 0

Re: [jboss-dev-forums] [JBoss AS 7 Development] - Single Installation Patching

by Nicklas Karlsson

Nicklas Karlsson [https://community.jboss.org/people/nickarls] commented on the document "Single Installation Patching" To view all comments on this document, visit: https://community.jboss.org/docs/DOC-47500#comment-10760 -------------------------------------------------- Sounds like a nice feature. Will the CLI also a provide a list of "Patch, status, when applied"? I assume you can also attach .cli files for execution (pre-and-post actions)? --------------------------------------------------

11 years, 7 months

1
0
0 / 0

[JBoss AS 7 Development] - Single Installation Patching

by Brian Stansberry

Brian Stansberry [https://community.jboss.org/people/brian.stansberry] modified the document: "Single Installation Patching" To view the document, visit: https://community.jboss.org/docs/DOC-47500 -------------------------------------------------------------- This article outlines design notes for the single instance patching feature being developed for AS 7.2. The 7.2 version of the feature will be apply to apply a patch to a single installation of the AS (i.e. a single unzip of the AS distribution.) That single installation may be being used for a standalone server or for a managed domain Host Controller and servers. However, the 7.2 version will not support coordinated patching by the patching tool of multiple installation in a managed domain. The user can of course independently patch multiple installation in a domain, coordinating the application of those patches themselves. The basic patching process will consist of: 1. The user obtains a patch file. 2. The user uses the CLI tool to connect to a standalone server or Host Controller that is running on the installation that is to be patched.1. The server or Host Controller may be running in admin-only mode or running normally. However, some patches may not be able to be applied if the target process isn't running in admin-only mode 3. The user invokes a command on the CLI providing the location of the patch file. The CLi invokes an operation(s) on the target process telling it to stage the patch. 4. The target process stages the patch by applying the patch contents to the filesystem.1. The changes made to the filesystem during staging should not affect the running operation of the server. If this is not possible, the server should reject the patch with an error message indicating that it needs to be placed in admin-only mode before applying the patch. 5. The user uses the CLI tool to restart the target process. Upon restart the staged patch is visible in the runtime. Patches can also be rolled back: 1. The user can use the CLI tool to instruct the target process to revert a patch. 2. Patch reversion results in changes to the filesystem that are staged in the same manner as what is done with a patch installation.1. The changes made to the filesystem during patch rollback staging should not affect the running operation of the server. If this is not possible, the server should reject the patch rollback with an error message indicating that it needs to be placed in admin-only mode before rolling back the patch. 3. The user uses the CLI tool to restart the target process. Upon restart the rolled back patch is no longer visible in the runtime. h1. Patch File A patch file is a zip archive that contains a patch.xml file that is used to describe the patch along with the updated modules, OSGi bundles and miscellaneous files that comprise the patch. It's structure is as follows: + META-INF ++ patch.xml + modules ++ patch modules in the same structure as they appear the modules dir in the normal AS dist + bundles ++ patch bundles in the same structure as they appear the bundles dir in the normal AS dist + misc ++ misc files that need to be updated, organized in a directory structure that matches the directory structure of the AS dist h3. The patch.xml File The patch.xml file describes the patch. It includes basic information about the patch along with metadata about the modules, bundles and misc files in the patch. h5. Basic patch metadata * The name of the patch * The type of the patch (one-off vs cumulative, etc -- TODO list all) * The version to which the patch applies * A text description of the patch * TODO others h5. Module metadata * The name of the module * The slot of the module * The hash of the module.xml file of the previous version of the module. Not present if the relevant module did not exist in the version being patched. h5. Removed module metadata Identifies modules that were available in the version being patched but which should no longer be accessible once the patch is applied * The name of the removed module * The slot of the removed module h5. Bundle metadata * TODO anything? h5. Removed bundle metadata Identifies bundles that were available in the version being patched but which should no longer be accessible once the patch is applied * The name of the removed bundle h5. Misc file metadata * The path of the misc file, relative to the root of the AS distribution * The hash of the version of the file that was in the version being patched. Not present if the relevant file did not exist in the version being patched. * A boolean indicator as to whether the file is in active use by a non-admin-mode Host Controller or server h5. Removed misc file metadata Identifies misc files that were available in the version being patched but which should no longer be accessible once the patch is applied * The path of the misc file, relative to the root of the AS distribution * A boolean indicator as to whether the file is in active use by a non-admin-mode Host Controller or server h2. Patch Staging The target process when it applies a patch will create a patches directory directly underneath the root of the AS distribution. As with other directories, the location of this directory can be controlled via a system property passed to the JVM at process launch. Before patch staging begins, a check is made as to whether the target process is in admin-only mode. If it is not, and h4. Modules Patch modules will be staged by copying them to a patch-specific subdirectory of the patches directory. Information about the location of this directory will be stored in a location visible to the module loader used by JBoss Modules at boot. This patch-specific subdirectory is not visible to the module loader currently in use by the target process. TODO describe check for user-modified modules. Information about removed modules will also be stored in a location visible to the boot module loader at next boot. h4. Bundles Patch bundes will be staged by copying them to a patch-specific subdirectory of the patches directory. This patch-specific subdirectory is not visible to the OSGi subsystem currently in use by the target process. Information about removed bundles will also be stored in a location visible to the OSGi subsystem at next boot. h4. Misc files Misc files are staged by copying them directly to their normal location on the filesystem. A copy of the existing file at that location will be stored in the patch-specific subdirectory of the patches directory. TODO describe check for user-modified misc files. h2. Patch Application TODO h2. Rollback Staging TODO h2. Rollback Application TODO h2. Patch Generation Tool * Accepts basic metadata along with the location of a distribution of the new version along with a distribution of the old version* Also includes details on any misc files that are expected to be in active use * Generates a patch.xml file * Can generate a full patch file * Optional: Can be run from inside the bin/ dir of the full distribution of the new version and if provided with the patch.xml file can generate a patch file from the contents of the full dist* Idea here is the patch.xml file could be distributed as part of the new version and the user could use it to generate patch -------------------------------------------------------------- Comment by going to Community [https://community.jboss.org/docs/DOC-47500] Create a new document in JBoss AS 7 Development at Community [https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]

11 years, 7 months

1
0
0 / 0

[jBPM Development] - interactions

by Leo C

Leo C [https://community.jboss.org/people/koorio] created the discussion "interactions" To view the discussion, visit: https://community.jboss.org/message/761648#761648 -------------------------------------------------------------- Hi everyone if I have a jBPM project and a web app (JSPs, for example) is there a way to make them interact without web services? Thanks all for your time Best regards Leo -------------------------------------------------------------- Reply to this message by going to Community [https://community.jboss.org/message/761648#761648] Start a new discussion in jBPM Development at Community [https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]

11 years, 7 months

1
0
0 / 0

[JBoss Transactions Development] - Narayana Release Process

by Tom Jenkinson

Tom Jenkinson [https://community.jboss.org/people/tomjenkinson] modified the document: "Narayana Release Process" To view the document, visit: https://community.jboss.org/docs/DOC-17433 -------------------------------------------------------------- This page provides a list of instructions that must be done *in order* when doing a release of Narayana. h2. Check JIRA Ensure all issues are resolved. Any outstanding issues must be pushed back or resolved. h2. Check Hudson Ensure no test failures in the following group of hudson tests (for the branch you intend to release): * 4.16 Branch : jbossts-branch416-* * 4.17 Branch : jbossts-branch417-* * 5 Branch: jbossts-narayana-* h2. Do Release h3. Release Quickstarts and Docs Must be done first as the build-release-packages.xml relies on the tag being available # Similar steps apply to both Quickstarts and Docs current='4$[._]$17$[._]$0$[._]$Final-SNAPSHOT' next='4\117\20\3Final' find . -name \*.java -o -name \*.xml -o -name \*.properties -o -name \*.ent -o -name \INSTALL -o -name \README | grep -v ".svn" | grep -v ".git" | grep -v target | xargs sed -i "s/"$current"/"$next"/" git commit -am "Updated to $next" git tag 4.17.0.Final current='4$[._]$17$[._]$0$[._]$Final' next='5\10\20\3M2-SNAPSHOT' find . -name \*.java -o -name \*.xml -o name \*.properties -o -name \*.ent -o -name \INSTALL -o -name \README | grep -v ".svn" | grep -v ".git" | grep -v target | xargs sed -i "s/"$current"/"$next"/" git push upstream master --tags h3. svn branches #Make sure your checkout has no local changes svn update svn status POINT_VERSION=5 NEXT_POINT_VERSION=6 #Update the version in text files find . -name \*.java -o -name \*.xml -o name \*.properties -o -name \*.ent -o -name \INSTALL -o -name \README | grep -v ".svn" | grep -v target | xargs grep -l "4[._]16" | xargs sed -i "s/4$[._]$16$[._]$${POINT_VERSION}$[._]$Final-SNAPSHOT/4\116\2$POINT_VERSION\3Final/" svn commit -m "Updated to version 4.16.$POINT_VERSION.Final" #Tag the release: svn cp https://svn.jboss.org/repos/labs/labs/jbosstm/branches/JBOSSTS_4_16 https://svn.jboss.org/repos/labs/labs/jbosstm/tags/JBOSSTS_4_16_${POINT_V... -m "4.16.$POINT_VERSION" #Bump to next version using similar find to above find . -name \*.java -o -name \*.xml -o name \*.properties -o -name \*.ent -o -name \INSTALL -o -name \README | grep -v ".svn" | grep -v target | xargs grep -l "4[._]16" | xargs sed -i "s/4$[._]$16$[._]$${POINT_VERSION}$[._]$Final/4\116\2${NEXT_POINT_VERSION}\3Final-SNAPSHOT/" svn commit -m "Updated to version 4.16.${NEXT_POINT_VERSION}.Final-SNAPSHOT" #Update the maven version of jbossts in our fork of JBossAS: https://github.com/jbosstm/jboss-as git checkout 4_16_BRANCH git pull --rebase --ff-only #Check no local changes git status sed -i "s/4.16.${POINT_VERSION}.Final-SNAPSHOT/4.16.${NEXT_POINT_VERSION}.Final-SNAPSHOT/g" pom.xml git commit -am "Updated to 4.16.${NEXT_POINT_VERSION}.Final-SNAPSHOT" git push #Build and deploy the release to nexus staging: mkdir ~/filemgmt.jboss.org/ sshfs jbosstm(a)filemgmt.jboss.org: ~/filemgmt.jboss.org/ ant -f build-release-pkgs.xml dist mvn-repository downloads magnolia h5. h3. git branches #Make sure your checkout has no local changes git checkout master git status #Pull remote changes git fetch git reset --hard upstream/master #Update the version in text files and tag and push the release CHANGE: current='4$[._]$17$[._]$0$[._]$Final-SNAPSHOT' next='4\117\20\3Final' find . -name \*.java -o -name \*.xml -o name \*.properties -o -name \*.ent -o -name \INSTALL -o -name \README | grep -v ".svn" | grep -v ".git" | grep -v target | xargs sed -i "s/"$current"/"$next"/" git commit -am "Updated to $next" git tag 4.17.0.Final git push upstream master git push upstream --tags #Bump to next version using similar find to above CHANGE: current='4$[._]$17$[._]$0$[._]$Final' next='5\10\20\3M2-SNAPSHOT' find . -name \*.java -o -name \*.xml -o name \*.properties -o -name \*.ent -o -name \INSTALL -o -name \README | grep -v ".svn" | grep -v ".git" | grep -v target | xargs sed -i "s/"$current"/"$next"/" git push upstream master #Update the maven version of jbossts in our fork of JBossAS: https://github.com/jbosstm/jboss-as git clone -o jbosstm https://github.com/jbosstm/jboss-as git checkout 5_BRANCH sed -i "s/5.0.0.M1-SNAPSHOT/5.0.0.M2-SNAPSHOT/g" pom.xml git commit -am "Updated to 5.0.0.M2-SNAPSHOT" git push jbosstm 5_BRANCH #Build and deploy the release to nexus staging: mkdir ~/narayana/filemgmt.jboss.org/ sshfs jbosstm(a)filemgmt.jboss.org: ~/narayana/filemgmt.jboss.org/ ant -f build-release-pkgs.xml dist downloads docs magnolia h2. Release the artifact through Nexus 1. https://repository.jboss.org/nexus/index.html#welcome https://repository.jboss.org/nexus/index.html#welcome 2. login 3. "Staging Repositories" 4. Click tickbox for your repo 5. Click "Close" 6. Don't worry about a description, just click "Close" 7. Click tickbox after it is closed 8. Click "Release" 9. Again a description doesn't matter h2. JIRA Release 1. Check all issues resolved. 2. Create next point release version if not exists - this is so you can push issues in step 3 below. 3. Unresolved issues should be resolved or pushed. 4. Close all issues for the release 5. Mark as released (Need admin permissions) h2. Update Website Update the Narayana community site: * Login to Magnolia* https://www.jboss.org/author/.magnolia/pages/adminCentral.html https://www.jboss.org/author/.magnolia/pages/adminCentral.html * Login with credentials: Tom and Paul know these, ask them. * Documentation* Browse to 'jbosstm/documentation' * right click on 'downloads' and select 'import' * browse to the location of the 'website.jbosstm.documentation.4.16.5.Final.xml' file * Right click on the new file and click 'move' * Drag the file to the top of the documentation list. * Right click on the new page and select 'open page...' * Check that the page looks right and that the download links work * Right click on the new page and select 'activate' * You now need to wait for the page to be moderated before it will appear. * Downloads* Browse to 'jbosstm/downloads' * right click on 'downloads' and select 'import' * browse to the location of the 'website.jbosstm.downloads.4.16.5.Final.xml' file * Right click on the new file and click 'move' * Drag the file to the top of the downloads list. * Right click on the new page and select 'open page...' * Check that the page looks right and that the download links work * Right click on the new page and select 'activate' * You now need to wait for the page to be moderated before it will appear. * Announcement* Right click on 'jbosstm' and select 'open page...' * Click edit on the 'announcement' pane * Update the announcement for this release. * Right click on 'jbosstm' and select 'activate changes' * You now need to wait for the page to be moderated before it will appear. * Release notes* Right click on 'jbosstm' and select 'open page...' * Click edit on the 'getting started' pane on the right-hand-side * Edit the release notes url to point to the release notes for this version * Click save * Right click on 'jbosstm' and select 'activate changes' * You now need to wait for the page to be moderated before it will appear. h2. Push Upstream If appropriate for this release, create a new 'component update' issue in AS7 JIRA. Ensure the module is set to 'transactions' and select an appropriate 'fix for'. Assign it to yourself Resolve the work and raise the pull request 1. https://issues.jboss.org/browse/AS7 https://issues.jboss.org/browse/AS7 2. cd AS source 3. git checkout -b AS7-<JIRANUMBER> 4. sed -i "s/4.16.3.Final/4.16.4.Final/g" pom.xml 5. git commit -am "AS7-<JIRA> Updated to 4.16.4.Final" 6. git push 7. Raise a pull request h2. Promote NOTE: It is worth waiting for the merge of the pull request before advertising, or at least wait for the merge build notification first ;) Promote the release through the following channels: 1. Email jbossts-announce(a)lists.jboss.org (mailto:jbossts-announce@lists.jboss.org) 2. Forum 3. Blog - as appropriate -------------------------------------------------------------- Comment by going to Community [https://community.jboss.org/docs/DOC-17433] Create a new document in JBoss Transactions Development at Community [https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]

11 years, 7 months

1
0
0 / 0

[PicketBox Development] - PicketBox Security Annotations

by Ondrej Zizka

Ondrej Zizka [https://community.jboss.org/people/ozizka] modified the document: "PicketBox Security Annotations" To view the document, visit: https://community.jboss.org/docs/DOC-14926 -------------------------------------------------------------- << https://community.jboss.org/docs/DOC-14744 Go Back to PicketBox Overview h3. Project: http://jboss.org/picketbox PicketBox *** #Project_PicketBox Project: PicketBox ** #SecurityDomain_Annotation @SecurityDomain Annotation ** #Authentication_Annotation @Authentication Annotation ** #Authorization_Annotation @Authorization Annotation ** #SecurityMapping_Annotation @SecurityMapping Annotation ** #SecurityAudit_Annotation @SecurityAudit Annotation ** #Module_Annotation @Module Annotation ** #ModuleOption_Annotation @ModuleOption Annotation ** #SecurityConfig_Annotation @SecurityConfig Annotation Here we describe the various security annotations available as part of PicketBox. h2. @SecurityDomain Annotation Fully Qualified Name: org.jboss.security.annotation.SecurityDomain It contains: * value: a name indicating the security domain. h2. @Authentication Annotation Fully Qualified Name: org.jboss.security.annotation.Authentication It contains: * modules: an array of @Module annotations. This is not optional. @Authentication(modules={@Module(code = UsersRolesLoginModule.class, options = {@ModuleOption})}) public class AuthenticationAnnotatedPOJO { } h2. h2. @Authorization Annotation Fully Qualified Name: org.jboss.security.annotation.Authorization It contains: * modules: an array of @Module annotations. This is not optional. @Authentication(modules={@Module(code = UsersRolesLoginModule.class, options = {@ModuleOption})}) @Authorization(modules ={@Module(code = PicketBoxAuthorizationModule.class, options = {@ModuleOption(key="roles",value="validuser")})}) public class AuthAuthorizationAnnotatedPOJO { } h2. h2. @SecurityMapping Annotation Fully Qualified Name: org.jboss.security.annotation.SecurityMapping It contains: * modules: an array of @Module annotations. This is not optional. @Authentication(modules = {@Module(code = UsersRolesLoginModule.class, options = {@ModuleOption})}) @SecurityMapping(modules = {@Module(code = OptionsRoleMappingProvider.class, type="role", options = {@ModuleOption(key="rolesMap",value="validuser=AuthorizedUser,InternalUser", valueType=VALUE_TYPE.JAVA_PROPERTIES), @ModuleOption(key="replaceRoles", value="false")})}) public class AuthPlusMappingAnnotatedPOJO { } h2. @SecurityAudit Annotation Fully Qualified Name: org.jboss.security.annotation.SecurityMapping It contains: * modules: an array of @Module annotations. This is not optional. @SecurityDomain(value="role-mapping-test") @SecurityAudit public class SecurityMappingAnnotationRolePOJO { } h2. @Module Annotation Fully Qualified Name: org.jboss.security.annotation.Module It contains: * code : the class of the module (Eg: UsersRolesLoginModule.class) This represents the JAAS login module for @Authentication, Policy Module for @Authorization, Mapping provider for @SecurityMapping and Audit Provider for @Audit * flag : one of (REQUIRED,REQUISITE,SUFFICIENT,OPTIONAL). Default, REQUIRED is assumed. This is the behavior defined in the JAAS configuration for login modules. (Optional) * type: an additional type value provided (mainly, for mapping modules). Default: "" (Optional) * options: an array of @ModuleOption annotations h2. h2. @ModuleOption Annotation Fully Qualified Name: org.jboss.security.annotation.ModuleOption It contains: * key : key of the option being passed to the module * value : value of the options being passed to the module * valueType : whether the value is a regular string or assumed as a Java properties. Default is plain string. h2. h2. @SecurityConfig Annotation Fully Qualified Name: org.jboss.security.annotation.ModuleOption It contains: * fileName: name of the xml config file that defines the security domain configuration << https://community.jboss.org/docs/DOC-14744 Go Back to PicketBox Overview -------------------------------------------------------------- Comment by going to Community [https://community.jboss.org/docs/DOC-14926] Create a new document in PicketBox Development at Community [https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]

11 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums September 2012