[JBoss AS 7 Development] - Layered Distributions and Module Path Organization
by Brian Stansberry
Brian Stansberry [https://community.jboss.org/people/brian.stansberry] modified the document:
"Layered Distributions and Module Path Organization"
To view the document, visit: https://community.jboss.org/docs/DOC-47927
--------------------------------------------------------------
h1. Overview
This document describes notions for how different software distributions based on the JBoss AS 7 project can integrate with the base AS and with each other in a controlled manner.
+*
*+
h1. Fundamental Concepts
h2. Distribution
A coherent set of software produced by a "project" or a "product". JBoss AS 7 is a project. JBoss EAP is such a product. Both play similar technical roles in the JBoss ecosystem, but there are significant differences in how the two are made available to end users.
This article uses "distribution" as a replacement for constantly saying "project/product" everywhere. It's not a great term; if someone has a better one, please suggest it.
h2. Distribution Base
The "distribution base" is the core set of modules, bundles and miscellaneous files that is common to all layered distributions. It may itself be usable standalone project or product.
Currently the software produced by the JBoss AS 7 project and the JBoss EAP product are the distribution bases relevant to this discussion. In the future a more limited subset of functionality may become the distribution base, with the full set of functionality currently provided in community AS and EAP coming as layered distributions or add-ons.
h2. Layered Distribution
A distribution that builds on top of the distribution base, potentially superceding some of the distribution base's functionality. A layered distribution is allowed to supercede any aspect of the distribution base's functionality. The less the layered distribution does this, the easier it will be for the layered distribution to manage things like patching, but, if necessary, a layered distribution can supercede anything in the distribution base.
A layered distribution may build on top of another layered distribution, provided it has worked out the necessary procedures to ensure compatibility.
h2. Identity
An identity is a named set of distribution base + layered distribution(s) that is certified as a valid combination. The distribution base by itself may or may not be a valid identity. Currently it is; in the future it may not be.
The software produced by a given layered distribution may be associated with more than one identity.
h3. Patching and Identities
Patches are applicable to an identity. A given patch can apply to more than one identity, if there are no conflicts between the identities in terms of how they use the items modified by a patch. The metadata associated with a patch will indicate the identities to which it is applicable.
Patches are comprised of one or more discrete +patch elements+ each of which is produced by the distribution base or by one of the layered distributions associated with the identity. A patch element includes metadata describing the element along with any added or modified files. The patch element metadata will identify the provider of the patch component. A given patch element can be used in multiple different patches. For example, a patch element upgrading the distribution base can be included in several patches produced by different identities, with each patch also including a patch element upgrading a layered distribution used in that identity.
For example, let's say an identity named I consists of the distribution base and a layered distribution named A. Version 1.0 of identity I is based on version 2.0 of the distribution base and version 1.0 of layered distribution A. The distribution base produces a patch element that will move it to version 2.1. The producers of the I identity could then produce a patch that will result in version 1.1 of identity A. This would include a patch element upgrading layered distribution A to its version 1.1, as well as the separate element that provides the distribution base upgrade to its 2.1. There are two main benefits of this sharing approach:
* The modules and bundles provided by the distribution base upgrade are associated with the original 2.1 patch provided by the distribution base, not just with the enclosing patch provided by A. This will make possible the sharing of modules/bundles provided by patches across installations.
* Incorporating one patch within another as a simple discrete unit helps avoid errors during patch production.
For modules and bundles within a patch, once the patch is applied the association of the module or bundle with the distribution base or layer that provided it is retained within the installation. The association is encoded within the filesystem path that points to the patch version of the module or bundle.
Miscellaneous files within a patch are not associated with the distribution base or any particular layered distribution once they are installed. For example bin/standalone.sh is bin/standalone.sh no matter what patch component added or modified it.
Each identity produces a patch stream. Because a given patch can apply to more than one identity, the same patch can appear in multiple patch streams.
The distribution base and layered distributions can produces +patch elements+ but they cannot themselves produce +patches+ or a patch stream. Since a patch must be associated with an an identity, only an identity (or a group of cooperating identities) can produce a patch.
If there is an identity that consists of nothing but the distribution base, that identity can produce a patch. But this is logically not the same thing as saying the distribution base itself produced the patch, even though the practical effect is similar.
h2. Installation
An installation is a single filesystem location containing the distribution base plus zero or more layered distributions. It includes the bin/ dir from which processes are launched. The root of the installation is the path indicated by the $JBOSS_HOME environment variable referred to in the scripts and indicated by the jboss.home.dir system property used in the java code.
h3. Installation Identity
Each installation has a *+single identity+*. Because an installation only has a single identity, there is no confusion as to which layered distribution "owns" a particular filesystem location in that installation. Further, because the identity of an installation can be easily determined (see "Establishing Identity" below), external tools can quickly understand the functionality provided by a given installation, even if no process is currently running from the installation.
+TODO further spell out the importance of single identity.+
h3. Sharing Files Across Installations+
+
The files that comprise modules and bundles are potentially sharable across installations. Making it easy for users to do this should be a key goal.
Miscellaneous files are not sharable across installations. An end user could potentially share them using symlinks, but doing so is not a supported feature nor is it a recommended practice.
Patches are not sharable across installations. The +modules and bundles that the patch provides+ are potentially sharable, but the miscellaneous files provided by a patch are not sharable. The patching history metadata that the patching tool records in the installation is also not sharable -- the metadata is associated with the given installation. However, making it easy to share the the modules and bundles provide by a patch across installations should be a key goal.
h2. Add-On Distribution
An add-on distribution is a set of software that extends the capabilities of a given "identity". An add-on can only extend capabilities. It is not allowed to supercede capabilities of the identity it extends. For modules and OSGi bundles, the module and bundle loading logic provided by the distribution base will enforce this behavior. For miscellaneous files, it is up to the people providing an add-on to ensure that the add-on does not overwrite any file provided by the distribution base, any layered distribution associated with the identity or any other add-ons associated with the identity. Conversely, once the providers of an identity have accepted an add-on into their ecosystem, it is their responsibility to ensure that they do not add any files to their distributions that will conflict with files already provided by the add-on.
In practice, the most likely sources of conflict will be the xml files in the configuration directories and the .conf files in the bin directory. Conflicts over xml files are solvable by having add-on providers ship their own xml file variants rather than attempting to modify the standard ones that ship with the identity.
A given add-on is allowed to extend the capabilities of more than one identity.
An add-on may require the presence of other add-ons.
h3. Patching and Add-ons
Add-on distributions produce their own patch stream. The patches produced by an add-on indicate the versions of the identity that must be present for the patch to apply. More than one identity can be listed, since add-ons may be applicable to multiple identities. The patches produced by an add-on also indicate the existing version of the add-on that must be present, as well as the version of any other required add-ons.
Add-ons cannot use patches in their own stream to fix problems in the identity on which they depend. Add-ons depend on the patch stream provided by their dependent identity to provide such fixes. Modules and bundles provided by an add-on or its patches will have lower precedence in the module loading order than those that come from the distribution base or layered distributions, so any fix to such a module/bundle provided by an add-on patch will have no effect.
h1. Installers
+TODO discussion of RPM+
h2. Distribution Base Installers
The distribution base can be installed via a simple unzip. If the distribution base is itself an identity, see also "Identity Installers"
h2. Identity Installers
An identity can be installed via:
* An unzip onto an empty filesystem location of a zip file that includes the distribution base and all layered distributions.
* An unzip onto a filesystem location that already contains a depended upon identity or the installation base of a zip that only includes the layered distribution(s) to be added.
* An installer program that does one or the other or both of the above and also provides a user interface that allows the user to customize the installation.
It is a goal but not an initial requirement to allow installation to be performed via the patching tool. The benefit of this is the patching tool incorporates a number of compatibility checks that can help a user avoid invalid combinations.
A further goal is to make the logic contained in the patching tool available to installer programs via a library.
*+Once an identity is installed into a given filesystem location, the identity of that installation is irrevocably changed.+* When an identity is installed it has the right to modify any miscellaneous files in the installation filesystem, so once an identity is installed, the identity of the installation is changed. In many (hopefully nearly all) cases it may be possible for a user to remove files added by an identity install and get the installation back to its previous identity, but doing this is not a supported feature of the software and is not a recommended practice.
*+However, once support for installing patches via the patching tool is available, reverting an identity installation will be possible.+* The patching tool maintains backup copies of any miscellaneous files modified by a patch, making it possible to restore those files.
h2. Add-on Installer
An add-on can be installed via:
* An unzip onto an empty filesystem location of a zip file that includes the distribution base and all layered distributions along with the add-on itself.
* An unzip onto a filesystem location that contains the depended upon identity of a zip that only includes the add-on.
* An installer program that does one or the other or both of the above and also provides a user interface that allows the user to customize the installation.
It is a goal but not an initial requirement to allow installation to be performed via the patching tool. The benefit of this is the patching tool incorporates a number of compatibility checks that can help a user avoid invalid combinations.
A further goal is to make the logic contained in the patching tool available to installer programs via a library.
*+Once an add-on is installed into a given filesystem location, the identity of that installation is not changed, and it must be possible to reverse the installation.+* An add-on is merely additive, so removing it is a matter of deleting what was added. This could be done via a script provided by the add-on, via an installer program, or manually by a user following a set of instructions.
h1. Establishing Identity
It +must+ be possible for external tools to determine the identity of a given installation without requiring the software based on that installation to be running. It's also necessary for the software based on an installation to determine its own identity.
The identity of an installation is provided via the bin/product.conf file located in the distribution. The product.conf file is a simple properties file that contains the following property:
slot=<simple string name for identity>
For example:
slot=eap
The value of "slot" is used by the running software to identify the "slot" portion of the identifier of a jboss-modules module. The software uses the slot to load a module named org.jboss.as.product:<value of slot property>, e.g. org.jboss.as.product:eap. The software will then read manifest properties included in the META-INF/MANIFEST.MF file located in that module to find out other identifying information for the identity. Currently supported manfiest properties include:
* JBoss-Product-Release-Name -- Provides the name of the identity for use in the management API and in places like the startup and shutdown log messages.
* JBoss-Product-Release-Version -- Provides the version of the identity for use in the management API and in places like the startup and shutdown log messages.
* JBoss-Product-Console-Slot -- Used to drive what variant of the management console should be loaded. The notion here is there are different streams of consoles being produced, one for community AS releases and one for product releases, differentiated primarily by cosmetic differences. This property drives which of the two streams of console releases should be used when the console module is loaded. +The use of "Slot" in this property name is a bit unfortunate since it implies an implementation detail that may very well change. The name of the property may change in a future minor release of the AS or EAP and will very likely change in the next major release. The values we used for this attribute in AS 7 and EAP 6.0 and 6.1 are "main" to indicate the community console stream and "eap" to indicate the product console stream. These values are also unfortunate in that "main" implies an implementation detail and "eap" implies the console is not appropriate for other products based on EAP. Better values would be "community" and "product" or something like that. These values may also change in a future minor release of the AS or EAP and will very likely change in the next major release.+
If no bin/product.conf file exists, the installation is assumed to be the community version of the distribution base.
If the product.conf file contains other properties besides slot, the software will use those properties to set system properties in the runtime. However, the properties in the file will not take precedence over other mechanisms for setting system properties (i.e. the command line, the standard scripts or the xml configuration files.) Note also that the reading of product.conf occurs after primordial boot, so this mechanism should not be used for setting properties needed immediately on launch. The values are unknown to the JVM launcher, will be unknown to jboss-modules when it sets up the modular classloading environment, and will be unknown to the logging system until any logging subsystem in the xml configuration file is processed.
The software based on the installation will also need to know the name of any layered distributions used by the identity, in order of the precedence to be used when loading their modules and/or bundles. This information will be done via a modules/layers.conf file located in the distribution. This file will be a simple properties file that includes a single property:
layers=<comma delimited list of layered distribution names with earlier names taking precedence>
For example, assuming we have layered distribution named "soa" and "brms" with "brms" taking precedence over "soa":
layers=brms,soa
There is no need to include "base" in the list of layers; if not present "base" will be appended to the list of layers as the lowest precedence layer. It is legal to include "base" in the list, though.
If the modules/layers.conf file does not exist or no layered distributions are named in it, only the base and any add-ons will be used.
h1. Module Loading
JBoss AS currently loads modules based on a "module path" which is a list of filesystem locations which JBoss Modules searches for modules. In our standard launch scripts, users are able to manipulate this module path by setting the $JBOSS_MODULEPATH environment variable. If not set, $JBOSS_MODULEPATH is set to $JBOSS_HOME/modules. The module path is provided to the running process via the -mp command line argument that is set in our standard scripts.
This mechanism creates a single default location under which modules can be located. This is problematic when layered distributions and add-ons wish to install their own modules, since there are no clear rules as to how those modules should be installed or how they relate to one another.
h2. Goals
* To make it easy for layered distributions or add-ons to add their modules to the set of available modules or remove their modules from the set of available modules, without fear of physically overwriting modules provided by others.
* To establish clear rights and responsibilities for providers of the distribution base, layered distributions and add-ons with respect to how their modules should be managed.
* To establish clear rules for how distributions that add modules that must take precedence over other modules provided by other distributions with the same name and slot should:* locate those modules
* indicate at launch time to the modular classloading system the precedence order
* To make it easy for end users to alter the module path for their own purposes by setting $JBOSS_MODULEPATH without needing to concern themselves with details of how the modules provided by the distribtuion base, layered distributions, or add-ons relate to one another. Reserve the use of $JBOSS_MODULEPATH and the value of the -mp command line argument passed to jboss-modules for end use uses.
h2. Rights and Responsibilities of Module Providers
All modules provided as part of the distribution base can be depended upon by any add-on associated with an identity.
If the distribution base by itself is an identity (i.e. with no additional layered distribution required), the providers of the distribution base accept the following with respect to that identity:
* The version of the module the distribution base provides will take precedence over a module with the same name and slot provided by any add-on.
* As a consequence of this, any modification of that module in a patch will need to be tested for compatibility with add-ons based on the version of the identity being patched.
* As a subset of the previous point, within a major version family the distribution base cannot remove a module that is depended upon by an add-on, even if the distribution base itself no longer needs that module.
If the distribution base is part of an identity along with one or more layered distributions, the providers of the distribution base accept the following with respect to that identity:
* The distribution base has the same responsibilities with respect to add-ons that it has in the case of add-ons without any layered distribution.
* However, if a layered distribution in an identity provides a module with the same name and slot as the one provided by the distribution base, the distribution base no longer has responsibility to provide the module. The layered distribution's version of the module takes precedence.
* The distribution base can modify a module that is depended upon by a layered distribution in a way that breaks functionality of the layered distribution. Providers of identities that include layered distributions are responsible for testing patch elements produced by the distribution base before making them available for use with the identity. If the distribution base patch element in some way breaks the functionality of an identity, either the patch element should not be provided for the identity, or the patch that incorporates the distribution base patch element should also include a layered distribution patch element that fixes the problem.* However, the distribution base should take great care not to break layered distributions with which it is associated when it produces patch elements. Distribution base patch element production should involve reasonable testing of all relevant identities such that problems can be found and resolved before the distribution base patch element ships.
* The distribution base can remove a module that is not depended upon by any add-on but which is depended upon by a layered distribution. Providers of identities that include layered distributions are responsible for testing patch elements produced by the distribution base before making them available for use with the identity. If the distribution base removes a module depended upon by a layered distribution, the patch that incorporates the distribution base patch element should also include a layered distribution patch element that adds the module as part of the layered distribution.
* If an identity add-on depends on a module provided by the distribution base and the distribution base wishes to remove the module, that is allowed provided some layered distribution is willing to begin providing the same module in an overall patch.
All modules provided as part of a layered distribution can be depended upon by any add-on associated with an identity. They cannot be depended upon by the distribution base. When a layered distribution includes a module it accepts the following:
* The version of the module it provides will take precedence over a module with the same name and slot provided by the distribution base or by any add-on.
* As a consequence of this, any modification of that module in a patch element will need to be tested for compatibility with add-ons based on that version of the identity. Any functionality provided by the distribution base and supported by the identity will also have to be tested.
* As a subset of the previous point, within a major version family the layered distribution cannot remove a module that is depended upon by an add-on, even if the layered distribution itself no longer needs that module.
* A layered distribution can remove a module that is not depended upon by any add-on.
If a layered distribution participates in an identity with another layered distribution that depends on it, the depended-on layer accepts the following:
* If the dependent layered distribution provides a module with the same name and slot as the one provided by the depended-on layer, the depended-on layer no longer has responsibility to provide the module to the dependent or to any add-ons. The dependent layered distribution's version of the module takes precedence.
* The depended-on layer can modify a module that is depended upon by another layer in a way that breaks functionality of the dependent. Providers of identities that include layered distributions are responsible for testing patch elements produced by the component layers before making them available for use with the identity. If the depended-on layer's patch element in some way breaks the functionality of an identity, either the patch should not be provided for the identity, or the patch element that incorporates the depended-on layer's patch component should also include a patch element to a dependent layer that fixes the problem.* However, a depended-on layer should take great care not to break dependent layers when it produces patch elements. Layered distribution patch production should involve reasonable testing of all relevant identities such that problems can be found and resolved before the depended-on layer's patch ships.
* A depended-on layer can remove a module that is not depended upon by any add-on but which is depended upon by another layer. Providers of identities that include layered distributions are responsible for testing patch elements produced by a depended-upon layered distribution before making them available for use with the identity. If the depended-upon layer removes a module that is depended upon by another layer, the patch that incorporates the depended-upon layer's patch element should also include a patch element from the dependent layer distribution that adds the module as part of that layered distribution.
* If an add-on depends on a module provided by the layered distribution and the layered distribution wishes to remove the module, that is allowed provided some other layered distribution in the identity is willing to begin providing the same module in an overall patch.
When an add-on includes a module, it accepts the following with respect to any identity with which the add-on is associated:
* The distribution base or a layered distribution may ship a module with the same name and slot, and that module +*will*+ take precedence over the module provided by the add-on.
* Another add-on may ship a module with the same name and slot, and that module +*may*+ take precedence over the module provided by this layered distribution or add-on.
* Another add-on may ship a module with the same name and slot, and the version provided by this layered distribution or add-on +*may*+ take precedence over the module provided by the other add-on.
* As a consequence of this, any modification of the depended-upon module in a patch element will need to be tested for compatibility with any add-on based on the same major version of the identity.* The providers of the add-on are responsible for providing an adequate set of tests to the providers of the identity.
* The distribution base or a layered distribution cannot depend upon a module provided by an add-on.
* As a consequence of the previous point, an add-on can remove a module in a patch, without fear of breaking the core functionality of an identity.
* An add-on can depend up a shareable module provided by another add-on upon which it depends, but +only with the express consent of the providers of that add-on+. Such dependencies are strongly discouraged.
* If an add-on allows another add-on to depend upon its modules, it takes on the following responsibilities:* Any modification of that module in a patch or version upgrade will need to be tested for compatibility with any dependent add-ons. Testing procedures must be created to ensure that any patches produced by the depended-upon add-on do not break the dependent add-on.
* As a subset of the previous point, within a major version family the add-on cannot remove a module that is depended upon by another add-on, even if the add-on itself no longer needs that module.
h2. Module Organization on the Filesystem
This section will describe how the above points are reflected in the actual organization of modules on the filesystem.
h4. Requirement for Standardized Module Loading
JBoss Modules can support other mechanisms for finding module content and loading it besides the filesystem-based module path mechanism. Theoretically a custom boot module loader implementation could be specified at process launch, with that module loader using some other means for locating module content. This article proposes that this capability be declared as unsupported for JBoss AS and products based upon it. Rather, the AS will have a specified boot module loader implementation.
Users of the AS community project are free to use a non-standard boot module loader implementation, but if they do so and certain features provided by the AS don't work, that is their problem.
h3. Filesystem Layout
Modules would be organized on the filesystem as follows:
modules
+ system
++ add-ons
+++ abc
+++ def
++ layers
+++ base
+++ vuw
+++ xyz
The system level exists to separate modules associated with the distribution base, layered distribution or add-ons from those the end user may store in the modules directory. +(Note: in earlier versions of this document, "internal" was used instead of "system" with a request for suggestions of something better.)+
h3. Translation of Filesystem Layout into Module Loading Precedence
For any location provided by the user via the -mp switch, the module loader will look for the system structure. The module loader will understand the structure above and will apply module loading precedence rules as follows.
Assume the above structure exists under $JBOSS_HOME and that the user sets $JBOSS_MODULEPATH as follows
JBOSS_MODULESPATH=/user/me/my-modules;$JBOSS_HOME/modules
In addition, the bin/product.conf file declares that the identity of the install is xyz, the xyz layered distribution should be loaded and the xyz layered distribution depends on the vuw layered distribution.
Assume also that patches named base-1, abc-1, def-1, vuw-1, xyz-1 and xyz-2 have been applied.
The module loader would look for modules on the filesystem in following locations, starting with first and terminating as soon as the module is found:
/user/me/my-modules
/modules (in case the user placed modules directly in under this directory)
/modules/system/layers/xyz/patches/xyz-2
/modules/system/layers/xyz/patches/xyz-1
/modules/system/layers/xyz
/modules/system/layers/vuw/patches/vuw-1
/modules/system/layers/vuw
/modules/system/layers/base/patches/base-1
/modules/system/layers/base
/modules/system/add-ons/abc/patches/abc-1
/modules/system/add-ons/abc
/modules/system/add-ons/def/patches/def-1
/modules/system/add-ons/def
The precedence order between /modules/system/add-ons/abc and /modules/system/add-ons/def is arbitrary. An add-on should never assume its modules will take precedence over those of any other add-on's modules.
The fact that the various patches locations are included in the path is entirely due to +metadata+ that the patching tool will store in the $JBOSS_HOME/patches directory. The mere presence of a directory like /modules/system/layers/xyz/patches/xyz-2 is insufficient to trigger inclusion of that directory in the module search path. However, when the patching tool installs the patch, the actual location of the +module contents+ will be in /modules/system/layers/xyz/patches/xyz-2 -- only patching related metadata will be stored in $JBOSS_HOME/patches. This behavior is important for allowing sharing of modules across installations.
h2. Sharing Modules Across Installations
The above behavior makes it relatively straightforward for a user to share modules across installations. For example, the user could set up a shared module repo in /user/me with the following structure
jboss-module-repo
+ add-ons
++ abc
++ def
+ layers
++ base
++ vuw
++ xyz
The $JBOSS_HOME/modules/system location in each installation on the filesystem could then be replaced with a symlink to /user/me/jboss-module-repo.
The downside to this very simple sharing is the abc and def add-ons will be visible and used by all installations, whether or not they are relevant to the installation's identity. A solution to this problem would be to do more symlinks:
$JBOSS_HOME/modules/system/layers -> /user/me/jboss-module-repo/layers
$JBOSS_HOME/modules/system/add-ons/abc -> /user/me/jboss-module-repo/add-ons/abc
$JBOSS_HOME/modules/system/add-ons/def -> /user/me/jboss-module-repo/add-ons/def
As an improvement at some point we could define some sort of file format (say xml) and allow a file with that format to be placed in $JBOSS_HOME/modules/system in lieu of the subdirectories. The file would include all of the mapping information for the external repo. The boot module loader, patching tool and any programmatic installers would know how to read and update that file. The file would only include information for the add-ons relevant to the installation.
h3. Implications for the Patching Tool
The possibility of module sharing doesn't remove the requirement to apply a patch to each installation on a given filesystem. Applying the patch to each installation is required in order to:
* update any miscellaneous files
* record the patching metadata for the particular installation
* allow the patching tool to understand what combinations of layered distributions and add-ons are relevant to the given installation
However, the patching tool should recognize the possibility of this kind of module sharing. When it applies a patch it should recognize that the modules may already exist on the filesystem and should not apply them again if not necessary. It should however record some information in, e.g. /modules/system/layers/xyz/patches/xyz-2 indicating that the installation being patched is using that set of patch modules. This information will prevent deletion of patch modules used by multiple installations if one of the installations uses the patching feature's cleanup functions.
h1. OSGi Bundle Loading
OSGi bundle loading will follow the same rules as for module loading. The file used to specify what layers should be used will be a layers.conf file found in each directory in the bundle path (i.e. $JBOSS_HOME/bundles/layers.conf.) +The bundle loading mechanism will not use+ +$JBOSS_HOME/modules/layers.conf for identifying layers. Identities that wish to include bundles in layers other than the base will need to provide a $JBOSS_HOME/bundles/layers.conf.+
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-47927]
Create a new document in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
9 years, 11 months
[JBoss AS 7 Development] - JBoss Jaas Jersey Rest Authentication and forwarding
by Coen Damen
Coen Damen [https://community.jboss.org/people/coenos] created the document:
"JBoss Jaas Jersey Rest Authentication and forwarding"
To view the document, visit: https://community.jboss.org/docs/DOC-48570
--------------------------------------------------------------
Hi,
I have the following Rest service which bypasses the form login and instead authenticates via the Rest service. This is working fine EXCEPT......I need to call the rest URL twice before I am forwarded to the home.xhtml page. The first time I get the login screen.
Now, what I don't understand (and can't get to work) is that I am presented with the login screen ALTHOUGH there is a session AND the JAAS login worked already during the first call. Why does the Server not recognize there is already an authenticated session in the browser.
How can this be fixed ? Or is there another mechanism I need to implement ? Maybe I am missing some fundamental understanding here ?
@GET
@Path("login/{username}/{password}")
public void login(@PathParam(value = "username") String username,
@PathParam(value = "password") String password,
@Context HttpServletRequest request,
@Context HttpServletResponse response) throws NamingException,
ServletException {
try {
request.login(username, password);
} catch (ServletException e) {
throw new WebApplicationException(Response.Status.BAD_REQUEST);
}
// all is well
String passwordhash = Util.createPasswordHash("MD5",
Util.BASE64_ENCODING, null, null, password);
userService = (UserService) new InitialContext()
.lookup("java:global/vrs-web/UserService");
User user = userService.getUserByUsernameAndPassword(username,
passwordhash);
if (user == null) {
throw new WebApplicationException(Response.Status.BAD_REQUEST);
}
try {
URI uri = new URI("../user/home.xhtml");
// Response.
// return Response.temporaryRedirect(uri).build();
} catch (URISyntaxException e) {
// TODO Auto-generated catch block
throw new WebApplicationException(Response.Status.NOT_ACCEPTABLE);
}
String baseUrl = getBaseUrl(request);
try {
response.sendRedirect(baseUrl + "/user/home.xhtml");
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
I tried both Response.temporaryRedirect and the response.sendRedirect. Both have the same effect.
Do I need to implement a filter or something?
Thanks for your help!
Coenos
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-48570]
Create a new document in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
9 years, 11 months
[JBoss AS 7 Development] - Missing user.properties
by Clifton Sothoron
Clifton Sothoron [https://community.jboss.org/people/cbsoth00] modified the document:
"Missing user.properties"
To view the document, visit: https://community.jboss.org/docs/DOC-48569
--------------------------------------------------------------
We have a web application that uses com.sun.security.auth.callback.TextCallbackHandler, javax.security.auth.login.LoginContext and com.sun.security.auth.module.NTLoginModule to do Windows NT security. I've been using it successfully in Tomcat without having to configure Tomcat in any way. Our app handles the authentication. When I copy my app over to JBoss 7 I get the error "*PB00015: Null Value:Missing users.properties file."* when invoking loginContext.login. How do I suppress this and allow the login to occur? I've tried messing around with jboss-web.xml, jboss.xml, standalone.xml, login-config.xml and my web.xml to no avail. I bundle my own copy of jaas.jar. I include the following in web.xml to avoid conflicts.
<context-param>
<param-name>org.jboss.jbossfaces.WAR_BUNDLES_JSF_IMPL</param-name>
<param-value>true</param-value>
I did the following things.
jboss-web.xml
<?xml version="1.0"?> <jboss-web>
<jboss-web>
<context-root>rdWeb</context-root>
</jboss-web>
jboss.xml
<?xml version="1.0"?> <jboss-web>
<jboss>
<security-domain>rdWeb</security-domain>
</jboss>
Thanks in advance,
Clifton Sothoron
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-48569]
Create a new document in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
9 years, 11 months
[JBoss Tools Development] - Integration Tooling Release Process
by Paul Leacu
Paul Leacu [https://community.jboss.org/people/pleacu] modified the document:
"Integration Tooling Release Process"
To view the document, visit: https://community.jboss.org/docs/DOC-48326
--------------------------------------------------------------
h1. Overview
This document details the process for building and releasing composite/aggregate update sites for the JBoss integration tooling (formerly SOA tools).
h2. Goals
* Provide a light-weight process with minimal overhead for component owners.
* Provide an ever-current update site containing the latest, stable releases of integration tooling components.
* Allow component owners to independently manage their release schedules.
* Allow component owners to manage their own dependency stack.
h2. Assumptions
* Components use released versions of dependencies (i.e. stable builds).
* Component owners manage their own interdependencies with other integration components.
* Components and dependencies adhere to Eclipse API versioning rules.
h2. Implications
* Aggregate releases will be driven by component releases.
* Aggregate releases should manage themselves.
* Component nightly/milestone builds should always be compatible with other components in the aggregate.
h2. Definitions
* *Integration Stack (IS)* - all JBoss middleware integration tooling
* *IS configuration* - the definition of specific components and versions that make up the IS
* *IS build* - an update site (p2 repo) aggregating specific versions of integration tooling components.
* *Release types:** *stable* - an IS build aggregating stable (i.e. final) builds of all components that has been certified/tested by QA.
* *development* - an IS build aggregating stable builds of all components that has not been certified/tested by QA.
* *integration* - an IS build aggregating stable, development (e.g. beta) and/or integration builds of all components
* *next* - an internal IS build incorporating the latest integration builds of all components (i.e. the current "trunk" build). This will be used for identifying potential future incompatibilities.
Stable builds will align with a JBDS release in the same way JBT core builds do today. Development builds will reflect the current state of all stable components. Theoretically, any development build could be QA'd and promoted to stable (assuming no test failures). Integration builds allow for an "interim" stack which may be useful during a QA cycle (e.g. verifying a fix that requires updates to multiple components; a single component can be updated via the component update site). Next builds are used to identify potential incompatiblilities among components before they are integrated into a release and would occur weekly/monthly via a Hudson job (e.g. targeting JBT integration builds).
An IS build only needs to occur when the IS configuration changes. Because the IS stack is composed of stable components, configuration changes will only occur when individual components are released. For this reason, it is assumed the build would be invoked manually.
h1. Roles and Responsibilities
h2. Component Owners
1. *Component update site:* Component owners must provide an update site for each release of their component that is included in an IS build.
2. *Updating IS configuration:* Component owners must update the IS build configuration when a new version of their component is released. This ensures the IS is up-to-date.
3. *Respond to change requests:* Component owners must review IS configuration change requests and respond in a timely manner. If a requested change is incompatible with the current version of your component, provide details regarding when your component will be compatible, along with a patch containing changes to the IS configuration for your compatible release.
h2. Release Engineers
1. *Maintain build infrastructure:* Release engineers will be responsible for maintianing the build infrastructure, primarily the Jenkins jobs.
2. *Processing pull requests:* Release engineers will be responsible processing all pull requests related to IS configuration. This is to ensure consistency in the composition of the stack (e.g. components, component versions, IS version, etc.).
3. *Initiate IS builds:* Release engineers will be responsible for initiating IS builds.
4. *Build promotion:* Release engineers will be responsible for the promotion of IS builds (e.g. from development to stable).
h1. Release Process
h2. Component Updates
The following outlines the basic process for updating the IS configuration. Typically, this would occur when a component is released, but the same process is also used for updating shared dependencies (e.g. JBT core, third-party plugins, etc.).
1. Create a branch in the user repository for your IS configuration changes.
2. Modify the Integration Stack configuration for your updates, e.g. update URL for SwitchYard from 0.5.0.Final to 0.6.0.Final; update IS version from 0.9.0 to 0.9.1 (see versioning rules)1. For changes to your component within the community aggregate: https://github.com/jbosstools/jbosstools-integration-stack/tree/master/jb... https://github.com/jbosstools/jbosstools-integration-stack/tree/master/jb.... Modify the https://github.com/jbosstools/jbosstools-integration-stack/tree/master/jb... compositeArtifacts.xml and https://github.com/jbosstools/jbosstools-integration-stack/tree/master/jb... compositeContent.xml files to point to the new component update site.
2. Modify the https://github.com/jbosstools/jbosstools-integration-stack/tree/master/jb... category.xml file as necessary for any feature changes (e.g. adding a feature).
3. Modify the project version in https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ag... pom.xml.
2. For changes to your component within the production aggregate: https://github.com/jbosstools/jbosstools-integration-stack/tree/master/de... https://github.com/jbosstools/jbosstools-integration-stack/tree/master/de.... Modify the https://github.com/jbosstools/jbosstools-integration-stack/tree/master/de... compositeArtifacts.xml and https://github.com/jbosstools/jbosstools-integration-stack/tree/master/de... compositeContent.xml files to point to the new component update site.
2. Modify the https://github.com/jbosstools/jbosstools-integration-stack/tree/master/de... category.xml file as necessary for any feature changes (e.g. adding a feature).
3. Modify the project version in https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ag... pom.xml.
3. For changes to dependencies: https://github.com/jbosstools/jbosstools-integration-stack/tree/master/ta... https://github.com/jbosstools/jbosstools-integration-stack/tree/master/ta.... Modify https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ta... integration-stack-base.target, https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ta... core-base.target or https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ta... community.target
2. Modify project version in https://github.com/jbosstools/jbosstools-integration-stack/blob/master/ta... pom.xml
3. Ensure plugins are mirrored on jboss.org
3. Build locally to validate stack dependencies.
4. Create a https://issues.jboss.org/browse/JBTIS JBTIS JIRA task requesting update, e.g. update SwitchYard to 0.6.0.Final* Include link to github branch in task
* Include build results (e.g. SUCCESS or specific dependency resolution errors)
5. Create subtasks against each IS component for verification/approval* For components that failed the consistency check, mark subtasks appropriately, e.g. m2e-wtp version is inconsistent
6. Merge any changes required by other components from subtasks (e.g. update Savara to 2.1.0.Final)
7. Build IS locally to validate dependency consistency
8. Issue pull request against upstream IS configuration project
9. Process pull (by release engineer)
10. Invoke build job (by release engineer)
h2. Platform Updates
*Goal:* release updated IS within four weeks of JBT/JBDS core release.
1. Initiate platform update during JBT beta phase
2. Follow the component update process above (e.g. update JBT core from 3.3 to 4.0)
h2. JBoss Central Discovery Updates
*Goal:* Modify the JBoss Central mylyn discovery install/update mechanism.
JBoss Central, based on http://wiki.eclipse.org/Mylyn/Discovery Mylyn Discovery, is in part a UI for installing new features into Eclipse or JBDS. It provides a richer, yet simpler UI than what Eclipse's p2 Install Manager provides out of the box.
For detailed information see https://community.jboss.org/docs/DOC-48297 https://community.jboss.org/wiki/JBossCentralsSoftwareUpdateTab-HowDoesIt...
1. For changes to the discovery update: https://github.com/jbosstools/jbosstools-integration-stack/tree/master/ta... https://github.com/jbosstools/jbosstools-integration-stack/tree/master/di...
2. Follow the same git process as defined in the Components Updates section.
3. Modify the discovery connector descriptors and installation units as needed within the https://github.com/jbosstools/jbosstools-integration-stack/blob/master/di... discovery plugin.
4. Add any icons that may be required.
h2. Dependency Updates
The process for updating a shared dependency is the same as that for updating any other component, with the following additions:
1. Make sure the dependency is mirrored on jboss.org.
2. Make sure the dependency is not already included through JBT core.
If a dependency is included through JBT core, you will need to coordinate with the core team on the upgrade, as the change may impact components outside the IS.
h2. Versioning Rules - major.minor.update.build
*Major* should be updated for:
* Base platform changes, e.g. Eclipse Indigo->Juno, JBT 3.3->4.0
* Major component updates, e.g. SwitchYard 1.0->2.0
*Minor* should be updated for minor component updates, e.g. SwitchYard 0.5->0.6
*Update* should be updated for minor component updates, e.g. SwitchYard 0.5.0->0.5.1
*Build* should be updated for each build, e.g. when building against nightly/integration/development repositories
** Note, the basic assumption here is that components are adhering to basic API rules (per Eclipse; e.g. minor includes bug fixes and api additions, major may include breaking api changes).
h1. Update Site Locations
* *Integration builds: http://download.jboss.org/jbosstools/updates/integration/juno/integration... http://download.jboss.org/jbosstools/updates/integration/juno/integration...
* *Development builds: http://http://download.jboss.org/jbosstools/updates/development/juno/inte... http://http://download.jboss.org/jbosstools/updates/development/juno/inte...
* *Stable builds: http://http://download.jboss.org/jbosstools/updates/stable/juno/integrati... http://http://download.jboss.org/jbosstools/updates/stable/juno/integrati...
h1. Infrastructure
* *JIRA -* https://issues.jboss.org/browse/JBTIS https://issues.jboss.org/browse/JBTIS
* *Source -* https://github.com/jbosstools/jbosstools-integration-stack https://github.com/jbosstools/jbosstools-integration-stack* *target-platform* - provides a target platform defining all upstream dependencies for use by IS components (e.g. JBT core, third-party plugins)
* *aggregate-site* - provides category and feature definitions for the IS update site
* *discovery* - provides JBoss Central discovery support
* *Jenkins* - * *target platform* - https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-target-platform https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-target-platform
* *aggregate* - https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-aggregate https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-aggregate
* *aggregate publish/promote* - https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-aggregate-publish https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-aggregate-publish
* *discovery* - https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-discovery https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-discovery
* *install tests* - https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-4.0_stable_bra... https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/JBTIS-4.0_stable_bra...
h2. Target Platforms
The provided target platforms define all upstream dependencies available to an IS component. Two target platforms are provided: base and community. The base target platform includes all dependencies which are also included as part of JBDS. The community target extends the base target by including dependencies which are only available in community JBT releases. If your component needs to be included in a JBDS release, DO NOT use the community target platform. For more information and an example on how to refer to the target platform definition, see: https://github.com/jbosstools/jbosstools-integration-stack/blob/master/RE... https://github.com/jbosstools/jbosstools-integration-stack/blob/master/RE...
h1. Future Plans
1. Add support for executing component unit tests as part of the aggregate build. The goal being to help ensure the stability of the aggregate.
2. Add a "next" build that will build against upcoming core platforms (e.g. Kepler, JBT 4.1). This should serve as an early warning system to identify platform incompatibilities early in the process.
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-48326]
Create a new document in JBoss Tools Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
9 years, 11 months
[JBoss Remoting Development] - SASL and Kerberos
by Darran Lofthouse
Darran Lofthouse [https://community.jboss.org/people/dlofthouse] modified the document:
"SASL and Kerberos"
To view the document, visit: https://community.jboss.org/docs/DOC-17302
--------------------------------------------------------------
Working on how Kerberos can be supported with Remoting for https://issues.jboss.org/browse/REM3-29 REM3-29, the first stage is understanding the unederlying mechanism.
*Please Note, this article is not a user guide, it is a reference guide to hold the information needed so that the issue REM3-129 can be implemented.*
Whilst there is some JDK documentation this does not go into the finer details, the implementation makes quite a few assumptions so this article is to capture the additional detail.
h1. Client
OS local Kerberos configuration can be used to specify the Ream and KDC, alternatively JVM wide system properties can be used: -
System.setProperty("java.security.krb5.kdc", "ec2-?-?-?-?.compute-1.amazonaws.com");
System.setProperty("java.security.krb5.realm", "DARRANL.JBOSS.ORG");
On the client side unless you fallback to default JAAS configurations the SASL negotiation needs to be within a PrivilegedAction where a Subject for the local clients identity is passed in: -
Subject.doAs(clientSubject, new PrivilegedAction<Void>() {
@Override
public Void run() {
try {
client.haveAChat();
} catch (IOException e) {
e.printStackTrace();
}
return null;
}
});
To obtain the subject a JAAS LoginContext is used with the 'com.sun.security.auth.module.Krb5LoginModule' LoginModule, although JAAS is used we don't need the configuration within a descriptor - we can provide a simplified configuration for the client and dynamically configure the LoginContext.
No special configuration of the LoginModule is required on the client side. There are three configuration options for the client: -
1. Use a supplied CallbackHandler to prompt the client for the username and password, the LoginModule will then obtain their Kerberos tickets.
2. Configure to use a keytab without prompting - useful for unattended processes e.g. server instances.
3. Configure to use local OS cache i.e. if user obtained Kerberos ticket on OS log on use this identity.
The client side does not require the 'storeKey' option being set to true although if a process is both a client and a server this can be set to true.
Inside the PriviledgedAction the SaslClient can be obtained as: -
Sasl.createSaslClient(MECHS, null, "remoting", "test2", Collections.EMPTY_MAP,
new NoCallbackHanlder());
The parameters are: -
1. Array of mechanisms, in this case just "GSSAPI"
2. The authorization ID, if not supplied it will default to the username@REALM of the user.
3. Protocol
4. Server host name
5. Configuration options
6. Callback Handler
*The values for protocol and server host name are criticial to the negotiation process.*
In this example before the communication with the server commences the client side will automatically send a TGS-REQ to the KDC for the server name 'remoting/test2' - this is an integral part of the process an if this server is not known by the KDC the process will terminate.
Do also note that the host name may undergo the following conversion, the comment in the code openly admints that this is against the RFC but goes ahead and does it anyway. The end result is that the name could end up being the fully qualified host name of the remote service. If the server name does not match then the original supplied name is used.
// RFC4120 does not recommend canonicalizing a hostname.
// However, for compatibility reason, we will try
// canonicalize it and see if the output looks better.
String canonicalized = (InetAddress.getByName(hostName)).
getCanonicalHostName();
For this TGS-REQ a service principal mapping on the KDC is sufficient, however there are also issues on the server side of this to consider.
There are a couple of options which could be passed in, one is to enable server_auth, this setting means that in addition to the server verifying the identity of the client the client will also verify the identity of the server.
At the stage of the SASL message exchange the CallbackHandler on the client is not required to handle any callbacks, the client side idenity has already been established when the Subject was obtained.
If this was SPNEGO the web browser would be verifying the DNS name of the server it is connecting to, we should consider if our client should allow any flexibility in the setting of server host name or should we mandate that it does match the host name we are connecting to - at the same point also consider banning connection to IP addresses as DNS is also fundamental to this.
h1. Server
As for the client side the Realm / KDC configuration is required, again this can either be configured using OS specific configuration or the same system properties can be set.
On the server a Subject needs to be obtained similar to how one was obtained for the client, this time the Subject is for the identity of the server - all the Sasl calls will then be within a PriviledgedAction.
When the Subject for the server is obtained here it is essential that 'storeKey' is set to true for the LoginModule, this will store the KerberosKeys for the server in the PrivateCredentials of the Subject.
On the server side the SaslServer can be obtained with: -
SaslServer saslServer = Sasl.createSaslServer(GSSAPI, "remoting", "test2", Collections.EMPTY_MAP,
new AuthorizeCallbackHandler());
Here the parameters are: -
1. Chosen mechanism "GSSAPI"
2. Protocol
3. Server Host Name
4. Configuration options
5. Callback Handler
On the server side the protocol and server host name are again critical to the process but this time they affect how the PrivateCredentials of the Subject are searched.
In this example the protocol is 'remoting', the server host name is 'test2' and from the system properties the realm is 'DARRANL.JBOSS.ORG', the private credentials of the Subject will be searched for KerberosKeys with the prinicipal name " mailto:remoting/test2@DARRANL.JBOSS.ORG remoting/test2(a)DARRANL.JBOSS.ORG"
On the server side an error indicating "Mechanism level: Failed to find any Kerberos Key" most likely translates to mean that no key has been found with the expected principal name.
The server identity does need to match the identity the client received in the TGS-REP from the TGS-REQ that the client sent in, however I need to verify if the names within the Subject also need to match or if we can just allign the createSaslServer identity with what is provided in the Subject. The reason this needs to be considered is that it may be desirable to just have a single Kerberos identity on the server for both Remoting and HTTP, however for HTTP the identity may already be mapped to HTTP/test2
The only Callback that needs to be supported is the AuthorizeCallback, by default the authentication ID will be in the form username@REALM - there may be some desire to drop the @REALM part.
In the exchange between the client and the server we do need to be able to support 0 length SASL messages.
There is also an option that may be possible to set on the server side if the identity is only being used for incomming requests and that is to set isInitiator to false, this removes one round trip with the KDC.
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-17302]
Create a new document in JBoss Remoting Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
9 years, 11 months
Re: [jboss-dev-forums] [JBoss AS 7 Development] - Using the CLI remote client jar
by Miguel Reyes
Miguel Reyes [https://community.jboss.org/people/miguelreyes] commented on the document
"Using the CLI remote client jar"
To view all comments on this document, visit: https://community.jboss.org/docs/DOC-18795#comment-11850
--------------------------------------------------
jboss-cli-client.jar works fine in Fedora. However, when I try to run it in Win7 I get a "connection timeout" error:
Microsoft Windows [Version 6.1.7600]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\myuser\Desktop\Test>*java -jar jboss-cli-client.jar --controller=10.11.12.13:9999 --connect --user=admin --password=admin --file=test.cli*
WARN: can't find jboss-cli.xml. Using default configuration values.
apr 09, 2013 10:35:21 FM org.xnio.Xnio <clinit>
INFO: XNIO Version 3.0.7.GA
apr 09, 2013 10:35:21 FM org.xnio.nio.NioXnio <clinit>
INFO: XNIO NIO Implementation Version 3.0.7.GA
apr 09, 2013 10:35:21 FM org.jboss.remoting3.EndpointImpl <clinit>
INFO: JBoss Remoting version 3.2.14.GA
org.jboss.as.cli.CliInitializationException: Failed to connect to the controller
at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:280)
at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:240)
at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
Caused by: org.jboss.as.cli.CommandLineException: The controller is not available at 10.11.12.13:9999
at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:950)
at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:789)
at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:765)
at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:278)
... 2 more
Caused by: java.io.IOException: java.net.ConnectException: JBAS012144: Could notconnect to remote://10.11.12.13:9999. The connection timed out
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:129)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:928)
... 5 more
Caused by: java.net.ConnectException: JBAS012144: Could not connect to remote://10.11.12.13:9999. The connection timed out
at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:130)
at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:256)
at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70)
at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:176)
at org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:153)
at org.jboss.as.cli.impl.CLIModelControllerClient$2.getChannel(CLIModelControllerClient.java:114)
at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:115)
at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:98)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
... 7 more
My workaround right now is to pass the +connect+ command in my test.cli (connect 10.11.12.13) and instead run:
C:\Users\myuser\Desktop\Test>*java -jar jboss-cli-client.jar --user=admin --password=admin --file=test.cli*
Still, I would like to be able to pass the server IP as part of the execution line so that I can run the same test.cli file against several servers...
Using the jboss-cli-client.jar from EAP6.1.ALPHA
--------------------------------------------------
9 years, 12 months
rg.jnp.interfaces){kind=link}