Re: [jboss-dev-forums] [JBoss AS 7 Development] - ManagementLayer RBAC
by Brian Stansberry
Brian Stansberry [https://community.jboss.org/people/brian.stansberry] commented on the document
"ManagementLayer RBAC"
To view all comments on this document, visit: https://community.jboss.org/docs/DOC-47854#comment-11140
--------------------------------------------------
I added a requirement to secure JMX interactions that don't end up delegating into the normal ModelController layer (i.e. mbeans outside the jboss-as JMX domain.)
My hope is such mbeans can simply be another type of resource, with a different kind of address (ObjectName instead of PathAddress).
I think that if there is any overlap in the permission configuration between JMX and the core management model, the allowed actions for a given request become the intersection of the sets of permissions. IOW, if the JMX scheme allows access to mbean jboss-as:subsystem=security but the core management model doesn't allow access to /subsystem=security, then the request will fail. This can be accomplished by doing a permission check in the JMX layer, and then the normal core management check is done in the core layer.
Another option is to not allow JMX permissions to be set up for the JMX domains that result in calls into the core management layer.
--------------------------------------------------
11 years, 5 months
[JBoss AS 7 Development] - ManagementLayer RBAC
by Brian Stansberry
Brian Stansberry [https://community.jboss.org/people/brian.stansberry] 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-30-19... https://community.jboss.org/servlet/JiveServlet/downloadImage/102-47854-3...
*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)
* +Support 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
* JMX access that isn't delegated to the ModelController needs to be covered by the permission scheme as well
*Use cases*
See https://community.jboss.org/docs/DOC-47856 RBACUsecases*
*
*Advanced Topics*
- Context based access control: i.e. Taking the connection into consideration
- 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
- Ability to hide the existence of a resource altogether, vs the ability to show its existence but hide its content.
The issue here is in some cases the address of the resource itself may provide sensitive information,
e.g. security-realm=ManagementRealm
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 Development Deployment Framework] - Unfinished deployment in JBoss 7.1.1 on linux
by Zeev Lazarev
Zeev Lazarev [https://community.jboss.org/people/zlazarev256] created the discussion
"Unfinished deployment in JBoss 7.1.1 on linux"
To view the discussion, visit: https://community.jboss.org/message/776731#776731
--------------------------------------------------------------
Hi,
After some porting changes from JBoss 5.1.0 to JBoss 7.1.1 our application worked fine on Windows 7 platform.
When trying to deploy this application on linux machine (both Ubuntu and RedHat, were tried) I encounter an issue
by which deployment enters idle state.
After investigating the issue I realized that a servlet in its init() method is awaiting for the proxy component that
represents my EJB stateless session bean. The code snippets below leads to the 'gate' flag for that component
that on Windows 7 is 'ture' and on linux machine is 'false':
# componentName | CAAdminSessionBean
# componentClass | class org.ejbca.core.ejb.ca.caadmin.CAAdminSessionBean
# org.jboss.as.ejb3.component.stateless.StatelessSessionComponent(org.jboss.as.ee.component.BasicComponent)
protected BasicComponentInstance constructComponentInstance(ManagedReference instance, boolean invokePostConstruct, InterceptorFactoryContext context) {
-> waitForComponentStart();
...
}
protected void waitForComponentStart() {
if (!gate) {
// Block until successful start
synchronized (this) {
if (stopping.get()) {
throw MESSAGES.componentIsStopped();
}
while (!gate) {
// TODO: check for failure condition
try {
-> wait();
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
throw MESSAGES.componentNotAvailable();
}
}
}
}
}
The stack of JBoss Interceptors is given in reverse order to track back the issue that starts in servlet:
The interesting thing is that the proxy for local interface is created (it is represented by View39),
but the bean itselft is not - this is indicated by gate = false flag.
#
# org.ejbca.core.ejb.ca.caadmin.CAAdminSessionLocal$$$View39
# Proxy for view class: org.ejbca.core.ejb.ca.caadmin.CAAdminSessionLocal of EJB: CAAdminSessionBean
# caAdminSession | org.ejbca.core.ejb.ca.caadmin.CAAdminSessionLocal
#
#
# org.ejbca.ui.web.admin.configuration.StartServiceServlet
public void init(ServletConfig config) throws ServletException {
. . .
-> caAdminSession.initializeAndUpgradeCAs(admin);
. . .
}
# org.jboss.as.ee.component.ProxyInvocationHandler
public Object invoke(final Object proxy, final Method method, final Object[] args) throws Throwable {
final Interceptor interceptor = interceptors.get(method);
if (interceptor == null) {
throw new NoSuchMethodError(method.toString());
}
final InterceptorContext context = new InterceptorContext();
// special location for original proxy
context.putPrivateData(Object.class, proxy);
context.putPrivateData(Component.class, component);
context.putPrivateData(ComponentView.class, componentView);
context.setParameters(args);
context.setMethod(method);
// setup the public context data
context.setContextData(new HashMap());
-> return interceptor.processInvocation(context);
}
# org.jboss.invocation.ChainedInterceptor
public Object processInvocation(final InterceptorContext context) throws Exception {
final int oldNext = context.getNextInterceptorIndex();
final List<Interceptor> old = context.getInterceptors();
context.setInterceptors(interceptors);
try {
-> return context.proceed();
} finally {
context.setInterceptors(old, oldNext);
}
}
# org.jboss.invocation.InterceptorContext
public Object proceed() throws Exception {
final ListIterator<Interceptor> iterator = interceptorIterator;
if (iterator.hasNext()) {
Interceptor next = iterator.next();
try {
-> return next.processInvocation(this);
} finally {
if (iterator.hasPrevious()) iterator.previous();
}
} else {
throw msg.cannotProceed();
}
}
# org.jboss.as.ee.component.TCCLInterceptor
public Object processInvocation(final InterceptorContext context) throws Exception {
final ClassLoader oldTccl = SecurityActions.getContextClassLoader();
try {
SecurityActions.setContextClassLoader(classLoader);
-> return context.proceed();
} finally {
SecurityActions.setContextClassLoader(oldTccl);
}
}
#
# org.jboss.as.ejb3.tx.CMTTxInterceptor
public Object processInvocation(InterceptorContext invocation) throws Exception {
final EJBComponent component = (EJBComponent) invocation.getPrivateData(Component.class);
final MethodIntf methodIntf = MethodIntfHelper.of(invocation);
final TransactionAttributeType attr = component.getTransactionAttributeType(methodIntf, invocation.getMethod());
final int timeoutInSeconds = component.getTransactionTimeout(methodIntf, invocation.getMethod());
switch (attr) {
case MANDATORY:
return mandatory(invocation, component);
case NEVER:
return never(invocation, component);
case NOT_SUPPORTED:
return notSupported(invocation, component);
case REQUIRED:
-> return required(invocation, component, timeoutInSeconds);
case REQUIRES_NEW:
return requiresNew(invocation, component, timeoutInSeconds);
case SUPPORTS:
return supports(invocation, component);
default:
throw new IllegalStateException("Unexpected tx attribute " + attr + " on " + invocation);
}
}
# org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor
public Object processInvocation(InterceptorContext context) throws Exception {
PooledComponent<ComponentInstance> component = (PooledComponent<ComponentInstance>) getComponent(context, EJBComponent.class);
-> ComponentInstance instance = component.getPool().get();
context.putPrivateData(ComponentInstance.class, instance);
boolean discarded = false;
try {
# StrictMaxPool
public T get() {
. . .
T bean = null;
try {
// Pool is empty, create an instance
-> bean = create();
} finally {
. . .
return bean;
}
# org.jboss.as.ejb3.component.stateless.StatelessSessionComponent
StatelessObjectFactory<StatelessSessionComponentInstance> factory = new StatelessObjectFactory<StatelessSessionComponentInstance>() {
@Override
public StatelessSessionComponentInstance create() {
-> return (StatelessSessionComponentInstance) createInstance();
}
@Override
public void destroy(StatelessSessionComponentInstance obj) {
obj.destroy();
}
};
# componentName | CAAdminSessionBean
# componentClass | class org.ejbca.core.ejb.ca.caadmin.CAAdminSessionBean
# org.jboss.as.ejb3.component.stateless.StatelessSessionComponent(org.jboss.as.ee.component.BasicComponent)
protected BasicComponentInstance constructComponentInstance(ManagedReference instance, boolean invokePostConstruct, InterceptorFactoryContext context) {
-> waitForComponentStart();
...
}
protected void waitForComponentStart() {
if (!gate) {
// Block until successful start
synchronized (this) {
if (stopping.get()) {
throw MESSAGES.componentIsStopped();
}
while (!gate) {
// TODO: check for failure condition
try {
-> wait();
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
throw MESSAGES.componentNotAvailable();
}
}
}
}
}
The structure of the application ear file is 8 war modules, 2 ejb modules and the library jars under lib entry:
adminweb.war
...
more 7 wars
...
ejbca-ejb.jar
ejbca-ws-ejb.jar
I tried following things:
1. Changed @Stateless(mappedName=__old_jndiName__ to
@Stateless(mappedName=java:global/ejbca/ejbca-ejb/CAAdminSessionBean!org.ejbca.ca.caadmin.CAAdminSessionRemote)
2. Added below entry to standalone.xml to explicitly tie war module with ejb.
<ear-subdeployments-isolated>false</ear-subdeployments-isolated>
3. Added jboss-deployment-structure.xml file to META-INF of ear file to explicitly tie war module with ejb.
<jboss-deployment-structure>
<sub-deployment name="adminweb.war">
<dependencies>
<module name="deployment.ejbca.ear.ejbca-ejb.jar" />
</dependencies>
</sub-deployment>
</jboss-deployment-structure>
The latter led to unnecessary dependencies errors in the logs.
Please advise.
Thanks.
Zeev
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/776731#776731]
Start a new discussion in JBoss AS Development Deployment Framework at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
11 years, 5 months
[JBoss Web Services Development] - JAX-WS fails to unmarshal payload due to strict namespaces
by Morten Nyhaug
Morten Nyhaug [https://community.jboss.org/people/morten.nyhaug] created the discussion
"JAX-WS fails to unmarshal payload due to strict namespaces"
To view the discussion, visit: https://community.jboss.org/message/776631#776631
--------------------------------------------------------------
I have a web service that receives the following payload
{code:xml}
<soap-env:Envelope xmlns:soap-env=" http://schemas.xmlsoap.org/soap/envelope/ http://schemas.xmlsoap.org/soap/envelope/">
<soap-env:Header/>
<soap-env:Body>
<mm7:DeliverReq xmlns:mm7=" http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0 http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0">
<MM7Version>5.3.0</MM7Version>
</mm7:DeliverReq>
</soap-env:Body>
</soap-env:Envelope>
{code}
I have generated classes for the schema using xjc, and created a webservice with an endpoint interface to receive it
{code}
@WebService(name = "deliver")
@SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE)
@XmlSeeAlso({
org._3gpp.ftp.specs.archive._23_series._23_140.schema.rel_5_mm7_1_0.ObjectFactory.class
})
public interface Rel5Mm710ReceiverApi {
@WebMethod(action = "deliverRequest")
@WebResult(name = "DeliverRsp", targetNamespace = " http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0 http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0")
public DeliverRspType deliverRequest(
@WebParam(name = "DeliverReq", targetNamespace = " http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0 http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0")
DeliverReqType request);
}
{code}
{code}
@WebService(serviceName = "soap")
@HandlerChain(file = "handler.xml")
public class InboundApi implements Rel5Mm710ReceiverApi {
@Override
@WebMethod
public DeliverRspType deliverRequest(DeliverReqType request) {
...
}
}
{code}
When I deploy this service on jboss as 7.1 and test it with soap ui by sending in the payload shown above, I get the following error:
{noformat}
10:52:56,107 WARNING [org.apache.cxf.phase.PhaseInterceptorChain] (http--127.0.0.1-8080-1) Interceptor for { http://mms.tele2.returia.nrk.no/ http://mms.tele2.returia.nrk.no/}soap#{ http://api.mm7.returia.nrk.no/ http://api.mm7.returia.nrk.no/}deliverRequest has thrown exception, unwinding now: org.apache.cxf.interceptor.Fault: Unmarshalling Error: unexpected element (uri:"", local:"MM7Version"). Expected elements are <{ http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0 http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1...>,<{ http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0 http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1...>,<{ http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0 http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1...>,<{ http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0 http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1...>,<{ http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0 http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1...>,<{ http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0 http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1...>,<{ http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0 http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1...>,<{ http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0 http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1...>,<{ http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0 http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1...>,<{ http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0 http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1...>
at org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:801)
at org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:642)
at org.apache.cxf.jaxb.io.DataReaderImpl.read(DataReaderImpl.java:156)
at org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:201)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:207)
...
Caused by: javax.xml.bind.UnmarshalException
- with linked exception:
[javax.xml.bind.UnmarshalException: unexpected element (uri:"", local:"MM7Version"). Expected elements are <{ http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0 http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1...>,<{ http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0 http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1...>,<{ http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0 http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1...>,<{ http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0 http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1...>,<{ http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0 http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1...>,<{ http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0 http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1...>,<{ http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0 http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1...>,<{ http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0 http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1...>,<{ http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0 http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1...>,<{ http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0 http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1...>]
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.handleStreamException(UnmarshallerImpl.java:434)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:371)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:348)
at org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:778)
... 31 more
{noformat}
The funny thing is, if I try to unmarshal this using JAXB, I get no errors at all. If I try to modify the payload so that it is like this:
{code:xml}
<mm7:DeliverReq xmlns:mm7=" http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0 http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0">
<mm7:MM7Version>5.3.0</mm7:MM7Version>
</mm7:DeliverReq>
{code}
I also get no errors. Obviously changing the payload is not an option since I cant control what 3rd parties are sending me.
How can I get rid of this error? How can I tell JAX-WS to not be so strict regarding namespaces?
I have tried using a SOAPHandler to set some properties or other, but no amount of googeling has led me to the correct solution. Since JAXB is able to unmarshal this, then surly it must be possible to make JAX-WS do this as well?
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/776631#776631]
Start a new discussion in JBoss Web Services 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:
*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-8-198... https://community.jboss.org/servlet/JiveServlet/downloadImage/102-47689-8...
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"/>
Lastly, you can execute the +list-active-jsf-impls+ operation. This is useful if you are writing an AS7 client and you need the list of impls as a ModelType.LIST.
/subsystem=jsf/:list-active-jsf-impls
{
"outcome" => "success",
"result" => [
"myfaces-2.1.8",
"mojarra-2.2.0-m05",
"1.2",
"main"
]
}
*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
[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-5-198... https://community.jboss.org/servlet/JiveServlet/downloadImage/102-47689-5...
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
