[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:
+ 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, or if the relevant file is a directory.
* A boolean indicator as to whether the relevant file is a directory.
* 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
* The hash of the version of the file that was in the version being patched. Not present if the relevant file is a directory.
* A boolean indicator as to whether the relevant file is a directory.
* 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
A patch is "applied" by stopping the target process and then restarting it in a normal manner; e.g. from the command line or by using the :shutdown(restart=true) command from the CLI. The patch contents that have been staged are then used by the restarted process.
h4. Modules
In 7.2 the AS will use a custom implementation of the JBoss Modules ModuleLoader interface, instead of the default implementation used in previous AS 7 releases. The selection of this custom implementation will be part of the launch VM command created by the startup scripts (i.e. standalone.sh/standalone.bat/domain.sh/domain.bat). The module loader works using a notion of a "module path", which is an ordered list of directories in which modules are located. When the module loader needs to find a module, it searches the directories in that path in order, and once it finds the desired module the search ends. Thus, directories earlier in the path listing take precedence over those found later. This is all very similar to how an OS uses the $PATH environment variable.
Previous AS7 releases allowed the user to specify a $JBOSS_MODULES_PATH environment variable to declare the "module path", with a default value of $JBOSS_HOME/modules used if not specified. The startup scripts used to the AS pass that module path into JBoss Modules (via the -mp <the_path> argument to java.) In AS 7.2, the custom module loader we will use will support this behavior, but in addition the custom module loader we provide will be able to examine the patching metadata that will be persisted in the "staging" phase and from that will determine which of the patch-specific subdirectories of the patches directory need to be prepended to the module path. In addition, for modules that have been removed in patches, the custom module loader will know to not load those modules, even though the modules will still remain on the filesystem.
h4. Bundles
TODO -- basic idea is to do something similar to how modules work, but the details need to be sorted out.
h4. Misc Files
Application of miscellaneous files to the runtime is straightforward. The staging step places the patch's miscellaneous files in the normal location that the runtime services will expect, so when the target process is restarted, the runtime services see them.
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.
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.+*
h2. Rollback Application
A patch rollback is "applied" by stopping the target process and then restarting it in a normal manner; e.g. from the command line or by using the :shutdown(restart=true) command from the CLI. The modules, bundles and miscellaneous files that have been staged are then used by the restarted process.
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.
h4. Modules
See the discussion in "Patch Application" above of how the module path works. When a patch is rolled back, the metadata the custom module loader uses to construct the module path will no longer indicate the patch's modules should be on the path, so they will not be available for loading.
h4. Bundles
TODO -- basic idea is to do something similar to how modules work, but the details need to be sorted out.
h4. Misc Files
As was the case in the discussion in "Patch Application" above, the patch rollback staging step places the correct miscellaneous files in the normal location that the runtime services will expect, so when the target process is restarted, the runtime services see them.
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 or removing an existing module, the patch.xml file will include the hash of the existing module's contents. The patching process will hash the current module's contents 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 a module, they will need to make an equivalent change to the patch module. The sole purpose of this "module conflict detection" is to provide information to users.
* Bundles: If the patch is updating or removing an existing bundle, the patch.xml file will include the hash of the existing bundle's contents. The patching process will hash the current bundle's contents to check for modifications. If any affected bundle is found to have been modified, the patch command will have to have been provided with a parameter indicating that "overriding" modified bundles is ok. No option will be given to optionally override some bundles and leave others unmodified. If the user wishes to retain some modification they made to a bundle, they will need to make an equivalent change to the patch bundle. The sole purpose of this "bundle conflict detection" is to provide information to users.
* Misc files: If the patch is updating an existing misc file, the patch.xml file will include the hash of the existing file. If the patch is removing an existing directory, the patch.xml file will include the hash of the existing directory's contents. The patching process will hash the current file or directory to check for modifications. If any affected file/directory 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. If no permission is available for a particular file or directory, the conflict will be treated as unresolved. These permissions can come in four forms:* A global permission to update all conflicting misc files, provided as a param to the CLI tool's patching command
* A global permission to not update any conflicting misc files, provided as a param to the CLI tool's patching command
* A file containing* a list of paths (relative to $JBOSS_HOME) for which update permission is granted.
* a list of paths (relative to $JBOSS_HOME) for which update permission is denied, meaning the existing file should be retained.
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
h4. Directory structure
h4.
${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, 6 months
- 1
- 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-10820
--------------------------------------------------
I'm going to change the conflict detection stuff to have the hash include all contents of the updated/removed module or bundle or a removed misc directory. It's no big deal to compute this, and it's clearer for the end user.
--------------------------------------------------
11 years, 6 months
- 1
- 0
[JBoss Tools Development] - Promoting JBoss Tools nightly project builds to milestone or stable release
by Nick Boldt
Nick Boldt [https://community.jboss.org/people/nickboldt] modified the document:
"Promoting JBoss Tools nightly project builds to milestone or stable release"
To view the document, visit: https://community.jboss.org/docs/DOC-47427
--------------------------------------------------------------
+*This doc is in progress and subject to change. ~nickboldt*+
Publishing SOA/BRMS Tooling components
*== STEP ONE :: Nightly Snapshot Build (Continuous Integration) ==*
Run your job as you would run a local build, that is, by invoking Maven 3 w/ Tycho 0.15 (or later) against your sources.
Then publish the output of the build to the server using publish.sh - simply run a shell script at the end of the job which does this:
Currently, the publish.sh script that everyone uses assumes a few things:
a) git or svn sources are fetched into ${WORKSPACE}/sources/, not the root ${WORKSPACE} folder
b) all builds will go into http://download.jboss.org/jbosstools/builds/staging/builds/staging/$ http://download.jboss.org/jbosstools/builds/staging/builds/staging/${JOB_...
Invocation of the script is done via Jenkins like this:
cd ${WORKSPACE}/sources/
wget http://anonsvn.jboss.org/repos/jbosstools/trunk/build/publish/publish.sh http://anonsvn.jboss.org/repos/jbosstools/trunk/build/publish/publish.sh -q --no-check-certificate -N
. publish.sh
*== STEP TWO :: Promoting a Snapshot to Milestone / Release ==*
You will need a second job with a "-publish" suffix which will copy your latest nightly to a new location.
Invocation of the script is done via Jenkins like this:
wget http://anonsvn.jboss.org/repos/jbosstools/trunk/build/publish/promote.sh http://anonsvn.jboss.org/repos/jbosstools/trunk/build/publish/promote.sh -q --no-check-certificate -N
. promote.sh -BUILD_TYPE build_type -TARGET_PLATFORM target_platform -PROJECT_NAME project_name -TARGET_FOLDER target_folder -SOURCE_PATH source_path
Example jobs (which show how to set up the above job parameters, such as ${TARGET_PLATFORM} or ${BUILD_TYPE}):
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-promote/ https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-promote/
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/SOA-Team/view/SOASt... https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/SOA-Team/view/SOASt...
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/SOA-Team/view/SOASt... https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/SOA-Team/view/SOASt...
*== Naming conventions ==*
Development milestones (x.y.z.Beta2) go here: updates/development/{eclipse-version}/{stream}/
Stable releases (x.y.z.Final) will go in here: updates/{stable|release}/{eclipse-version}/{stream}/
Examples:
http://download.jboss.org/jbosstools/updates/development/indigo/soa-tooli... http://download.jboss.org/jbosstools/updates/development/indigo/soa-tooli...
http://download.jboss.org/jbosstools/updates/development/indigo/soa-tooli... http://download.jboss.org/jbosstools/updates/development/indigo/soa-tooli...
http://download.jboss.org/jbosstools/updates/development/juno/soa-tooling... http://download.jboss.org/jbosstools/updates/development/juno/soa-tooling...
http://download.jboss.org/jbosstools/updates/stable/indigo/soa-tooling/sw... http://download.jboss.org/jbosstools/updates/stable/indigo/soa-tooling/sw...
*== Integration Builds? ==*
In future, we may also have "integration" builds, which are nightlies deemed good enough for
use by downstream developers, but not stable enough (ie., not tested enough) to be released to community as a milestone.
The above process will also work for building then promoting an integration build - it just uses BUILD_TYPE = *integration* instead of development or stable.
*== Composite Sites? ==*
When you publish your build, eg., into
http://download.jboss.org/jbosstools/updates/development/juno/soa-tooling... http://download.jboss.org/jbosstools/updates/development/juno/soa-tooling...
composite metadata will now be generated into
http://download.jboss.org/jbosstools/updates/development/juno/soa-tooling... http://download.jboss.org/jbosstools/updates/development/juno/soa-tooling...
See https://issues.jboss.org/browse/JBIDE-12662 https://issues.jboss.org/browse/JBIDE-12662 for details.
*== Index Pages? ==*
Should the generated sites have a similar look and feel instead of a raw directory listing?
Yes. See https://issues.jboss.org/browse/JBIDE-12660 https://issues.jboss.org/browse/JBIDE-12660
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-47427]
Create a new document in JBoss Tools Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
11 years, 6 months
- 1
- 0
[JBoss AS 7 Development] Announcement: Help us rename JBoss AS!
by Jason Greene
Jason Greene [https://community.jboss.org/people/jason.greene] posted the announcement
<b>Announcement</b>: "Help us rename JBoss AS!"
To view the announcement, visit: https://community.jboss.org/community/jbossas7/dev
--------------------------------------------------------------
http://www.businesswire.com/news/home/20121001005276/en/Red-Hat-Enters-Ph... As recently announced, we will be renaming the JBoss AS community project and are soliciting your suggestions and your vote on the new name that will best communicate our new direction. As Mark eloquently puts it https://community.jboss.org/blogs/mark.little/2012/10/01/announcing-the-r... in his blog, we have come a long way from the original meaning of the name, and we want the new name to emphasize the trail blazing role of the community project.
http://jboss.org/vote See our vote now page for more information and how to submite your ideas.
--------------------------------------------------------------
Announcement expires on December 30, 2012
11 years, 6 months
- 1
- 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, or if the relevant file is a directory.
* A boolean indicator as to whether the relevant file is a directory.
* 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
* The hash of the version of the file that was in the version being patched. Not present if the relevant file is a directory.
* A boolean indicator as to whether the relevant file is a directory.
* 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
A patch is "applied" by stopping the target process and then restarting it in a normal manner; e.g. from the command line or by using the :shutdown(restart=true) command from the CLI. The patch contents that have been staged are then used by the restarted process.
h4. Modules
In 7.2 the AS will use a custom implementation of the JBoss Modules ModuleLoader interface, instead of the default implementation used in previous AS 7 releases. The selection of this custom implementation will be part of the launch VM command created by the startup scripts (i.e. standalone.sh/standalone.bat/domain.sh/domain.bat). The module loader works using a notion of a "module path", which is an ordered list of directories in which modules are located. When the module loader needs to find a module, it searches the directories in that path in order, and once it finds the desired module the search ends. Thus, directories earlier in the path listing take precedence over those found later. This is all very similar to how an OS uses the $PATH environment variable.
Previous AS7 releases allowed the user to specify a $JBOSS_MODULES_PATH environment variable to declare the "module path", with a default value of $JBOSS_HOME/modules used if not specified. The startup scripts used to the AS pass that module path into JBoss Modules (via the -mp <the_path> argument to java.) In AS 7.2, the custom module loader we will use will support this behavior, but in addition the custom module loader we provide will be able to examine the patching metadata that will be persisted in the "staging" phase and from that will determine which of the patch-specific subdirectories of the patches directory need to be prepended to the module path. In addition, for modules that have been removed in patches, the custom module loader will know to not load those modules, even though the modules will still remain on the filesystem.
h4. Bundles
TODO -- basic idea is to do something similar to how modules work, but the details need to be sorted out.
h4. Misc Files
Application of miscellaneous files to the runtime is straightforward. The staging step places the patch's miscellaneous files in the normal location that the runtime services will expect, so when the target process is restarted, the runtime services see them.
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.
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.+*
h2. Rollback Application
A patch rollback is "applied" by stopping the target process and then restarting it in a normal manner; e.g. from the command line or by using the :shutdown(restart=true) command from the CLI. The modules, bundles and miscellaneous files that have been staged are then used by the restarted process.
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.
h4. Modules
See the discussion in "Patch Application" above of how the module path works. When a patch is rolled back, the metadata the custom module loader uses to construct the module path will no longer indicate the patch's modules should be on the path, so they will not be available for loading.
h4. Bundles
TODO -- basic idea is to do something similar to how modules work, but the details need to be sorted out.
h4. Misc Files
As was the case in the discussion in "Patch Application" above, the patch rollback staging step places the correct miscellaneous files in the normal location that the runtime services will expect, so when the target process is restarted, the runtime services see them.
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
h4. Directory structure
h4.
${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, 6 months
- 1
- 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
h4. Directory structure
h4.
${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, 6 months
- 1
- 0
[JBoss Web Services Development] - SOAP Message validation now enabled by default?
by Paul Robinson
Paul Robinson [https://community.jboss.org/people/paul.robinson] created the discussion
"SOAP Message validation now enabled by default?"
To view the discussion, visit: https://community.jboss.org/message/762174#762174
--------------------------------------------------------------
Hello,
Since AS7 upgraded from CXF '2.4.8-patch-01' to '2.4.9' ( https://github.com/jbossas/jboss-as/commit/0a1e626a5c4bf52a8c75e0cd27f15c... https://github.com/jbossas/jboss-as/commit/0a1e626a5c4bf52a8c75e0cd27f15c...) we have been getting the following 'unexpected element' error:
18:34:17,669 WARNING [org.apache.cxf.phase.PhaseInterceptorChain] (http-/127.0.0.1:8080-3) Interceptor for {http://schemas.arjuna.com/ws/2005/10/wsarjtx}TerminationParticipantSer
vice#{http://schemas.arjuna.com/ws/2005/10/wsarjtx}FaultOperation has thrown exception, unwinding now: org.apache.cxf.interceptor.Fault: Unexpected element {http://schemas.xmlsoa
p.org/soap/envelope/}Fault found. Expected {http://schemas.arjuna.com/ws/2005/10/wsarjtx}Fault.
at org.apache.cxf.interceptor.DocLiteralInInterceptor.validatePart(DocLiteralInInterceptor.java:259) [cxf-rt-core-2.4.9.jar:2.4.9]
at org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:201) [cxf-rt-core-2.4.9.jar:2.4.9]
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263) [cxf-api-2.4.9.jar:2.4.9]
at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) [cxf-rt-core-2.4.9.jar:2.4.9]
at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:207) [cxf-rt-transports-http-2.4.9.jar:2.4.9]
at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:91)
at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:169)
at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:87)
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:185) [cxf-rt-transports-http-2.4.9.jar:2.4.9]
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:108) [cxf-rt-transports-http-2.4.9.jar:2.4.9]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:754) [jboss-servlet-api_3.0_spec-1.0.1.Final.jar:1.0.1.Final]
at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:135)
at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.1.Final.jar:1.0.1.Final]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:372)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:679)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931)
at java.lang.Thread.run(Thread.java:680) [classes.jar:1.6.0_35]
This error occurs because our message type doesn't match that required by the WSDL:
<soap:Body>
<ns2:Fault xmlns:ns2="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns3="http://schemas.arjuna.com/ws/2005/10/wsarjtx">
<faultcode>ns3:TransactionRolledBack</faultcode>
<faultstring>ARJUNA043178: Transaction rolled back</faultstring>
</ns2:Fault>
</soap:Body>
Notice that the message is of type "ns2:Fault", rather than "ns3:Fault". The wsdl wants a '{http://schemas.arjuna.com/ws/2005/10/wsarjtx}Fault'.
So we have two problems here. The first is the problem that we have been sending malformed messages for some time. The second is that since the upgrade to CXF 2.4.9, this issue was not tolerated. In the long term we need to fix the message, but that may not be possible in the short term as we may not be able to get this fix into the release that needs it.
Do you know what has changed in CXF to cause this issue and do you know of a work-around?
For the original issue see here: https://issues.jboss.org/browse/JBTM-1275 https://issues.jboss.org/browse/JBTM-1275
Thanks,
Paul.
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/762174#762174]
Start a new discussion in JBoss Web Services Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
11 years, 6 months
- 2
- 2
[jBPM Development] - Cant connect to Hornet task server after changing database
by loaone seleka
loaone seleka [https://community.jboss.org/people/loaone] created the discussion
"Cant connect to Hornet task server after changing database"
To view the discussion, visit: https://community.jboss.org/message/762468#762468
--------------------------------------------------------------
Good Day
I have changed my database from H2 to MySQL but i can not deploy my task server
the error is
0 01/10 11:12:11,453[main] ERROR service.hornetq.HornetQTaskClientConnector.connect - Unable to connect to server using configuration org-hornetq-core-remoting-impl-netty-NettyConnectorFactory?port=5445&host=127-0-0-1
Exception in thread "main" org.jbpm.workflow.instance.WorkflowRuntimeException: [com.example.bpmn:1 - User Task:3] -- Could not connect task client: on ip: 127.0.0.1 - port: 5445
at org.jbpm.workflow.instance.impl.NodeInstanceImpl.trigger(NodeInstanceImpl.java:130)
at org.jbpm.workflow.instance.impl.NodeInstanceImpl.triggerNodeInstance(NodeInstanceImpl.java:205)
at org.jbpm.workflow.instance.impl.NodeInstanceImpl.triggerCompleted(NodeInstanceImpl.java:164)
at org.jbpm.workflow.instance.node.StartNodeInstance.triggerCompleted(StartNodeInstance.java:49)
at org.jbpm.workflow.instance.node.StartNodeInstance.internalTrigger(StartNodeInstance.java:41)
at org.jbpm.workflow.instance.impl.NodeInstanceImpl.trigger(NodeInstanceImpl.java:124)
at org.jbpm.ruleflow.instance.RuleFlowProcessInstance.internalStart(RuleFlowProcessInstance.java:35)
at org.jbpm.process.instance.impl.ProcessInstanceImpl.start(ProcessInstanceImpl.java:188)
at org.jbpm.workflow.instance.impl.WorkflowProcessInstanceImpl.start(WorkflowProcessInstanceImpl.java:303)
at org.jbpm.process.instance.ProcessRuntimeImpl.startProcessInstance(ProcessRuntimeImpl.java:168)
at org.jbpm.process.instance.ProcessRuntimeImpl.startProcess(ProcessRuntimeImpl.java:138)
at org.jbpm.process.instance.ProcessRuntimeImpl.startProcess(ProcessRuntimeImpl.java:130)
at org.drools.common.AbstractWorkingMemory.startProcess(AbstractWorkingMemory.java:1077)
at org.drools.impl.StatefulKnowledgeSessionImpl.startProcess(StatefulKnowledgeSessionImpl.java:315)
at example.TestProcess.main(TestProcess.java:46)
Caused by: java.lang.IllegalArgumentException: Could not connect task client: on ip: 127.0.0.1 - port: 5445
at org.jbpm.process.workitem.wsht.GenericHTWorkItemHandler.connect(GenericHTWorkItemHandler.java:119)
at org.jbpm.process.workitem.wsht.GenericHTWorkItemHandler.executeWorkItem(GenericHTWorkItemHandler.java:143)
at org.drools.process.instance.impl.DefaultWorkItemManager.internalExecuteWorkItem(DefaultWorkItemManager.java:70)
at org.jbpm.workflow.instance.node.WorkItemNodeInstance.internalTrigger(WorkItemNodeInstance.java:105)
at org.jbpm.workflow.instance.impl.NodeInstanceImpl.trigger(NodeInstanceImpl.java:124)
... 14 more
Please help if you can
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/762468#762468]
Start a new discussion in jBPM Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
11 years, 6 months
- 1
- 0
[JBoss Web Services Development] - Cannot find ServiceFactory implementation Problem
by Dipak Patel
Dipak Patel [https://community.jboss.org/people/dipak.nit] created the discussion
"Cannot find ServiceFactory implementation Problem"
To view the discussion, visit: https://community.jboss.org/message/762454#762454
--------------------------------------------------------------
Hello All,
I have created one web service and hosted it in JBoss. Now i want to use that web service in another class using following code.
-------------------------------------------------------------------
public static void main(String[] args) throws Exception
{
try
{
String urlstr = " http://localhost:8080/SimpleWebServiceAnnotationProject?wsdl http://localhost:8080/SimpleWebServiceAnnotationProject?wsdl";
System.out.println("Contacting webservice at " + urlstr);
URL url = new URL(urlstr);
String ns = " http://simple.ws.jboss.org/ http://simple.ws.jboss.org/";
QName qname = new QName(ns, "SimpleServiceAnnotation");
QName port = new QName(ns, "SimpleAnnotationPort");
QName operation = new QName(ns, "getMessage");
ServiceFactory factory = ServiceFactory.newInstance();
Service service = factory.createService(url, qname);
Call call = service.createCall(port, operation);
System.out.println("output:" + call.invoke(null));
}
catch (Exception e)
{
e.printStackTrace();
}
}
-------------------------------------------------------------------
If i run this code then it alwasys shows me following error.
Contacting webservice at http://localhost:8080/SimpleWebServiceAnnotationProject?wsdl
javax.xml.rpc.ServiceException: Cannot find ServiceFactory implementation
at javax.xml.rpc.ServiceFactory.newInstance(ServiceFactory.java:115)
at applications.JaxRpcDIIClient.main(JaxRpcDIIClient.java:28)
I am using JBoss 7.1.1 Final version.
I can Browse the web service http://localhost:8080/SimpleWebServiceAnnotationProject?wsdl in internet explorer.
Can any one help me what i missing here?
Thanks
Dipak
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/762454#762454]
Start a new discussion in JBoss Web Services Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
11 years, 6 months
- 1
- 0