[JBoss AS 7 Development] - Experimenting with Single Installation Patching
by Emanuel Muckenhuber
Emanuel Muckenhuber [https://community.jboss.org/people/emuckenhuber] modified the document:
"Experimenting with Single Installation Patching"
To view the document, visit: https://community.jboss.org/docs/DOC-47969
--------------------------------------------------------------
*+Initial draft; I haven't verified everything in this doc yet!!!+*
Instructions for experimenting with the " https://community.jboss.org/docs/DOC-47500 Single Installation Patching" feature currently being developed.
These instructions assume basic git knowledge and knowledge of how to work with the AS 7 code base. See " https://community.jboss.org/docs/DOC-15596 Hacking on JBoss AS7" for basic background.
h2. Getting and Building the Source
The patching feature is currently on a topic branch being maintained by Emanuel Muckenhuber. Until that branch is merged into master:
1) If you haven't already, clone the AS repo
$ git clone git://github.com/jbossas/jboss-as.git
2) Add Emanuel's github repo as a remote
$ cd jboss-as
$ git remote add -f emanuel git://github.com/emuckenhuber/jboss-as.git
3) Checkout a new branch "patches-master" to track Emanuel's branch
$ git checkout -t emanuel/patches-master
4) Build the AS
$ ./build.sh
add the -DskipTests option to skip running tests if you want the build to go a bit faster.
h3. Generating Patches
To generate a patch, you'll need 5 things:
1. An unzipped AS distribution representing the AS release being patched. This is the "applies-to-dist". This can be any AS7 release distribution, or the output of any successful build of the AS7 codebase since 7.1.0.Final was released. (Even earlier would probably work fine.)
2. An unzipped AS distribution representing the "patched" AS release. This is the "updated-dist". This is a distribution built from code that is newer than whatever went into the "applies-to" distribution. It can be a later release or build, or even the same distribution as the "applies-to-dist" that you've manually modified in some fashion.
3. An AS distribution you built following the instructions in the "Getting and Building the Source" section above. The patch generation tool is included in this distribution. If the distribution you are using for the "updated-dist" was built in that manner, then you can use it; you don't need a separate distribution. At some point we'll distribute the patch generation tool as a separate distribution, but for now it's simplest just to use an AS distribution. In the rest of this section, we'll refer to this as the "patch generation tool distribution."
4. A patch-config.xml file providing instructions about how to create the patch. See details below.
5. The filesystem location where you want the patch file to be written (including the name of the file.)
To run the patch generation tool:
$ cd /root/of/the/patch/generation/tool/distribution
$ java -jar jboss-modules.jar -mp modules org.jboss.as.patching.generator --help
INFO [org.jboss.modules] JBoss Modules version 1.1.3.GA
Usage: patch-gen.sh [args...]
where args include:
--applies-to-dist=<file> Filesystem path of a pristine unzip of
the distribution of the version of the
software to which the generated patch
applies
-h, --help Display this message and exit
--output-file=<file> Filesystem location to which the
generated patch file should be written
--patch-config=<file> Filesystem path of the patch generation
configuration file to use
--updated-dist=<file> Filesystem path of a pristine unzip of
a distribution of software which
contains the changes that should be
incorporated in the patch
-v, --version Print version and exit
To actually run the patch generation tool and not just get help output, you will need to append the --applies-to-dist, --updated-dist, --patch-config and --output-file arguments described above to the process launch command (instead of --help), with the appropriate value for each included.
The java command above is pretty lengthy, so we've written a shell script that does the same thing. In the source code it can be found at patching/src/main/resources/patch-gen.sh. Copy that to the bin/ dir of the patch generation tool distribution and then you can get the output above by simply doing:
$ bin/patch-gen.sh --help
+TODO: the patch-gen tool should use sensible defaults for --applies-to-dist, --updated-dist and --output-file such that only --patch-config needs to be specified. Or, allow those locations to be specified in the patch-config.xml file itself.+
* +Default for +--updated-dist+ can be the current working dir, or its parent if the current working dir is named bin/. Apply some simple sanity checks, e.g. check for jboss-modules.jar etc. The assumption here is the tool is being run from the ++--updated-dist++ (which is the newest dist and thus will have the newest version of the tool)
+
* +Default for +--applies-to-dist+ can be a sibling of the root of --applies-to-dist, named the same as the applies-to-version in the patch-config.xml.
+
* +Default for --output-file can be patch.par in the current working dir, assuming no such file already exists+
h4. Methods of Patch Generation
There are two basic methods of patch generation. Which the tool should use is declared in the patch-config.xml file:
* generate-by-diff: The patch generation tool itself compares the contents of the --applies-to-dist and the --updated-dist and creates a patch. This is most useful for CP patches. +TODO for one-off patches allow an option where the diffing algorithm ignore will timestamps as described by Jeff Mesnil (http://https://community.jboss.org/wiki/SingleInstallationPatching#commen...
* specified-content: The patch-config.xml file declares in detail what modules, bundles and misc files are to be added, updated or removed via the patch. This is most useful for one-off patches where the patch author knows what has changed.
h4. The patch-config.xml File
The patch-config.xml file provides basic metadata about the patch, along with instructions on how to generate it. The person preparing the patch creates the patch-config.xml file.
+Note: the file doesn't have to be named patch-config.xml; it can be named anything.+
The simplest way to describe the file is to show a couple of examples. The full xsd for the file can be found in the AS source dist at patching/src/main/resources/patch-config.xsd.
An example patch-config file for a generate-by-diff patch:
<?xml version='1.0' encoding='UTF-8'?>
<patch-config xmlns="urn:jboss:patch-config:1.0">
<name>6.1.0-to-6.1.1</name>
<description>Cumulative patch to move from EAP 6.1.0.GA to EAP 6.1.1.GA</description>
<cumulative applies-to-version="EAP 6.1.0.GA" resulting-version="EAP 6.1.1.GA"/>
<generate-by-diff/>
</patch-config>
An example patch-config file for a specified-content patch:
<?xml version='1.0' encoding='UTF-8'?>
<patch-config xmlns="urn:jboss:patch-config:1.0">
<name>JBPAPP6-123</name>
<description>One off patch to fix JBPAPP6-123</description>
<one-off>
<applies-to-version>EAP 6.1.0.GA</applies-to-version>
</one-off>
<specified-content>
<modules>
<added-module name="org.jboss.as.foo" />
<updated-module name="org.jboss.as.bar" slot="eap"/>
<removed-module name="org.jboss.as.fubar" />
</modules>
<misc-files>
<updated-misc-content path="bin/standalone.sh" />
<updated-misc-content path="bin/standalone.bat" />
</misc-files>
</specified-content>
</patch-config>
h3. Applying Patches
Only an AS release that includes the patching feature can be patched using the patching tool. So, that means you can only experiment with applying patches to an AS distribution you built following the instructions in the "Getting and Building the Source" section above. That limits things a bit as far as what patches you can try to apply; for example you couldn't generate a patch that represents the difference between 7.1.2.Final and 7.1.3.Final and then apply it to 7.1.2.Final.
To apply a patch, you need:
1. A patch file, prepared as described in the "Generating Patches" section.
2. An unzipped AS distribution that represents the "applies-to" distribution. This can be the exact same "applies-to" distribution you used when creating the patch, or, if you want to experiment with how the patch tool deals with the (typical) situation where the user has in some way modified a standard AS version, you can make some sort of modification.
We use the standard AS CLI tool to provide the user interface for the patch application tool. To see how to apply the patch, cd into the root of the installation being patched, launch the CLI and get the help for the "patch" command:
$ bin/jboss-cli.sh -c
[standalone@localhost:9999 /] patch --help
SYNOPSIS
patch
<action> <action_arguments>*
[--override-all]
[--override-modules]
[--override=path(,path)*]
[--preserve=path(,path)*]
[--host=<host>]
where <action> can be
apply - apply a patch
info - information about the installed patches
rollback - rollback a patch that has been applied
and <action_arguments> depends on the <action>
ACTION: apply
Apply a patch
....
h3.
This document won't include any more details on actually executing the patch command. Part of the goal of experimenting with it is to see if the --help output is adequate for users to understand what to do.
The patch command only stages the patch (i.e. modifies the filesystem in a way that should not impact the running target process.) To actually have the patch take effect in the runtime, the target process needs to be restarted:
[standalone@localhost:9999 /] :shutdown(restart=true)
{"outcome" => "success"}
Note that simply reloading the target process (using the :reload operation) is insufficient.
+TODO add options to the patch command to automatically restart the process if staging is successful.+
h3. The patch info
The patch info shows all currently active patches. In case there is no cumulative patch active it will return "base".
[standalone@localhost:9999 /] patch info
{
"outcome" : "success",
"result" : {
"cumulative" : "6.1.0-to-6.1.1",
"patches" : [ "JBPAPP6-123" ]
}
}
h3. Conflict resolution
Conflict dection is run for both applying and rolling back patches. In case conflicts are detected and the patch operation will fail and return all found conflicts as part of the failure-description. Since modules are not directly touched there is only a single swtich to ignore those (--override-modules).
h3. Following Progress
The patching feature is still under active development, so if you want update your build and see what's new:
1) cd into the git repo you cloned in step 1) of "Getting and Building the Source" above.
2) Pull down the latest
$ git fetch emanuel
3) Make sure you have a clean repo
$ git status
4) Rebase your branch onto the latest
$ git checkout patches-master
$ git rebase emanuel/patches-master
5) Build again
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-47969]
Create a new document in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
11 years, 4 months
[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
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.
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. Git Branches (4.17 and 5 only)
Must be done first as the build-release-packages.xml relies on the tag being available
For REPO in (documentation quickstart narayana); do
REPO=<REPO>
BRANCH=<4.17|master>
CURRENT=<Point version to release>
NEXT=<point version of next release, likely to be $CURRENT+1>
git clone mailto:git@github.com git@github.com:jbosstm/$REPO.git
cd $REPOgit checkout $BRANCH
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 | grep -v .idea | xargs sed -i "s/4\([._]\)17\([._]\)$CURRENT\([._]\)Final-SNAPSHOT/4\117\2$CURRENT\3Final/"
git commit -am "Updated to 4.17.$CURRENT.Final"
git tag 4.17.$CURRENT.Final
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 | grep -v .idea | xargs sed -i "s/4\([._]\)17\([._]\)$CURRENT\([._]\)Final/4\117\2$NEXT\3Final-SNAPSHOT/"
git commit -am "Updated to 4.17.$NEXT.Final-SNAPSHOT"
git push origin $BRANCH --tags
cd ..
h3. Update our AS7 fork
BRANCH=4_BRANCH
CURRENT=<Point version to release>
NEXT=<point version of next release, likely to be $CURRENT+1>
git clone git@github.com:jbosstm/jboss-as.git
cd jboss-as
git checkout $BRANCH
sed -i "s/4.17.$CURRENT.Final-SNAPSHOT/4.17.$NEXT.Final-SNAPSHOT/g" pom.xml
git commit -am "Updated to 4.17.$NEXT.Final-SNAPSHOT"
git push origin $BRANCH
h2. Build and release
CURRENT=<Point version to release>
mkdir -p ~/narayana/filemgmt.jboss.org/
sshfs -o defer_permissions mailto:jbosstm@filemgmt.jboss.org jbosstm(a)filemgmt.jboss.org: ~/narayana/filemgmt.jboss.org/
git clone mailto:git@github.com git@github.com:jbosstm/narayana.git
cd narayana
git checkout 4.17.$CURRENT.Final
ant -f build-release-pkgs.xml dist downloads docs magnolia
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/branches/JBOSSTS_4_16 https://svn.jboss.org/repos/labs/labs/jbosstm/tags/JBOSSTS_4_16_4_Final/ 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 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 -o defer_permissions mailto:jbosstm@filemgmt.jboss.org jbosstm(a)filemgmt.jboss.org: ~/filemgmt.jboss.org/
svn switch https://svn.jboss.org/repos/labs/labs/jbosstm/tags/JBOSSTS_4_16_$ https://svn.jboss.org/repos/labs/labs/jbosstm/tags/JBOSSTS_4_16_${NEXT_PO...
ant -f build-release-pkgs.xml dist mvn-repository downloads magnolia
h3.
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. Close all issues for the release
2. 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, update AS7.
1. https://issues.jboss.org/browse/AS7 https://issues.jboss.org/browse/AS7
2. create a new 'component update' issue. 1. Ensure the module is set to 'transactions'
2. select an appropriate 'fix for'.
3. Assign it to yourself.
Now update the code in your fork:
#cd to *your* fork of AS7
BRANCH=master # master for JBossTS-4.17.x and 7.1 for JBossTS-4.16.x
JIRA=AS7-5815
PREVIOUS=4.17.1.Final
CURRENT=4.17.2.Final
git checkout $BRANCH
git pull --rebase --ff-only upstream $BRANCH
git checkout -b "${JIRA}_Upgrading_JBossTS_to_${CURRENT}"
sed -i "s/$PREVIOUS/$CURRENT/g" pom.xml
git add pom.xml
git commit -m "${JIRA} Upgrading JBossTS to ${CURRENT}"
rm -rf ~/.m2/repository/org/jboss/jbossts
rm -rf ~/.m2/repository/org/jboss/narayana
build.sh clean install
git push origin "${JIRA}_Upgrading_JBossTS_to_${CURRENT}"
1. Raise a pull request
2. Once merged, resolve the Jira issue.
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, 4 months
[JBoss ESB Development] - Re: Use of ServiceInvoker to test an ESB service
by carl lee
carl lee [https://community.jboss.org/people/carl918] created the discussion
"Re: Use of ServiceInvoker to test an ESB service"
To view the discussion, visit: https://community.jboss.org/message/779272#779272
--------------------------------------------------------------
https://community.jboss.org/servlet/JiveServlet/showImage/2-779272-19951/... https://community.jboss.org/servlet/JiveServlet/downloadImage/2-779272-19...
my project contructs like above graph,and i'sure added all jars ,but SendEsbMessage can work yet,report err following:
Exception in thread "main" org.jboss.soa.esb.listeners.message.MessageDeliverException: org.apache.ws.scout.transport.TransportException: java.lang.reflect.InvocationTargetException
at org.jboss.soa.esb.client.ServiceInvoker.loadServiceClusterInfo(ServiceInvoker.java:545)
at org.jboss.soa.esb.client.ServiceInvoker.<init>(ServiceInvoker.java:174)
at org.jboss.soa.esb.client.ServiceInvoker.<init>(ServiceInvoker.java:155)
at org.jboss.soa.esb.client.ServiceInvoker.<init>(ServiceInvoker.java:197)
at org.jboss.soa.esb.samples.quickstart.helloworld.test.SendEsbMessage.main(SendEsbMessage.java:54)
Caused by: org.jboss.soa.esb.services.registry.RegistryException: org.apache.ws.scout.transport.TransportException: java.lang.reflect.InvocationTargetException
at org.jboss.internal.soa.esb.services.registry.JAXRRegistryImpl.findEPRs(JAXRRegistryImpl.java:348)
at org.jboss.internal.soa.esb.services.registry.InVMRegistryInterceptor.findEPRs(InVMRegistryInterceptor.java:85)
at org.jboss.soa.esb.services.registry.RegistryFactory$HeadRegistryInterceptor.findEPRs(RegistryFactory.java:229)
at org.jboss.soa.esb.listeners.RegistryUtil.getEprs(RegistryUtil.java:226)
at org.jboss.soa.esb.client.ServiceInvoker.loadServiceClusterInfo(ServiceInvoker.java:532)
... 4 more
Caused by: javax.xml.registry.JAXRException: org.apache.ws.scout.transport.TransportException: java.lang.reflect.InvocationTargetException
at org.apache.ws.scout.registry.BusinessQueryManagerV3Impl.findConcepts(BusinessQueryManagerV3Impl.java:516)
at org.jboss.internal.soa.esb.services.registry.JAXRRegistryImpl.getJBossESBTModel(JAXRRegistryImpl.java:653)
at org.jboss.internal.soa.esb.services.registry.JAXRRegistryImpl.findEPRs(JAXRRegistryImpl.java:307)
... 8 more
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/779272#779272]
Start a new discussion in JBoss ESB Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
11 years, 5 months
[JBoss AOP Development] - Problem creating service jboss.aop:service=AspectManager
by Murali K
Murali K [https://community.jboss.org/people/kmk1977] created the discussion
"Problem creating service jboss.aop:service=AspectManager"
To view the discussion, visit: https://community.jboss.org/message/779221#779221
--------------------------------------------------------------
Hi Experts,
I have been strugling with JBoss AOP execution, I did everything correct for JBoss AOP , but still i am always getting the following error.
Please help me.
1)I have installed jboss-aop-jdk50.deployer
2) modified jboss-service.xml <attribute name="EnableLoadtimeWeaving">true</attribute>
3)modified run.bat with set JAVA_OPTS=%JAVA_OPTS% -Dprogram.name=%PROGNAME% -javaagent:%JBOSS_ENDORSED_DIRS%\pluggable-instrumentor.jar
4)pluggable-instrumentor.jar is there in bin and as well in endorsed folder
5)I have deployed jboss-aop.xml the aspect/interceptor classes jar in /deploy folder
No luck, i have been strugling for 2 days. Please help.
17:29:47,561 WARN [ServiceController] Problem creating service jboss.aop:service=AspectManager
java.lang.NullPointerException
at org.jboss.aop.asintegration.core.AspectManagerServiceDelegateJDK5.attachTranslator(AspectManagerServiceDelegateJDK5.java:42)
at org.jboss.aop.asintegration.core.AspectManagerServiceDelegate.create(AspectManagerServiceDelegate.java:252)
at org.jboss.aop.deployment.AbstractAspectManagerService.create(AbstractAspectManagerService.java:107)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:995)
at $Proxy0.create(Unknown Source)
at org.jboss.system.ServiceController.create(ServiceController.java:330)
at org.jboss.system.ServiceController.create(ServiceController.java:273)
at org.jboss.system.ServiceController.create(ServiceController.java:349)
at org.jboss.system.ServiceController.create(ServiceController.java:273)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy4.create(Unknown Source)
at org.jboss.deployment.SARDeployer.create(SARDeployer.java:260)
at org.jboss.deployment.MainDeployer.create(MainDeployer.java:969)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:818)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy9.deploy(Unknown Source)
at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:417)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy4.start(Unknown Source)
at org.jboss.deployment.SARDeployer.start(SARDeployer.java:304)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy5.deploy(Unknown Source)
at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
at org.jboss.Main.boot(Main.java:200)
at org.jboss.Main$1.run(Main.java:508)
at java.lang.Thread.run(Unknown Source)
AND
--- MBeans waiting for other MBeans ---
ObjectName: jboss.aop:service=AspectManager
State: FAILED
Reason: java.lang.NullPointerException
I Depend On:
jboss.aop:service=JBoss4IntegrationWrapper
--- MBEANS THAT ARE THE ROOT CAUSE OF THE PROBLEM ---
ObjectName: jboss.aop:service=AspectManager
State: FAILED
Reason: java.lang.NullPointerException
I Depend On:
jboss.aop:service=JBoss4IntegrationWrapper
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/779221#779221]
Start a new discussion in JBoss AOP Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
11 years, 5 months
Re: [jboss-dev-forums] [JBoss AS 7 Development] - Using JBoss Negotiation on AS7
by guillaume cornet
guillaume cornet [https://community.jboss.org/people/raoulpetitpied] commented on the document
"Using JBoss Negotiation on AS7"
To view all comments on this document, visit: https://community.jboss.org/docs/DOC-16876#comment-11199
--------------------------------------------------
In my case, the given 'host' security-domain configuration failed, generating a 'Mechanism level: Checksum failed' exception.
I successfully use this configuration :
<security-domain name="host" cache-type="default">
<authentication>
<login-module code="Kerberos" flag="required">
<module-option name="storeKey" value="true"/>
<module-option name="useKeyTab" value="true"/>
<module-option name="principal" value="HTTP/{testserver}"/>
<module-option name="keyTab" value="/home/username/service.keytab"/>
<module-option name="doNotPrompt" value="true"/>
<module-option name="debug" value="false"/>
</login-module>
</authentication>
</security-domain>
where {testserver} is the FQDN of the machine.
--------------------------------------------------
11 years, 5 months
