[JBoss AS 7 Development] - Design of AS7 multi-JSF feature
by Stan Silvert
Stan Silvert [https://community.jboss.org/people/ssilvert] modified the document:
"Design of AS7 multi-JSF feature"
To view the document, visit: https://community.jboss.org/docs/DOC-47689
--------------------------------------------------------------
*About multi-JSF*
Currently, AS7 ships with two JSF implementations, a JSF 2.1 implementation and a JSF 1.2 implementation. A web application can select which implementation is used by including a context param in web.xml. By default, it uses the JSF 2.1 imlementation.
"multi-JSF" allows installation of multiple JSF implementations (and versions) on the same AS7 server. The goal is to allow use of any JSF implementation (MyFaces or Mojarra) and any version of those implementation from JSF 1.1 all the way up to the experimental JSF 2.2 versions. This is far superior to the old WAR_BUNDLES_JSF_IMPL method because JSF jars do not need to be bundled with the webapp. More importantly, "multi-JSF" provides an implementation that is fully integrated with the container. This means more efficient annotation processing, lifecycle handling, and other integration advantages.
*How it works*
The way multi-JSF will work is that for each JSF version, a new slot is created in the modules path under *com.sun.jsf-impl*, *javax.faces.api*, and *org.jboss.as.jsf-injection*. When the jsf-subsystem is started, it scans the module path to find all the installed JSF implementations. When the JSF subsystem deploys a web app containing the specified context param, it adds the slotted modules to the deployment.
Here is an example of the context param for the latest milestone of Mojarra 2.2:
<context-param>
<param-name>org.jboss.jbossfaces.JSF_CONFIG_NAME</param-name>
<param-value>mojarra-2.2.0-m05</param-value>
</context-param>
*How a JSF implementation is installed*
A single JSF implementation is installed using a https://community.jboss.org/docs/DOC-18945 CLI deployment archive. This archive includes the required jars and module.xml files. It also includes CLI scripts for installing/uninstalling the JSF impls using the https://issues.jboss.org/browse/AS7-4265 CLI module command. You execute the installation archive like this:
> [standalone@localhost:9999 /] deploy <local path to archive>/install-mojarra-2.2.0-m05.cli
The install script inside the archive looks like this:
> module add --name=javax.faces.api --slot=mojarra-2.2.0-m05 --resources=jsf-api-2.2.0-m05.jar --module-xml=mojarra-api-module.xml
> module add --name=com.sun.jsf-impl --slot=mojarra-2.2.0-m05 --resources=jsf-impl-2.2.0-m05.jar --module-xml=mojarra-impl-module.xml
> module add --name=org.jboss.as.jsf-injection --slot=mojarra-2.2.0-m05 --resources=jboss-as-jsf-injection-7.2.0.Alpha1-SNAPSHOT.jar --module-xml=injection-module.xml
*How the CLI deployment archives are created*
A CLI deployment archive for a JSF implementation/version is created using a standalone maven project you can https://github.com/ssilvert/jboss-jsf-installer download from GitHub and run. To create an archive with the project, you call it like this:
*mojarra example*
> mvn -Djsf-version=2.2.0-m05 -Pmojarra clean assembly:single
*myfaces example*
> mvn -Djsf-version=2.1.8 -Pmyfaces clean assembly:single
This pulls in the JSF resources and creates the install/uninstall scripts. It is all bundled together in an archive (zip) file that must be manually renamed with a .cli extension.
*How to change the default JSF implementation in AS7*
The multi-JSF feature adds two new attributes to the JSF subsystem. The first, +active-jsf-impls+, is just a read-only list of the installed JSF implementations. The second, +default-jsf-impl-slot+, allows you to change the default JSF implementation. You just need to issue a write-attribute command and set the value to one of the active impls. Then restart AS7.
https://community.jboss.org/servlet/JiveServlet/showImage/102-47689-4-198... https://community.jboss.org/servlet/JiveServlet/downloadImage/102-47689-4...
Alternatively, you can set this in your configuration file, such as standalone.xml:
<subsystem xmlns="urn:jboss:domain:jsf:1.0" default-jsf-impl-slot="mojarra-2.2.0-m05"/>
*Demo*
I've attached a copy of install-mojarra-2.2.0-m05.cli and install-myfaces-2.1.8.cli. You can unzip to take a look at it. You can even deploy it with the latest nightly build of AS7. This will let you see how the modules are installed. I'm not quite done with updates to the jsf-subsystem, so you can't see multi-jsf in action on a webapp yet. If you want to try it out though, let me know. I can upload a working version to my github account.
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-47689]
Create a new document in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
11 years, 5 months
[jBPM Development] - Issue building 5.4.0.Final on linux
by Peter Courcoux
Peter Courcoux [https://community.jboss.org/people/peter_courcoux] created the discussion
"Issue building 5.4.0.Final on linux"
To view the discussion, visit: https://community.jboss.org/message/776437#776437
--------------------------------------------------------------
Hi,
I have downloaded the 5.4.0.Final tagged sources from https://github.com/droolsjbpm/jbpm/tags https://github.com/droolsjbpm/jbpm/tags, extracted the folder and built using "mvn clean install -DskipTests".
Building on windows 7 using java jdk1.7.0_05 I get a successful build.
Building on ubuntu linux using the same jdk I get an error:
[INFO] Building jBPM :: JPA Persistence 5.4.0.Final
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ jbpm-persistence-jpa ---
[INFO] Deleting /home/peter/projects/drools-jbpm-project/5.4.0.Final/jbpm-5.4.0.Final/jbpm-persistence-jpa/target
[INFO] Deleting /home/peter/projects/drools-jbpm-project/5.4.0.Final/jbpm-5.4.0.Final/jbpm-persistence-jpa (includes = [btm*, JPADroolsFlow.*.db], excludes = [])
[INFO]
[INFO] --- maven-enforcer-plugin:1.0.1:enforce (default) @ jbpm-persistence-jpa ---
[INFO]
[INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @ jbpm-persistence-jpa ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 5 resources
[INFO]
[INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ jbpm-persistence-jpa ---
[INFO] Compiling 17 source files to /home/peter/projects/drools-jbpm-project/5.4.0.Final/jbpm-5.4.0.Final/jbpm-persistence-jpa/target/classes
[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR] /home/peter/projects/drools-jbpm-project/5.4.0.Final/jbpm-5.4.0.Final/jbpm-persistence-jpa/src/main/java/org/jbpm/persistence/jta/ContainerManagedTransactionManager.java:[20,24] error: cannot find symbol
[ERROR] package javax.transaction
/home/peter/projects/drools-jbpm-project/5.4.0.Final/jbpm-5.4.0.Final/jbpm-persistence-jpa/src/main/java/org/jbpm/persistence/jta/ContainerManagedTransactionManager.java:[50,14] error: cannot find symbol
[ERROR] class ContainerManagedTransactionManager
/home/peter/projects/drools-jbpm-project/5.4.0.Final/jbpm-5.4.0.Final/jbpm-persistence-jpa/src/main/java/org/jbpm/persistence/jta/ContainerManagedTransactionManager.java:[53,31] error: cannot find symbol
[INFO] 3 errors
Does anyone know why this might occur and point me in the right direction to fixing it.
I have tried building from both zip and tar archives on linux with identical results.
Maven is 3.0.4 on both boxes.
This is of particular interest as we have a problem running flows on our linux as7 server because of jta transaction issues, specifically, an exception when trying to join a transaction. While the two problems may be totally unrelated, it is possible that they are in that both are jta and linux issues.
Any help much appreciated.
Thanks,
Peter
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/776437#776437]
Start a new discussion in jBPM Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
11 years, 5 months
[JBoss AS 7 Development] - Design of AS7 multi-JSF feature
by Stan Silvert
Stan Silvert [https://community.jboss.org/people/ssilvert] modified the document:
"Design of AS7 multi-JSF feature"
To view the document, visit: https://community.jboss.org/docs/DOC-47689
--------------------------------------------------------------
*About multi-JSF*
Currently, AS7 ships with two JSF implementations, a JSF 2.1 implementation and a JSF 1.2 implementation. A web application can select which implementation is used by including a context param in web.xml. By default, it uses the JSF 2.1 imlementation.
"multi-JSF" allows installation of multiple JSF implementations (and versions) on the same AS7 server. The goal is to allow use of any JSF implementation (MyFaces or Mojarra) and any version of those implementation from JSF 1.1 all the way up to the experimental JSF 2.2 versions. This is far superior to the old WAR_BUNDLES_JSF_IMPL method because JSF jars do not need to be bundled with the webapp. More importantly, "multi-JSF" provides an implementation that is fully integrated with the container. This means more efficient annotation processing, lifecycle handling, and other integration advantages.
*How it works*
The way multi-JSF will work is that for each JSF version, a new slot is created in the modules path under *com.sun.jsf-impl*, *javax.faces.api*, and *org.jboss.as.jsf-injection*. When the jsf-subsystem is started, it scans the module path to find all the installed JSF implementations. When the JSF subsystem deploys a web app containing the specified context param, it adds the slotted modules to the deployment.
Here is an example of the context param for the latest milestone of Mojarra 2.2:
<context-param>
<param-name>org.jboss.jbossfaces.JSF_CONFIG_NAME</param-name>
<param-value>mojarra-2.2.0-m05</param-value>
</context-param>
*How a JSF implementation is installed*
A single JSF implementation is installed using a https://community.jboss.org/docs/DOC-18945 CLI deployment archive. This archive includes the required jars and module.xml files. It also includes CLI scripts for installing/uninstalling the JSF impls using the https://issues.jboss.org/browse/AS7-4265 CLI module command. You execute the installation archive like this:
> [standalone@localhost:9999 /] deploy <local path to archive>/install-mojarra-2.2.0-m05.cli
The install script inside the archive looks like this:
> module add --name=javax.faces.api --slot=mojarra-2.2.0-m05 --resources=jsf-api-2.2.0-m05.jar --module-xml=mojarra-api-module.xml
> module add --name=com.sun.jsf-impl --slot=mojarra-2.2.0-m05 --resources=jsf-impl-2.2.0-m05.jar --module-xml=mojarra-impl-module.xml
> module add --name=org.jboss.as.jsf-injection --slot=mojarra-2.2.0-m05 --resources=jboss-as-jsf-injection-7.2.0.Alpha1-SNAPSHOT.jar --module-xml=injection-module.xml
*How the CLI deployment archives are created*
A CLI deployment archive for a JSF implementation/version is created using a standalone maven project you can https://github.com/ssilvert/jboss-jsf-installer download from GitHub and run. To create an archive with the project, you call it like this:
> mvn -Djsf-version=2.2.0-m05 -Pmojarra clean assembly:single
This pulls in the JSF resources and creates the install/uninstall scripts. It is all bundled together in an archive (zip) file that must be manually renamed with a .cli extension.
*How to change the default JSF implementation in AS7*
The multi-JSF feature adds two new attributes to the JSF subsystem. The first, +active-jsf-impls+, is just a read-only list of the installed JSF implementations. The second, +default-jsf-impl-slot+, allows you to change the default JSF implementation. You just need to issue a write-attribute command and set the value to one of the active impls. Then restart AS7.
https://community.jboss.org/servlet/JiveServlet/showImage/102-47689-3-198... https://community.jboss.org/servlet/JiveServlet/downloadImage/102-47689-3...
Alternatively, you can set this in your configuration file, such as standalone.xml:
<subsystem xmlns="urn:jboss:domain:jsf:1.0" default-jsf-impl-slot="mojarra-2.2.0-m05"/>
*Demo*
I've attached a copy of install-mojarra-2.2.0-m05.cli and install-myfaces-2.1.8.cli. You can unzip to take a look at it. You can even deploy it with the latest nightly build of AS7. This will let you see how the modules are installed. I'm not quite done with updates to the jsf-subsystem, so you can't see multi-jsf in action on a webapp yet. If you want to try it out though, let me know. I can upload a working version to my github account.
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-47689]
Create a new document in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
11 years, 5 months
Re: [jboss-dev-forums] [JBoss AS 7 Development] - Single Installation Patching
by Brian Stansberry
Brian Stansberry [https://community.jboss.org/people/brian.stansberry] commented on the document
"Single Installation Patching"
To view all comments on this document, visit: https://community.jboss.org/docs/DOC-47500#comment-11120
--------------------------------------------------
Jeff,
This will need to be more complex.
For a CP, we don't want to ignore AS modules just because the only change is creation dates. If you apply a CP patch, the modules you should run should be the same as if you had downloaded a fresh install of that version. I discussed this with Jimmy Wilson of GSS a while back.
A critical question is whether a build of a product involves a complete rebuild from source of all 3rd party libs, or whether an existing built-from-source binary is re-used if the source is unchanged. I expect the latter; otherwise a new maven GAV would be needed for every build. And if that is case, again, for a CP there is no reason not to include a 3rd party module even if the diff is only creation dates. For whatever reason the module was rebuilt.
For one-off patches, the patch generator includes the ability for the patch-config to explicitly declare what modules are different. I did this as something of a workaround to the problem you're attacking. The person preparing the one-off will probably do a complete big from source of a tag + bug-fix patch, and generating a diff of that will produce spurious diffs. Your approach here provides another way to help with this case. But it shouldn't be done for CPs and for one-offs the patch-config should include a config to turn it off.
Re: the .index files, I had some discussions about those and I thought they were no longer being generated. If that's wrong, then yes, we'll need to deal with them.
I'm not in favor of analyzing the module.xml to determine what resources to hash. For two reasons:
1) The user-side patch tool shouldn't add any functionality that isn't really necessary. The more it does, the more ways it can break. And breaking is bad.
2) It's not the business of the patch tool to parse and understand the contents of module.xml. If jboss-modules changes something, we don't want to have to update the patch tool to understand that.
I don't think it's a big deal if users stick a README in a module and we treat that as a conflict. The users looks, sees the difference (the README would likely have a different filesystem date from the rest of the module) and provides the param to the patching operation indicating that it's ok to override modules with conflicts.
--------------------------------------------------
11 years, 5 months
Re: [jboss-dev-forums] [JBoss AS 7 Development] - Single Installation Patching
by Jeff Mesnil
Jeff Mesnil [https://community.jboss.org/people/jmesnil] commented on the document
"Single Installation Patching"
To view all comments on this document, visit: https://community.jboss.org/docs/DOC-47500#comment-11114
--------------------------------------------------
I have been working on the patch CLI command to patch an AS7 installation and add to tweak the code related to module to be able to generate a correct patch generated by diffing 2 AS7 installations.
When comparing modules to check whether they have been updated, computing the dir's checksum is not correct:
* Jar files generated during AS7 build can not have the same checksum since the creation date of the class files is store in the jar's zip entries.
=> this concerns AS7's own modules (org/jboss/as/...) and also jandex jars for 3rd party libraries
To circumvent that, instead of computing the SHA-1 of the jar files, I compute the checksum of the file's zip entries name/size/crc (ie I exclude the date metadata).
I also need to exclude some entries from the jar:
* Some java sources are generated at build time (logger and bundle classes) and embed their generation date into the code => the .class files have different size and crc
* META-INF/MANIFEST.MF and pom.properties files also contains the jar creation date => these files have different size and crc
When a module dir is compared, .index files (generated at runtime) should not be taken into account (they are not present in the pristine AS7 installations I used to generate the patch by diff)
I have a branch for this[1] which uses the same hash algo (based on the zip entries metadata) for all jars. This could likely be reduced only to jars in org/jboss/as and -jandex.jar.
With these changes, the patch code is able to compute a "suitable" checksum for module.
I also think the module's resource checksum should be based on the content of the module.xml. Only resources listed in the <resources> element should be included in the checksum. Eg adding a README to a module should not change its checksum. This means a 2-step check:
1. check that the module.xml are identical (with a file checksum)
2. check that the resources listed by the module are "equivalent" (with jar-specific checksum for jar + file checksum for other resources)
What do you think?
[1] https://github.com/jmesnil/jboss-as/compare/emuckenhuber:patches-master..... https://github.com/jmesnil/jboss-as/compare/emuckenhuber:patches-master.....
--------------------------------------------------
11 years, 5 months
[JBoss AS 7 Development] - ManagementLayer RBAC
by Heiko Braun
Heiko Braun [https://community.jboss.org/people/heiko.braun] modified the document:
"ManagementLayer RBAC"
To view the document, visit: https://community.jboss.org/docs/DOC-47854
--------------------------------------------------------------
Role based access control to the AS7 management layer.
*Core Concepts*
*
*
When defining an RBAC model, the following conventions are useful:
* Subject = A person or automated agent
* Role = Job function or title which defines an authority level
* Permissions = An approval of a mode of access to a resource
* Action = An operation to execute on a resource
* Constraint: Predicate that makes the permission valid in the context of the system state
* Session = A mapping involving Subject, Role and/or Permissions
https://community.jboss.org/servlet/JiveServlet/showImage/102-47854-28-19... https://community.jboss.org/servlet/JiveServlet/downloadImage/102-47854-2...
*Generic Requirements*
* Provide a usable (in terms of complexity), yet comprehensive base model
* Provide a set of out-of-the-box roles & permissons that reflect common authorization requirements
* Enable customizations/extension of the default scheme (i.e custom permissions, permission granularity)
* Provide management operations to retrieve session information (i.e. roles assigned, permissions granted, etc)
* Clearly distinguish security exceptions from other operation errors (i.e. custom response headers)
* Mappability with existing authorisation schemes (i.e. JON)
*Specific Requirements*
* +Support permission enforcement that restricts visibility of model elements:
+Control visibility of resources (i.e. restrict visibility of server groups)
* +Suppor permission enforcement that restricts execution on model elements+:
Control execution on resources (i.e. lock down certain operations, distinguish read & read/write access)
* +The management layer needs to enforce permission regardless of the client type and availability:
+I.e. enformenent can not be delegated to the client only+
+
* +Clients (CLI, Web) should indicate permissions prior to execution of management operations:+
I.e. grey out interface elements to emphasis lack of permissions
*Use cases*
See https://community.jboss.org/docs/DOC-47856 RBACUsecases*
*
*Advanced Topics*
- Context based access control: i.e. Taking the connection into consideratin
- Support for role hierarchies: i.e. structuring roles to reflect an organizations lines of authority and responsibility
- Role constraints: i.e. mutual exclusive roles
- RBAC to manage RBAC itself
structuring roles to re ect an organiza tion s lines of authority and resp onsibility
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-47854]
Create a new document in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
11 years, 5 months
[JBoss AS 7 Development] - RBAC Usecases
by Heiko Braun
Heiko Braun [https://community.jboss.org/people/heiko.braun] modified the document:
"RBAC Usecases"
To view the document, visit: https://community.jboss.org/docs/DOC-47856
--------------------------------------------------------------
|| *Name* || *Description* || *<Reject/Accept>* ||
| *Restricting access to server groups* | +Configuration+: Server groups: "production", "staging". roles: "admin", "developer"
+Goal+: Restrict access to the production group to the "admin" role in to prevent messing with the production system
+Implications+: Server groups are part of the model but also a logical concept. I.e. restricting access to a group does imply preventing access to conceptually related entities like servers, deployments, etc. |
|
| *Support clients & tools that provide their own security model* | +Configuration+: See JON User Guide (https://access.redhat.com/knowledge/docs/en-US/JBoss_Operations_Network/3...)
+Goal+: Allow interaction with systems that provide their own authorization scheme
+Implications+: Systems like JON, that provide their own scheme currently can only operate the super user level |
|
| *Restrict visibility of attributes* | Suppress attributes on responses, i.e. read-resource | arguable |
| *Restrict visibility of operations* | Suppress operations on reponses, i.e. read-operation-names | arguable |
| *Prevent execution of operations* | Execution of operations with permissions yields a security exception |
|
**
**
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-47856]
Create a new document in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
11 years, 5 months
