[JBoss AS 7 Development] - AS 7 Internal Architecture Overview
by Brian Stansberry
Brian Stansberry [https://community.jboss.org/people/brian.stansberry] modified the document:
"AS 7 Internal Architecture Overview"
To view the document, visit: https://community.jboss.org/docs/DOC-47970
--------------------------------------------------------------
h2. High Level Overview
At a coarse level, AS 7 consists of two main elements:
* A core manageable service container based on modular classloading
* Extensions to that core that provide the kind of functionality most users associate with an application server, like handling HTTP requests and managing transactions
The AS distribution also includes two clients for the management interfaces it exposes (a CLI tool and a web-based admin console). The AS codebase also produces implementations of the SPIs published by the Arquillian project, allowing AS7 servers to run Arquillian-based tests.
h3. AS Core
The core of the AS consists of the following primary elements:
* A modular classloading system provided by the jboss-modules library
* A fast, highly scalable service container framework provided by the jboss-msc library
* An extensible management layer that is meant to mediate access to the service container by logic that wants to add, remove and modify services. The management layer also provides a consistent, persistent, configuration model for the AS. The management layer involves* core elements, via the jboss-dmr library and the AS codebase's own controller, controller-client, deployment-repository, domain-management and network modules as well as parts of the server module
* remote management capability via the protocol and domain-http modules
* multi-server managed domains via the process-controller and host-controller modules
* miscellaneous elements provided via the managment-client-content and platform-mbean modules
* A deployment framework for coordinating installation of deployment content into the runtime. This is one of the things provided by the server module.
h3. AS Extensions
Most of the functionality that end users associate with an application server is provided AS extensions. Most of the modules in the AS7 codebase are extension implementations, with each extension providing a coherent set of functionality. Many extensions provide support for some aspect of the Java EE specifications.
Extensions implement an interface (org.jboss.as.controller.Extension) that allows integration with the core AS management layer. Via that mechanism, extensions are able to
* participate in the parsing and marshalling of the AS's configuration documents
* register resources and operations to be exposed via the AS's management API
* install services into the AS's service container
* register deployment unit processors with the AS's deployment framework
See the " https://docs.jboss.org/author/display/AS72/Extending+JBoss+AS+7 Extending JBoss AS 7" document for more on extensions. See also https://community.jboss.org/docs/DOC-25627 https://community.jboss.org/docs/DOC-25627 for more on how extending AS 7 differs from extending previous versions of JBoss AS.
h2. AS7 Boot Process
To better illustrate the AS 7 architecture, let's walk through the boot process for a standalone server.
h3. Primordial Boot
When you run bin/standalone.sh from the root of the AS 7 distribution, the final effect is to launch a JVM using the following essential command
java -jar jboss-modules.jar -mp modules org.jboss.as.standalone
If you start the AS and use the ps command to see the actual JVM launch command, you'll see a lot of JVM settings (-Xmx and the like) and a lot of system property settings, but the above bits are the key information. Let's break that down a bit:
java -jar jboss-modules.jar
We can see from this that the actual main class the VM will invoke isn't in a JBoss AS library at all; it's in jboss-modules.jar (specifically, the org.jboss.modules.Main class.) So, when you start the AS the first thing you are doing is setting up a modular classloading environment.
-mp modules
These are arguments passed to org.jboss.modules.Main.main(). The -mp is short for "module path" and the value is a path somewhat analogous to the value of an OS $PATH environment variable. Each item in the path is a location under which jboss-modules will look for a module when needed. If there is more than one item in the path, the items are searched in order, with the search ending as soon as the module is found. In this case there is only one item in the path -- the modules/ dir under the AS distribution root.
org.jboss.as.standalone
This is the name of a module located on the module path. This module will be loaded by jboss-modules. If you look in the modules/org/jboss/as/standalone/main/module.xml file in the AS distribution, you will see it includes this element:
<main-class name="org.jboss.as.server.Main"/>
When jboss-modules sees that element in the module.xml for the module passed to its main() method, it knows to load the specified class and to pass any remaining command line arguments into +its+ main() method. So, now we have a modular classloading enviroment set up, and the org.jboss.as.server.Main.main() method (found in the AS codebase's server module) has been invoked.
The org.jboss.as.server.Main.main() method does a number of things, but two are most relevant for people who wish to understand how to develop the AS:
* Any remaining command line arguments are processed and an instance of the ServerEnvironment is created. This object encapsulates environmental information available via the command line or system properties; things like where the root of the AS dist is; where the root of the server instance is; where the configuration file is, etc. Later this information is made available to all services in the system via the ServerEnvironmentService.
* An object implementing the Bootstrap interface (specifically, the org.jboss.as.server.BootstrapImpl class) is created and configured and its bootstrap() method is invoked.
h3. Service-based Boot
The most important thing BootstrapImpl does is create an instance of the JBoss MSC library's ServiceContainer interface. A service container manages a set of running services. A service is simply a thing that can be started and stopped, with start and stop performed via methods specified in the JBoss MSC Service interface. A service also exposes a value of some type T via the Service interface's public T getValue() method. The value type T specified by the service is used by default by consumers of the service, and should represent the public interface of the service. It may or may not be the same as the implementing type of the service.
The ServiceContainer provides an API for managing services -- configuring and installing them, removing them, triggering start and stop, looking up already installed services, etc. Configuring a service can involve expressing the dependencies the service has on other services and asking that the service container inject the value of depended-upon services into the service before starting it. If a service depends upon another service, that other service must be successfully started before the service container will invoke the dependent service's start method. If for some reason the depended-upon service needs to be stopped, the service container will invoke the dependent service's stop method first.
The ServiceContainer maintains an internal thread pool. In order to achieve highly performant management of large numbers of inter-related services, activities related to starting and stopping services are performed as a series of concisely scoped tasks, with the threads in the thread pool used to execute those tasks. For example, executing a service's start method would be a task performed by a thread in the ServiceContainer's thread pool. Because of this fact, +it is important to recognize that any activity related to starting and stopping services will be highly multi-threaded. For example, you can never assume that the thread that asks the service container to install a service will be the thread that calls its start method.+
So, at this point in our boot, we have in place two of the four main architectural elements discussed in the "AS Core" section of the "High Level Overview" above: a modular classloading environment provided by the jboss-modules library, and a service container framework provided by the jboss-msc library.
Up to this point in the AS boot, all activity has been on a single thread, the JVM's main thread. In the BootstrapImpl.bootstrap() method, things get more interesting, since much of the remaining boot work involves installing services, with the ServiceContainer's thread pool threads doing the most of that work.
BootstrapImpl.bootstrap() installs two services:
* ControlledProcessStateService. This service provides access to a simple enum value showing the current running state of the server (STARTING, STOPPING, RUNNING, RESTART_REQUIRED, RELOAD_REQUIRED). This is the only service that once started should not be stopped until the VM is being shut down.
* ApplicationServerService. This is the root service for the application server; all other services in one way or another depend upon it. When you use the CLI to perform the :reload operation, the server handles that request by telling the service container to stop this service, which has the effect of stopping all other services that depend upon it. Then once it is stopped, the service container is told to start the service again.
The ApplicationServerService starts a number of other services in its start method. The most significant of these is the ServerService.
h3. The ServerService and the Controller Boot Thread
ServerService brings in the 3rd and 4th of the four primary components of the core AS listed in the "High Level Overview" above -- the extensible management layer and the deployment framework. For those of you familiar with the " https://docs.jboss.org/author/display/AS72/Extending+JBoss+AS+7 Extending JBoss AS 7" document, ServerService performs many of the same kinds of activities an Extension implementation performs in its initialize(ExtensionContext context) method, but for the core AS management model:
* registers resource definitions, attribute definitions and OperationStepHandlers for the core AS managed resources
* registers core DeploymentUnitProcessors
ServerService implements Service<ModelController>. A ModelController is the central execution point for management operations in a managed AS process (i.e. a server or a HostController in a managed domain.)
In its start method, ServerService spawns a separate thread, the "Controller Boot Thread", which is responsible for coordinating the remainder of the boot. It does the following primary tasks
* Triggers the parsing of the server configuration file (e.g. standalone.xml) into a list of management operations that should be executed by the ModelController to bring the server's running configuration in line with the xml configuration
* Passes those management operations into the ModelController's execute method. The ModelController uses the Controller Boot Thread to handle execution of many of the steps involved in handling those operations.
* Blocks until all services added into the runtime as part of handling those management ops have either started or failed to start.
* Logs the completion of boot.
The tasks of the Controller Boot Thread are spelled out in further detail below.
h4. XML Parsing, Extension Loading, Extension Parsing Initialization
The task of an XML parser for an AS7 configuration document (e.g. standalone.xml, domain.xml, host.xml) is to populate a list of management operations that should be executed by the ModelController to bring the process' running configuration in line with the xml. Each of those management operations has the same format as would be read off the wire if the CLI had sent an operation request to the server to invoke an equivalent operation.
The parser for the core AS xml namespace has some special behavior when it comes to parsing an <extension> element in the xml:
* The name attribute of the element is the name of a JBoss Modules module that contains an implementation of the org.jboss.as.controller.Extension interface
* Once the name is parsed, the parser asks JBoss Modules to load the module
* Once the module is loaded, the java.lang.ServiceLoader mechanism is used to load the module's implementation of the Extension interface.
* The initializeParsers(ExtensionParsingContext context) method on that Extension implementation is invoked. That allows the extension to register XML parsers for the XML namespaces supported by the subsystem(s) the extension provides.
* When the core AS xml parser subsequently encounters a <subsystem> element in the configuration document, the xml namespace of the element is determined, and the appropriate parser registered by some Extension is used to parse that portion of the document.
h4. Execution of Boot Management Operations, Extension Initialization
Once xml parsing is complete, a list of management operations is ready for execution by the ModelController. Each operation has the same format (address, operation name, parameters) as would be read off the wire if the CLI had sent an operation request to the server to invoke an equivalent operation after boot. The Controller Boot Thread asks the ModelController to execute the operations as a unit, with each individual operation acting as a step in the overall unit of work. Execution proceeds in 3 stages, with all steps in the overall unit completing a stage before execution on the next stage begins. (This execution pattern applies whenever any operation or atomic list of operations is invoked, not just during boot.)
* Stage MODEL -- the OperationStepHandler registered for each operation makes necessary updates to the server's internal configuration model, and, if necessary, registers a handler for the same operation for Stage RUNTIME.
* Stage RUNTIME -- any OperationStepHandler registered in Stage MODEL for an operation accesses the JBoss MSC ServiceContainer and installs/removes/updates any relevant services. The ServiceContainer has its own thread pool and uses it to perform the necessary tasks to start and stop services. The thread executing the OperationStepHandler does not do this directly, and the handler implementation needs to recognize that service start/stop will be asynchronous.
* Stage VERIFY -- A Stage.MODEL or Stage.RUNTIME handler can register a Stage.VERIFY handler that will only run once the ServiceContainer had completed all service modifications made in stage RUNTIME. A VERIFY handler can check that the runtime service changes completed successfully.
Before the list of boot operations is passed into the ModelController, a check is done for operations that add extension resources (for example, using CLI syntax, /extension=org.foo.extension:add.) When one is found, the relevant Extension implementation's initialize(ExtensionContext context) method is invoked. This gives the Extension a chance to register its resource and attribute definitions and its OperationStepHandlers with the core AS management layer before the boot operations are executed.
h4. Wait for Service Container Stability and Boot Completion
The final steps in the AS 7 boot are to wait while the JBoss MSC ServiceContainer processes the installation and start of all the services added by the handlers for the boot operations. As discussed in the introduction to the ServiceContainer above, the start of services is performed by threads in the ServiceContainer's internal thread pool. Services are not started by the Controller Boot Thread. However, the ServerService attaches a listener to the controller object for each service; using this the ServerService is able to track when all services have reached a stable state. The Controller Boot Thread uses this facility to block until the ServiceContainer has stabilized. At that point, all services are either started or failed, and boot is nearly complete. The Controller Boot Thread switches the state of the ControlledProcessState service from STARTING to RUNNING, writes a log message reporting that the boot is complete, and boot is finished.
h2. Deployment Processing
When you trigger deployment of some content, one of the management operations supported by the core AS management layer is invoked. The logic responsible for handling that operation will extract relevant information from the operation request (e.g. the name of the deployment) and will then install services into the AS's service container:
* A Service<VirtualFile> implementation that provides an org.jboss.vfs.VirtualFile that represents the deployment content.
* A Service<DeploymentUnit> (in this case RootDeploymentUnitService) that provides a DeploymentUnit for the deployment. A DeploymentUnit retains data which is persistent for the life of the deployment, and will later be passed into the various DeploymentUnitProcessor implementations that perform various actions to install the runtime services needed by the deployment.
The RootDeploymentUnitService has injected into it a reference to all the DeploymentUnitProcessor (DUP) implementations that were registered by the core ServerService at boot or that have been registered by subsystems. The DUP implementations are grouped by the Phase of the deployment process in which they execute, and are numerically ordered within that phase. DeploymentUnitProcessors are organized in a chain fashion, with each DUP performing a limited set of tasks to help take a deployment from being a bunch of bits to being a set of useful services.
Deployment proceeds in phases. See the https://github.com/jbossas/jboss-as/blob/master/server/src/main/java/org/... Phase enum for a listing of the phases. For each phase, a DeploymentUnitPhaseService representing that phase that is installed into the service container. Each phase service (save the first) depends on the phase service for the previous phase, and each phase service (save the last) in its start method installs the phase service for the next phase. The RootDeploymentUnitService in its start method installs the first phase service, which in turn depends on it the RootDeploymentUnitService. The effect of all this is if the RootDeploymentUnitService is stopped (e.g. by the undeploy management operation), this will trigger a requirement for the service container to first stop the first phase service, which will in turn trigger a requirement to first stop the next phase service, and so on all the way to the final phase service. The effect is the phase services will be stopped in reverse order from how they were started.
The primary thing the phase services do in their start and stop methods is invoke the deploy and undeploy methods of each DeploymentUnitProcessor registered for their phase. The deploy method is invoked in phase service start and the undeploy method is invoked in stop. For each deploy/undeploy call the DUP is provided with a DeploymentPhaseContext that provides context to the call and gives the DUP access to the service container, allowing it to install or remove services.
h3. Deployment Processing and Modules
One of the tasks performed by the DeploymentUnitProcessors is to set up the modular classloading enviroment for the deployment. Each top-level deployment has its own dynamically generated module. For deployment types that include known subdeployments (e.g. an ear can include wars, ejb jars, etc) then in addition those subdeployments also get their own dynamically generated module. What other modules these deployment modules have visibility to depends on the requirements determined by the deployment framework when it analyzes the deployment content (e.g. by parsing deployment descriptors, reading manifests, or scanning annotations.)
The key actor in this process is the org.jboss.as.server.deployment.module.ModuleSpecProcessor, which is a DeploymentUnitProcessor. The ModuleSpecProcessor configures and installs an MSC service that interacts with jboss-modules to dynamically generate the deployment's module. Other DeploymentUnitProcessors that execute prior to ModuleSpecProcessor analyze the content of the deployment and add contextual information to the DeploymentUnit that is used by ModuleSpecProcessor to establish what other modules the deployment's module can access. So, for example, a DUP registered by the JPA subsystem might recognize that the deployment requires JPA support (e.g. by detecting the presence of a persistence.xml file) and record that visibility to the modules that provide the JPA APIs should be added. The effect of all this is the deployment's classes have access to an appropriate set of classes located in the AS's own modules or in other deployments, but do not have access to classes located in other modules.
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-47970]
Create a new document in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
11 years, 9 months
[JBoss Tools Development] - How To Build JBoss Tools 4.1 FAQ
by Nick Boldt
Nick Boldt [https://community.jboss.org/people/nickboldt] modified the document:
"How To Build JBoss Tools 4.1 FAQ"
To view the document, visit: https://community.jboss.org/docs/DOC-48358
--------------------------------------------------------------
>
https://community.jboss.org/4.5.6/images/tiny_mce3/plugins/jiveemoticons/... https://community.jboss.org/4.5.6/images/tiny_mce3/plugins/jiveemoticons/...
*Frequently Asked Questions: How Do I Build JBoss Tools 4.1?*
*
*
*+How do I configure my settings.xml?+*
* Follow https://community.jboss.org/docs/DOC-15170 these instructions to add reference to JBoss Repositories into your settings.xml. You'll also probably need access to the SNAPSHOT repository. So here is what you should see in your ~/.m2/settings.xml
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">
....
<profiles>
....
<profile>
<id>jboss-default</id>
<repositories>
<!-- To resolve parent artifact -->
<repository>
<id>jboss-public-repository-group</id>
<name>JBoss Public Repository Group</name>
<url>http://repository.jboss.org/nexus/content/groups/public/</url>
</repository>
<repository>
<id>jboss-snapshots-repository</id>
<name>JBoss Snapshots Repository</name>
<url>https://repository.jboss.org/nexus/content/repositories/snapshots/</url>
</repository>
</repositories>
<pluginRepositories>
<!-- To resolve parent artifact -->
<pluginRepository>
<id>jboss-public-repository-group</id>
<name>JBoss Public Repository Group</name>
<url>http://repository.jboss.org/nexus/content/groups/public/</url>
</pluginRepository>
<pluginRepository>
<id>jboss-snapshots-repository</id>
<name>JBoss Snapshots Repository</name>
<url>https://repository.jboss.org/nexus/content/repositories/snapshots/</url>
</pluginRepository>
</pluginRepositories>
</profile>
</profiles>
<activeProfiles>
<activeProfile>jboss-default</activeProfile>
...
</activeProfiles>
</settings>
+*My build is failing due to OutOfMemory or PermGen issues! How do I give Maven more memory?*+
+*
*+
* To configure the amount of memory used by Maven, you can define MVN_OPTS as follows, either in the mvn / mvn.bat script you use to run Maven, or set as global environment variables. Here's how to do so for http://forums.fedoraforum.org/showthread.php?t=262465 Fedora, https://help.ubuntu.com/community/EnvironmentVariables Ubuntu, http://forums.techarena.in/windows-xp-support/1152405.htm Windows, http://www.digitaledgesw.com/node/31 OSX.
set MAVEN_OPTS=-Xms512m -Xmx1024m -XX:PermSize=128m -XX:MaxPermSize=256m
+*How do I build via commandline?*+
1. Fetch code from github
2. Run maven
3. Repeat for other projects
cd ~/jbosstools
git clone https://github.com/jbosstools/jbosstools-base
cd ~/jbosstools/jbosstools-base
mvn verify
+*How do I build in Eclipse (with m2e)?*+
* With m2e installed, you can either do *CTRL-SHIFT-X,M (Run Maven Build),* or right-click the project and select *Run As > Maven Build*. See https://community.jboss.org/docs/DOC-47936#Building_Locally_In_Eclipse How To Build JBoss Tools 4 - Building Locally In Eclipse
+*How do I build a single project?*+
* Generally, you need only fetch the sources, and run `mvn verify`. See 'How do I build via commandline?' or 'How do I build in Eclipse (with m2e)?' above.
+*
*+
+*How do I build a series of projects (eg., Base, Server, Webservices) ?*+
* Assuming your goal is to change sources in *multiple* projects, then build them all to verify everything still compiles, you will need to fetch sources, then build the projects in dependency order.
* This workflow is useful when you're looking to change framework code in an upstream project like Base on which Webservices or Server depends, and verify that API changes don't break the downstream project's code.
* Rather than using `mvn verify`, you must use `*mvn install*` so that the downstream build will use YOUR locally-built content in your ~/.m2, rather than looking to the internet for the last published upstream dependencies.
cd ~/jbosstools
git clone https://github.com/jbosstools/jbosstools-base
git clone https://github.com/jbosstools/jbosstools-server
git clone https://github.com/jbosstools/jbosstools-webservices
cd ~/jbosstools/jbosstools-base; mvn install
cd ~/jbosstools/jbosstools-server; mvn install
cd ~/jbosstools/jbosstools-webservices; mvn verify
+*Which is better - `mvn clean install` or `mvn verify` ?*+
* Use `*install*` to create artifacts in your ~/.m2 folder which will be checked when building anything which depends on those artifacts (in addition to checking the internet). Also useful for doing subsequent offline builds with the `*-o*` or `*--offline*` flag.
* Use `*verify*` to build, but NOT install anything into your ~/.m2 folder.
+*How do I clean out artifacts I might have installed to my ~/.m2/repo ?*+
+*What if I've already built something locally, but I want to build against the server version instead of my local repo?*+
* There are http://wiki.eclipse.org/Tycho/Target_Platform#Locally_built_artifacts two approaches that work here:
0.1. override temporarily when building, using *-Dtycho.localArtifacts=ignore*, or
0.2. delete *~/.m2/repository/.meta/p2-local-metadata.properties*
+*How do I build a target platform?*+
* Currently, you should not need to build a target platform locally if you're building w/ maven via commandline. But if you'd like to materialize a target platform for use in Eclipse, you can do so like this:
1. Fetch target platforms project from github
2. Switch to the correct branch
3. Run maven
4. Results will be in jbosstools/multiple/target/jbosstools-multiple.target.repo/ or jbdevstudio/multiple/target/jbdevstudio-multiple.target.repo/
cd ~/jbosstools
git clone https://github.com/jbosstools/jbosstools-target-platforms
cd ~/jbosstools/jbosstools-target-platforms
git checkout 4.3.0
mvn install
cd ~/jbosstools/jbosstools-target-platforms/jbosstools/multiple/target/jbosstools-multiple.target.repo/
+*
*+
+*Why is there more than one target platform?*+
* Every time we make changes to the target platform, either to add/remove something, or to change the included version, we release a new version.
* In order to verify we can build against the oldest version of a target platform (eg., one based on Eclipse 4.2.0, or "minimum" target platform) but also run tests against the latest for that stream (eg., based on Eclipse 4.2.2, or "maximum" target platform), we need to maintain multiple versions.
* By default, your build will use the default "minimum" target platform specified in the JBoss Tools parent pom. To easily build against the default "maximum", use *-Pmaximum*. See also 'What profiles do I need to build? What Maven properties are useful when building?'
+*How do I specify which target platform to use when building?*+
* See 'What profiles do I need to build? What Maven properties are useful when building?'
+*How to I skip running tests? How do I make tests not fail? Or only fail after ALL tests run?
*+
+*
*+
* To skip running tests, you can use these Maven flags:* *-Dmaven.test.skip=true*
* *-DskipTests*
* If your reason for skipping tests is to see if everything can run without being stuck on the first test failure, you might also like these flags:* *-fae*, *--fail-at-end* : Fail at end of build only
* *-fn*, *--fail-never* : Never fail the build regardless of result
* You can also cause test failures to result in JUnit output without failing the build using these flags:* *-Dmaven.test.error.ignore=true*
* *-Dmaven.test.failure.ignore=true*
+*How can I debug tests in Eclipse when run from Tycho (with Surefire)?*+
* See http://www.jboss.org/tools/docs/testing.html http://www.jboss.org/tools/docs/testing.html
+*How do I build docs?*+
* See https://community.jboss.org/docs/DOC-13341 Building JBoss Tools Documentation.
+*What profiles do I need to build? What Maven properties are useful when building?
*+
* Most of the time, you don't need any profiles or -D properties. Here are some profiles and properties you might want to use in special cases.
** *-Pmaximum* : selects the default maximum target platform version instead of the default minimum one. Useful when running tests to verify that your code works against a newer target platform (eg., Eclipse 4.2.2 instead of 4.2.0)
** *-DTARGET_PLATFORM_VERSION* : allows you to pick a specific target platform version from those available in Nexus.
* See also 'How to I skip running tests? How do I make tests not fail? Or only fail after ALL tests run?' above for test-related properties.
+*How do I see what's happening on a remote slave running Xvfb?
*+
* Look in the build log for 2 lines like these:* Building remotely on ${SLAVE_NAME} in workspace /mnt/hudson/workspace/${JOB_NAME}
* Xvfb starting$ Xvfb :1 -screen 0 1024x768x24 -fbdir ${FBDIR}
* Get the Xvfb_screen0 file:* rsync -Pzrlt --rsh=ssh --protocol=28 ${USER}@${SLAVE_NAME}:${FBDIR}/Xvfb_screen0 /tmp/
* View the screen w/ xwud:* xwud /tmp/Xvfb_screen0
+*
*++*Anything else?*+
* See also this FAQ: https://community.jboss.org/docs/DOC-10796 https://community.jboss.org/wiki/JBossToolsFAQ
+*
*+
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-48358]
Create a new document in JBoss Tools Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
11 years, 9 months
Re: [jboss-dev-forums] [JBoss AS 7 Development] - AS 7.1.0 Beta1 - Security Enabled By Default
by Vedran Mikulcic
Vedran Mikulcic [https://community.jboss.org/people/vmikulcic] commented on the document
"AS 7.1.0 Beta1 - Security Enabled By Default"
To view all comments on this document, visit: https://community.jboss.org/docs/DOC-17367#comment-11798
--------------------------------------------------
How does the web management application authenticate users then? I'm building an web service that will enable users to add and remove JNDI datasources remotely and, if possible, would like to use that same mechanism to allow this only to the users that know their jboss credentials.
Removing access from the auth folder works (i.e. only then ModelControllerClient.Factory.create actually throws an exception on wrong credentials), but mantaining that on 500+ JBoss instalations on various platforms would be a nightmare.
Any help would be most appreciated :)
--------------------------------------------------
11 years, 9 months
[Clustering Development] - mod_cluster SSL setup/implementation (JBoss AS --> httpd)
by Torben Jaeger
Torben Jaeger [https://community.jboss.org/people/jicken] created the discussion
"mod_cluster SSL setup/implementation (JBoss AS --> httpd)"
To view the discussion, visit: https://community.jboss.org/message/804615#804615
--------------------------------------------------------------
Hi,
I have little problems with how the password attribute of the ssl element in the JBoss AS7 modcluster subsystem is used.
Let's say we already have a truststore defined using system properties:
<system-properties>
<property name="javax.net.ssl.trustStore" value="${jboss.server.config.dir}/certs/myCA.jks"/>
<property name="javax.net.ssl.trustStorePassword" value="mypasswd"/>
</system-properties>
In addition I have different keystores for the client certificates with different passwords.
If the password is used in the subsystem config, ModClusterSubsystemAdd.java (as shown below) will overwrite my settings which will lead to exceptions b/c my truststore cannot be read anymore.
if (password.isDefined()) {
config.setSslTrustStorePassword(password.asString());
config.setSslKeyStorePassword(password.asString());
}
This fact gives me two options:
1. I will set a password in the ssl element
This means I have to duplicate my already existing CA truststore and use the same password I am using for my client certificate keystore.
2. I do not set a password.
My truststore can be read w/o modification, BUT my keystore has to use the default "changeit" password which needs considering due to security implications.
This is in ModClusterConfig.java
private String sslKeyStorePassword = "changeit";
What I'd like to discuss is:
1. Guard the truststore password set in ModClusterSubsystemAdd.java
if (System.getProperty("javax.net.ssl.trustStorePassword") == null) {
config.setSslTrustStorePassword(password.asString());
}
2. use the javax.net.ssl.keyStore* system properties like it's done for the javax.net.ssl.trustStore* ones
private String sslKeyStorePassword = System.getProperty("javax.net.ssl.keyStorePassword");
What do you think?
Thx,
Torben
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/804615#804615]
Start a new discussion in Clustering Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
11 years, 9 months
[JBoss Portal Development] - JBoss : create custom roles
by Antoine Grinn
Antoine Grinn [https://community.jboss.org/people/grinn78] created the discussion
"JBoss : create custom roles"
To view the discussion, visit: https://community.jboss.org/message/804604#804604
--------------------------------------------------------------
Hi,
I am working on a JBoss portal containing several pages.
These pages and the user having acces to these pages are define in the "...-object.xml" (using the <portal> => <page> => <security-constraint> => <policy-permission> => <role-name>)
Now I would like to modify this, in order for an administrateur to create a custom role from the application, without modifying the code and its xml.
So instead of defining which role has access to each page in the "....-object.xml", I would like to define it in my database.
I saw that I can set the <role-name> to <unchecked/> so every role has access to the page, but how can I then write in the code the differences of interface between users right and view?
Do you know if it is possible to hide/show different pages (so tabs, inside the application) depending on the database data of the user using JBoss?
Thank you,
Grinn
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/804604#804604]
Start a new discussion in JBoss Portal Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
11 years, 9 months
