[JBoss AS 7 Development] - Remote EJB/JMS JBoss AS 7.1.1 problem
by brunothebear
brunothebear [https://community.jboss.org/people/brunothebear] created the discussion
"Remote EJB/JMS JBoss AS 7.1.1 problem"
To view the discussion, visit: https://community.jboss.org/message/779066#779066
--------------------------------------------------------------
Hello,
Past couple of weeks ive been trying to migrate project from JBoss 4.2.2GA to JBoss 7 AS. Everything went pretty much fine till i hit the remoting part on which I've stuck for a quite time now.
In JBoss 4.2.2 project uses custom login module to authenticate remote calls.
The promblem is that i have trouble to get the username/password to the server so the user can eb authenticated.
Ive somewhat sorted otu the EJB invocation and i do it like this.
standalone.xml
<security-realms>
...
<security-realm name="TESTRealm">
<authentication>
<jaas name="testdomain"/>
</authentication>
</security-realm>
</security-realms>
....
<subsystem xmlns="urn:jboss:domain:remoting:1.1">
<connector name="remoting-connector" socket-binding="remoting" security-realm="TESTRealm"/>
</subsystem>
<subsystem xmlns="urn:jboss:domain:security:1.1">
<security-domains>
<security-domain name="other">
<authentication>
<login-module code="UsersRoles" flag="required"/>
</authentication>
</security-domain>
<security-domain name="jboss-web-policy">
<authorization>
<policy-module code="Delegating" flag="required"/>
</authorization>
</security-domain>
<security-domain name="jboss-ejb-policy">
<authorization>
<policy-module code="Delegating" flag="required"/>
</authorization>
</security-domain>
<security-domain name="testdomain">
<authentication>
<login-module code="com.test.proj.CustomLoginModule" flag="required">
<module-option name="password-stacking" value="useFirstPass"/>
<module-option name="hashAlgorithm" value="MD5"/>
<module-option name="hashEncoding" value="hex"/>
<module-option name="ignorePasswordCase" value="true"/>
</login-module>
</authentication>
</security-domain>
</security-domains>
</subsystem>
Client part:
Hashtable< String, Object>props = new Hashtable< String, Object>();
props.put("jboss.naming.client.ejb.context", true);
props.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
final String firstPassword = new String(password);
org.jboss.as.naming.InitialContext ctx = new org.jboss.as.naming.InitialContext();
Properties jbossProperties = new Properties();
jbossProperties.load(EjbSupportImpl.class.getResourceAsStream("/jboss-ejb-client.properties"));
jbossProperties.put("remote.connection.default.username", name);
jbossProperties.put("remote.connection.default.password", firstPassword);
final EJBClientConfiguration ejbClientConfiguration = new PropertiesBasedEJBClientConfiguration(jbossProperties);
final ContextSelector<EJBClientContext> ejbClientContextSelector = new ConfigBasedEJBClientContextSelector(ejbClientConfiguration);
EJBClientContext.setSelector(ejbClientContextSelector);
final String jndiName = "ejb:ear/ejb-module/TestBean!com.test.proj.TestBean?stateful";
final Object o = ctx.lookup(jndiName);
TestBean test= (TestBean) o;
test.testMethod();
jboss-ejb-client-properties:
remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
remote.connections=default
remote.connection.default.host=localhost
remote.connection.default.port=4447
remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=true
remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT=false
remote.connection.default.connect.options.org.xnio.Options.SASL_DISALLOWED_MECHANISMS=JBOSS-LOCAL-USER
With all the above everything works fine, the part that bothers me is this
org.jboss.as.naming.InitialContext ctx = new org.jboss.as.naming.InitialContext();
if i use javax.naming.InitialContext instead of JBoss
i get
javax.naming.NamingException: Failed to create remoting connection [Root exception is java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed]
at org.jboss.naming.remote.client.ClientUtil.namingException(ClientUtil.java:36)
at org.jboss.naming.remote.client.InitialContextFactory.getInitialContext(InitialContextFactory.java:121)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288)
at javax.naming.InitialContext.init(InitialContext.java:223)
at javax.naming.InitialContext.<init>(InitialContext.java:197)
at com.point_fi.tms.client.communication.EjbSupport.newInitialContext(EjbSupport.java:162)
at com.point_fi.tms.client.communication.EjbSupportImpl$MyLoginService.authenticate(EjbSupportImpl.java:243)
at com.point_fi.tms.client.communication.EjbSupportImpl.login(EjbSupportImpl.java:179)
at com.point_fi.tms.client.communication.EjbSupportImpl.getInstance(EjbSupportImpl.java:64)
at com.point_fi.tms.client.Application.<init>(Application.java:35)
at com.point_fi.tms.client.Application.getInstance(Application.java:59)
at com.point_fi.tms.client.TMSClient.main(TMSClient.java:51)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
Caused by: java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
at org.jboss.naming.remote.protocol.IoFutureHelper.get(IoFutureHelper.java:87)
at org.jboss.naming.remote.client.NamingStoreCache.getRemoteNamingStore(NamingStoreCache.java:56)
at org.jboss.naming.remote.client.InitialContextFactory.getOrCreateCachedNamingStore(InitialContextFactory.java:166)
at org.jboss.naming.remote.client.InitialContextFactory.getOrCreateNamingStore(InitialContextFactory.java:139)
at org.jboss.naming.remote.client.InitialContextFactory.getInitialContext(InitialContextFactory.java:104)
... 16 more
no errors on serverside.
Anyways im ok with using method above for EJBs but then the problem comes with remote JMS where i cant acquire the connection factory i require from server via JNDI
Connection factory in standalone.xml
<connection-factory name="RemoteConnectionFactory">
<connectors>
<connector-ref connector-name="netty"/>
</connectors>
<entries>
<entry name="RemoteConnectionFactory"/>
<entry name="java:jboss/exported/jms/RemoteConnectionFactory"/>
</entries>
</connection-factory>
and the way i trie to look it up
Hashtable<String, Object> env = new Hashtable<String, Object>();
env.put(Context.INITIAL_CONTEXT_FACTORY,"org.jboss.naming.remote.client.InitialContextFactory");
env.put(Context.PROVIDER_URL, System.getProperty(Context.PROVIDER_URL,"remote://localhost:4447"));
env.put(Context.SECURITY_PRINCIPAL, "test");
env.put(Context.SECURITY_CREDENTIALS, "123456");
InitialContext ctx = new InitialContext(env);
String connectionFactoryString = "jms/RemoteConnectionFactory";
ConnectionFactoryconnectionFactory = (ConnectionFactory) ctx.lookup(connectionFactoryString);
In which case im getting exception like the one above
javax.naming.NamingException: Failed to create remoting connection [Root exception is java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed]
Can anyone help me figure out how to properly get the ConnectionFactories/queues etc.. via remote JDNI?
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/779066#779066]
Start a new discussion in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
11 years, 4 months
[JBoss AS 7 Development] - Experimenting with Single Installation Patching
by Brian Stansberry
Brian Stansberry [https://community.jboss.org/people/brian.stansberry] 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.
To actually apply the patch, the installation being patched needs to actually be running. It can be running a standalone server or the managed domain processes; either is ok. It can be running normally or in --admin-only mode.
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, connecting it to the target process 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
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. 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, 5 months
[JBoss AS 7 Development] - Jboss 7.1.1 as having problems with Picketlink 2.0.3-Final for CXF endpoints
by biswa mishra
biswa mishra [https://community.jboss.org/people/mishra900] created the discussion
"Jboss 7.1.1 as having problems with Picketlink 2.0.3-Final for CXF endpoints"
To view the discussion, visit: https://community.jboss.org/message/779019#779019
--------------------------------------------------------------
I am trying to develop apache CXF web service endpoints using Picketlink 2.0.3-Final.jar and deploying in Jboss 7.1.1 AS.
I have updated Jboss 7.1.1 As org.picketlink modules with Picketlink 2.0.3-Final.jars as mentioned in some of the links in forum . all the examples are getting deployed and working as expected .
I am planning to deploy my CXF web services as .war file in Jboss Standalone deployment . i have added <extension module="org.picketlink"/> in the standalone.xml
So it means , if i will deploy *.war file , i donot need to add picketlink 2.0.3-final related jars in to web-inf\lib folder , but looks like WAR file got deployed but not started ....
Hence i have added picketlink 2.0.3-final related jars in to web-inf\lib folder , and redeployed , now WAR file got deployed and started also and i am able to see CXF endpoints started also like below :
21:30:41,029 INFO [org.jboss.wsf.stack.cxf.metadata.MetadataBuilder] (MSC service thread 1-4) Add Service
id=org.picketlink.identity.federation.core.wstrust.PicketLinkSTS
address=http://localhost:8080/security-token-service/PicketLinkSTS
implementor=org.picketlink.identity.federation.core.wstrust.PicketLinkSTS
invoker=org.jboss.wsf.stack.cxf.JBossWSInvoker
serviceName={urn:picketlink:identity-federation:sts}PicketLinkSTS
portName={urn:picketlink:identity-federation:sts}PicketLinkSTSPort
wsdlLocation=null
mtomEnabled=false
21:30:41,044 INFO [org.jboss.wsf.stack.cxf.metadata.MetadataBuilder] (MSC service thread 1-4) Add Service
id=org.picketlink.identity.federation.core.pdp.SOAPSAMLXACMLPDP
address=http://localhost:8080/security-token-service/SOAPSAMLXACMLPDP
implementor=org.picketlink.identity.federation.core.pdp.SOAPSAMLXACMLPDP
invoker=org.jboss.wsf.stack.cxf.JBossWSInvoker
serviceName={urn:picketlink:identity-federation:pdp}SOAPSAMLXACMLPDP
portName={urn:picketlink:identity-federation:pdp}SOAPSAMLXACMLPort
wsdlLocation=null
mtomEnabled=false
*But Immediately it got failed throwing the below exception like PL00075: File could not be located :policyConfig.xml*
09:31:43,712 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (MSC service thread 1-4) Creating Service {urn:picketlink:identity-federation:sts}PicketLinkSTS from WSDL: WEB-INF/wsdl/PicketLinkSTS.wsdl
09:31:50,163 INFO [org.apache.cxf.endpoint.ServerImpl] (MSC service thread 1-4) Setting the server's publish address to be http://localhost:8080/security-token-service/PicketLinkSTS
09:31:52,303 INFO [org.jboss.wsf.stack.cxf.deployment.WSDLFilePublisher] (MSC service thread 1-4) WSDL published to: file:/C:/jboss/jboss-as-7.1.0.Final/standalone/data/wsdl/security-token-service.war/PicketLinkSTS.wsdl
09:31:53,358 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC00001: Failed to start service jboss.deployment.unit."security-token-service.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."security-token-service.war".INSTALL: Failed to process phase INSTALL of deployment "security-token-service.war"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:119) [jboss-as-server-7.1.0.Final.jar:7.1.0.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_29]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_29]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29]
Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: PL00075: File could not be located :policyConfig.xml
at org.jboss.wsf.stack.cxf.configuration.NonSpringBusHolder.newInstance(NonSpringBusHolder.java:174)
at org.jboss.wsf.stack.cxf.configuration.NonSpringBusHolder.configure(NonSpringBusHolder.java:96)
at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.startDeploymentBus(BusDeploymentAspect.java:113)
at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.start(BusDeploymentAspect.java:66)
at org.jboss.as.webservices.deployers.AspectDeploymentProcessor.deploy(AspectDeploymentProcessor.java:81)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113) [jboss-as-server-7.1.0.Final.jar:7.1.0.Final]
... 5 more
Caused by: java.lang.IllegalStateException: PL00075: File could not be located :policyConfig.xml
at org.picketlink.identity.federation.core.pdp.SOAPSAMLXACMLPDP.getPDP(SOAPSAMLXACMLPDP.java:115)
at org.picketlink.identity.federation.core.pdp.SOAPSAMLXACMLPDP.<init>(SOAPSAMLXACMLPDP.java:75)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.6.0_29]
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) [rt.jar:1.6.0_29]
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) [rt.jar:1.6.0_29]
at java.lang.reflect.Constructor.newInstance(Constructor.java:513) [rt.jar:1.6.0_29]
at java.lang.Class.newInstance0(Class.java:355) [rt.jar:1.6.0_29]
at java.lang.Class.newInstance(Class.java:308) [rt.jar:1.6.0_29]
at org.jboss.wsf.stack.cxf.configuration.NonSpringBusHolder.newInstance(NonSpringBusHolder.java:170)
... 10 more
This looks to me more on support issues with jboss 7.1.1 AS with Picketlink using CXF endpoints ... , any tips from the Jboss Security team will be really helpful ..
Even i have tried with Jboss 7.1.0 As using Picketlink 2.0.2 -final build , same issue persists
Thanks,
Biswa
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/779019#779019]
Start a new discussion in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
11 years, 5 months
[JBoss AS 7 Development] - Logging Id's
by Brian Stansberry
Brian Stansberry [https://community.jboss.org/people/brian.stansberry] modified the document:
"Logging Id's"
To view the document, visit: https://community.jboss.org/docs/DOC-16810
--------------------------------------------------------------
Logging id ranges for JBoss AS7 i18n message interfaces.
|| %1,3% *Status* ||
| C | = | Complete |
| I | = | In Progress |
| P | = | Merged, but not complete |
| W | = | Waiting Merge |
|| *Range* || *Subsystem
* || *Status
* ||
| *10100 - 10199* | *Transaction* | C |
| *10200 - 10399
* | *Clustering**
* | C |
| *10400 - 10499* | *Connector**
* | C |
| *10500 - 10599* | *CLI (not applicable)
* | N/A |
| *10600 - 10699* | *Controller Client* | C |
| *10700 - 10799*, *18500 - 18699, 18800-18999* | *CMP* | C |
| *10800 - 10899* | *Host Controller (domain packages)* | C |
| *10900 - 10999, 16500 - 16599* | *Host Controller (host packages)* | C |
| *11000 - 11099, 16700 - 16799* | *EE* | C |
| *11100 - 11199* | *Embedded* | C |
| *11200 - 11299* | *JAXRS* | C |
| *11300 - 11399* | *JMX* | C |
| *11400 - 11499* | *JPA* | C |
| *11500 - 11599* | *Logging* | C |
| *11600 - 11699* | *Messaging* | C |
| *11700 - 11799* | *mod_cluster* | C |
| *11800 - 11899* | *Naming* | C |
| *11900 - 11999* | *OSGi* | C |
| *12000 - 12099, 16600 - 16699* | *Process Controller* | C |
| *12100 - 12199* | *Protocol* | C |
| *12200 - 12299* | *Management Client Content* | C |
| *12300 - 12399* | *Platform MBeans* | C |
| *12400 - 12499* | *Threads* | C |
| *12500 - 12599* | *PicketLink* | I |
| *12600 - 12699* | *JSF (proposed)* |
|
| *12700 - 13100* | *IIOP Common (proposed)* |
|
| *13100 - 13199* | *JDR* | C |
| *13200 - 13299* | *AppClient* | C |
| *13300 - 13399* | **Security*
* | C |
| available block(s) |
|
|
| *14000 - 14099* | *JAXR* | W |
| *14100 - 14599* | *Ejb3* | P |
| *14600 - 14899* | *Controller* | C |
| *14900 - 14999* | *Deployment Repository* | C |
| *15000 - 15099* | *Deployment Scanner* | C |
| *15100 - 15199* | *Domain Management HTTP Interface* | C |
| *15200 - 15299* | *Deployment Management* | C |
| *15300 - 15399* | *Network* | C |
| *15400 - 15499* | *Mail* | C |
| *15500 - 15699* | *Web Services (AS subsystem)* | C |
| *15700 - 15999*, *18700 - 18799* | *Server* | C |
| *1**6000 - 16099* | *Weld* | C |
| *16100 - 16199* | *EE Deployment* | C |
| *16200 - 16299* | *Configadmin* | C |
| *16300 - 16499* | *Jacorb* | C |
| *10900 - 10999, 16500 - 16599* | *Host Controller (host packages)* | C |
| *12000 - 12099, 16600 - 16699* | *Process Controller* | C |
| *11000 - 11099, 16700 - 16799* | *EE* | C |
| *16800 - 16899* | *Patching (Library)* | C |
| *16900 - 16999* | *Patching (Server)* |
|
| *17000 - 17099* | *POJO* | C |
| *17100 - 17199* | *Remoting* | W |
| *17200 - 17299* | *SAR* | W |
| *17300 - 17699* | *Web (reserved)* | I |
| *18000 - 18399* | *Web* | C |
| *18400 - 18499* | *Xts* | C |
| *15700 - 15999, 18700 - 18799* | *Server* | C |
| *19000-19999* | *JSR-77* | I |
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-16810]
Create a new document in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
11 years, 5 months
[JBoss AS 7 Development] - Configuring jboss7 ajp connector timeout
by Nandish A
Nandish A [https://community.jboss.org/people/nandish] created the discussion
"Configuring jboss7 ajp connector timeout"
To view the discussion, visit: https://community.jboss.org/message/778930#778930
--------------------------------------------------------------
I am setting up Jboss7 to work with apache http using ajp.
My server.xml has the following entry to open ajp port
<subsystem xmlns="urn:jboss:domain:web:1.1" native="false" default-virtual-server="default-host">
<connector name="http" protocol="HTTP/1.1" scheme="http" port="8080"/>
<connector name="ajp" protocol="AJP/1.3" port=8009 enabled="true" />
<virtual-server name="default-host" enable-welcome-root="false">
<alias name="localhost"/>
<alias name="example.com"/>
</virtual-server>
</subsystem>
However when i try adding connectionTimeOut="10000" after port definition, I get the following error in boot.log
> Caused by:
> org.jboss.as.controller.persistence.ConfigurationPersistenceException:
> JBAS014676: Failed to parse configuration at
>
> org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:125)
> [jboss-as-controller-7.1.0.Final.jar:7.1.0.Final] at
>
> org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:187)
> [jboss-as-controller-7.1.0.Final.jar:7.1.0.Final] at
> org.jboss.as.server.ServerService.boot(ServerService.java:261)
> [jboss-as-server-7.1.0.Final.jar:7.1.0.Final] at
> org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:155)
> [jboss-as-controller-7.1.0.Final.jar:7.1.0.Final] ... 1 more Caused
> by: javax.xml.stream.XMLStreamException: ParseError at
> [row,col]:[411,13] Message: JBAS014788: Unexpected attribute
> 'connectionTimeout' encountered at
> org.jboss.as.controller.parsing.ParseUtils.unexpectedAttribute(ParseUtils.java:104)
> [jboss-as-controller-7.1.0.Final.jar:7.1.0.Final] at
> org.jboss.as.web.WebSubsystemParser.parseConnector(WebSubsystemParser.java:831)
> at
> org.jboss.as.web.WebSubsystemParser.readElement(WebSubsystemParser.java:389)
> at
> org.jboss.as.web.WebSubsystemParser.readElement(WebSubsystemParser.java:60)
> at
> org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
> [staxmapper-1.1.0.Final.jar:1.1.0.Final] at
> org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69)
> [staxmapper-1.1.0.Final.jar:1.1.0.Final] at
> org.jboss.as.server.parsing.StandaloneXml.parseServerProfile(StandaloneXml.java:893)
> [jboss-as-server-7.1.0.Final.jar:7.1.0.Final] at
> org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_1(StandaloneXml.java:329)
> [jboss-as-server-7.1.0.Final.jar:7.1.0.Final] at
> org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:126)
> [jboss-as-server-7.1.0.Final.jar:7.1.0.Final] at
> org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:100)
> [jboss-as-server-7.1.0.Final.jar:7.1.0.Final] at
> org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
> [staxmapper-1.1.0.Final.jar:1.1.0.Final] at
> org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69)
> [staxmapper-1.1.0.Final.jar:1.1.0.Final] at
> org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:117)
> [jboss-as-controller-7.1.0.Final.jar:7.1.0.Final] ... 4 more
>
> 15:47:20,423 INFO [org.jboss.as] JBAS015950: JBoss AS 7.1.0.Final "Thunder" stopped in 29ms
My question is how do we configure timeout in jboss7.
I folllowed http://docs.jboss.org/jbossweb/latest/config/ajp.html http://docs.jboss.org/jbossweb/latest/config/ajp.html and I could not make out the configuration required in server.xml .
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/778930#778930]
Start a new discussion in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
11 years, 5 months
[PicketBox Development] - JBoss AS7 Security Auditing
by Peter Skopek
Peter Skopek [https://community.jboss.org/people/pskopek] modified the document:
"JBoss AS7 Security Auditing"
To view the document, visit: https://community.jboss.org/docs/DOC-17277
--------------------------------------------------------------
h2.
h2. Configure the Domain Model Logging Subsystem
<subsystem xmlns="urn:jboss:domain:logging:1.1">
<console-handler name="CONSOLE" autoflush="true">
<level name="INFO"/>
<formatter>
<pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
</formatter>
</console-handler>
<periodic-rotating-file-handler name="FILE" autoflush="true">
<level name="INFO"/>
<formatter>
<pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
</formatter>
<file relative-to="jboss.server.log.dir" path="server.log"/>
<suffix value=".yyyy-MM-dd"/>
<append value="true"/>
</periodic-rotating-file-handler>
<periodic-rotating-file-handler name="AUDIT" autoflush="true">
<level name="TRACE"/>
<formatter>
<pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
</formatter>
<file relative-to="jboss.server.log.dir" path="audit.log"/>
<suffix value=".yyyy-MM-dd"/>
<append value="true"/>
</periodic-rotating-file-handler>
<logger category="org.jboss.security.audit">
<level name="TRACE"/>
<handlers>
<handler name="AUDIT"/>
</handlers>
</logger>
<logger category="com.arjuna">
<level name="WARN"/>
</logger>
<logger category="org.apache.tomcat.util.modeler">
<level name="WARN"/>
</logger>
<logger category="sun.rmi">
<level name="WARN"/>
</logger>
<root-logger>
<level name="INFO"/>
<handlers>
<handler name="CONSOLE"/>
<handler name="FILE"/>
</handlers>
</root-logger>
</subsystem>
The key changes to the logging subsystem are:
* A new logger category for "org.jboss.security.audit.providers.LogAuditProvider" is defined.
* A periodic rotating file handler called "AUDIT" is defined.
h2. Web Applications
To enable auditing in your web applications, please configure your jboss-web.xml for your web archive. The <disable-audit> flag should be set to false.
<?xml version="1.0" encoding="UTF-8"?>
<jboss-web>
<security-domain>form-auth</security-domain>
<disable-audit>false</disable-audit>
</jboss-web>
h2.
h2. Quick Testing
1. Attached is the form-auth.war. Deploy it in standalone/deployments
2. Make the standalone/configuration/standalone.xml changes to the logging subsystem as defined above.
3. Start JBoss AS7
4. Access http://localhost:8080/form-auth/ http://localhost:8080/form-auth/ (User: anil Password: anil)
5. If things are working, you should see audit.log under standalone/log
1:32:27,751 TRACE [org.jboss.security.audit.providers.LogAuditProvider] (http--127.0.0.1-8080-1) [Success]principal=GenericPrincipal[anil(user,)];
Note: You will need the following security domain added to standalone.xml
<security-domain name="form-auth" cache-type="default">
<authentication>
<login-module code="UsersRoles" flag="required">
<module-option name="usersProperties" value="users.properties"/>
<module-option name="rolesProperties" value="roles.properties"/>
</login-module>
</authentication>
</security-domain>
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-17277]
Create a new document in PicketBox Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
11 years, 5 months