[JBoss AS 7 Development] - Remote ejb call issue from client code to jboss eap 6.0.1 server
by Sunil Chaurasia
Sunil Chaurasia [https://community.jboss.org/people/sunildell] created the discussion
"Remote ejb call issue from client code to jboss eap 6.0.1 server"
To view the discussion, visit: https://community.jboss.org/message/824017#824017
--------------------------------------------------------------
Hi,
We are facing an issue when the client application is pointing to our Jboss Dev environment. Client application makes call to backend service(deployed on jboss) for the purpose of caching templates at their end. The templates are 233 in number. So, backend api is called through ejb lookup for 233 iterations. The response is send back to client correctly for first four iterations and for the fifth iteration an exception is thrown.
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
log4j:WARN No appenders could be found for logger (org.jboss.logging).
log4j:WARN Please initialize the log4j system properly.
Time taken templates for group 139232 -->0:00:01.470
Time taken prefences for group 139232 -->0:00:01.390
Time taken templates for group 138689 -->0:00:00.871
Time taken prefences for group 138689 -->0:00:00.855
Exception in thread "main" java.lang.reflect.UndeclaredThrowableException
at com.sun.proxy.$Proxy3.getTemplatesByTemplateCode(Unknown Source)
at com.fares.preference.ifc.delegate.PreferenceServiceBD.getTemplatesByTemplateCode(PreferenceServiceBD.java:242)
at TestK2Cache.main(TestK2Cache.java:53)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:90)
Caused by: org.jboss.remoting3.MessageCancelledException
at org.xnio.streams.BufferPipeInputStream.checkFailure(BufferPipeInputStream.java:280)
at org.xnio.streams.BufferPipeInputStream.read(BufferPipeInputStream.java:125)
at org.jboss.remoting3.remote.InboundMessage$3.read(InboundMessage.java:122)
at java.io.DataInputStream.readByte(DataInputStream.java:248)
at org.jboss.ejb.client.remoting.ProtocolMessageHandler$1.read(ProtocolMessageHandler.java:91)
at java.io.InputStream.read(InputStream.java:151)
at java.io.FilterInputStream.read(FilterInputStream.java:116)
at java.io.FilterInputStream.read(FilterInputStream.java:90)
at org.jboss.marshalling.SimpleDataInput.read(SimpleDataInput.java:58)
at org.jboss.marshalling.river.BlockUnmarshaller.readToEndBlockData(BlockUnmarshaller.java:109)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1260)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37)
at org.jboss.ejb.client.remoting.MethodInvocationResponseHandler$MethodInvocationResultProducer.getResult(MethodInvocationResponseHandler.java:107)
at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:272)
at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:46)
at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:274)
at org.jboss.ejb.client.ReceiverInterceptor.handleInvocationResult(ReceiverInterceptor.java:129)
at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:262)
at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:437)
at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:140)
at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:121)
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:104)
... 8 more
Caused by: an exception which occurred:
in object of type com.fares.preference.ifc.model.DataElementDisplayInfo
in object of type com.fares.preference.ifc.model.DataElement
in element at index [42] of size [48]
in object of type com.fares.preference.ifc.model.Template
in element at index [0] of size [2]
in object of type com.fares.preference.ifc.model.Template
in element at index [0] of size [4]
in object of type com.fares.preference.ifc.model.Template
in element at index [1] of size [5]
in object of type com.fares.preference.ifc.model.Template
in element at index [8] of size [19]
in object of type com.fares.preference.ifc.model.PreferenceData
in object of type com.fares.preference.ifc.model.PreferenceOutData
We have checked that this is not data issue as we have removed the 5th element and in that case it fails for next iteration.
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/824017#824017]
Start a new discussion in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
11 years, 7 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
--------------------------------------------------------------
+*Note: For AS7, this feature was considered experimental. It has been much improved in WildFly. See Design of WildFly Multi-JSF feature (https://community.jboss.org/docs/DOC-48903) for details*+.
*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.2 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 a new attribute to the JSF subsystem. +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-13-19... https://community.jboss.org/servlet/JiveServlet/downloadImage/102-47689-1...
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"/>
To see which JSF impls are installed, you can execute the +list-active-jsf-impls+ operation.
/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 use these *.cli files with the https://ci.jboss.org/jenkins/job/JBoss-AS-7.x-latest/ latest nightly build of AS7 (jboss-as-7.2.0.Alpha1-SNAPSHOT).
--------------------------------------------------------------
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, 7 months
[JBoss AS 7 Development] - WildFly - login page cannot access css files (FORM based authentication)
by Marcos Antonio
Marcos Antonio [https://community.jboss.org/people/marcos_aps] created the discussion
"WildFly - login page cannot access css files (FORM based authentication)"
To view the discussion, visit: https://community.jboss.org/message/823742#823742
--------------------------------------------------------------
Hello, everybody!
I'm trying WildFly. After I enabled FORM based authenticaton in my simple web application, the login page (or container) cannot access the css files located in the /resources/css directory. That is working in a JBoss 7.1 application that I have in production with the same configuration. This is the relevant configuration in my simple application using WildFly:
*web.xml:*
<security-constraint>
<web-resource-collection>
<web-resource-name>restricted</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>USUARIO</role-name>
</auth-constraint>
</security-constraint>
<security-constraint>
<web-resource-collection>
<web-resource-name>allowed</web-resource-name>
<url-pattern>/modelos/*</url-pattern>
<url-pattern>/resources/*</url-pattern>
</web-resource-collection>
</security-constraint>
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/login.xhtml</form-login-page>
<form-error-page>/errologin.xhtml</form-error-page>
</form-login-config>
</login-config>
<security-role>
<role-name>USUARIO</role-name>
</security-role>
<security-role>
<role-name>NAO_AUTORIZADO</role-name>
</security-role>
*jboss-web.xml:*
<?xml version="1.0" encoding="UTF-8"?>
<jboss-web>
<security-domain>solicitacoes</security-domain>
</jboss-web>
*standalone.xml:*
<security-domain name="solicitacoes" cache-type="default">
<authentication>
<login-module code="br.urca.solicitacoes.visao.ModuloLogin" flag="required"/>
</authentication>
</security-domain>
So, what am I missing or doing wrong?
Thank you.
Marcos
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/823742#823742]
Start a new discussion in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
11 years, 7 months
[JBoss Tools Development] - Adding a Plugin (and/or Feature) To An Existing Component
by Mickael Istria
Mickael Istria [https://community.jboss.org/people/mickael_istria] modified the document:
"Adding a Plugin (and/or Feature) To An Existing Component"
To view the document, visit: https://community.jboss.org/docs/DOC-18373
--------------------------------------------------------------
+First, read this document on how to build JBoss Tools components locally: https://community.jboss.org/docs/DOC-16604 https://community.jboss.org/wiki/HowtoBuildJBossToolswithMaven3+
| *+Before adding a complete new feature to JBoss Tools announce the addition on jbosstools-dev <jbosstools-dev(a)lists.jboss.org > with reasons WHY+* *+a new feature is needed and what new (if any) dependencies it will bring in. New dependencies need to be added to the target platforms, and thus should be reported in JIRA for tracking and task assignment purposes.+*
*+Note too that new features will often start in+ JBoss Tools +but NOT be included in+ JBoss Developer Studio +until they have had time to mature. If your new feature needs to be in both offerings, please be sure to explain WHY when contacting the above mailing list.+* |
h2. Adding a new plugin or feature to JBoss Tools
Now that you can build your component, you can easily add a new plugin to that component. Here's how.
*0.* Make sure your new plugin compiles in your workspace. Ensure your MANIFEST.MF contains all references/includes/requirements you need. Be sure to set the correct Bundle-RequireExecutionEnvironment (eg., JDK5 or JDK6).
*1.* When you are satisfied, you can commit your new plugin project to Git.
cd ~/git/jbosstools-server/as/plugins; \
git add org.jboss.ide.eclipse.as.rse.core; \
git commit -m "JBIDE-123456 Initial commit of new as.rse.core plugin"
*2.* Next, add a pom.xml file to the root of your new project.
You can use m2eclipse to help w/ this if you have it installed; otherwise copy from another existing plugin project and edit appropriately. The version of the pom should match the version in the manifest.mf. Note that 3.2.0.qualifier (in MANIFEST.MF) is equivalent to 3.2.0-SNAPSHOT in the pom.xml.
*3.* Build your plugin:
cd ~/git/jbosstools-server/as/plugins/org.jboss.ide.eclipse.as.rse.core; \
mvn clean verify
*4.* If your component's new plugin builds successfully, you can commit the pom.xml file, and add a reference to the new plugin (module) in the container pom:
cd ~/git/jbosstools-server/as/plugins; \
git add pom.xml
*5.* To ensure that your plugin is available on the update site, be sure that it is contained in at least one feature's feature.xml.
cd ~/git/jbosstools-server/as/features; \
vim org.jboss.ide.eclipse.as.feature/feature.xml
*6.* If necessary, create a new feature to contain the new plugin - easiest approach is to copy an existing feature project, and string-replace the various files until it suits your needs. Don't forget to update .project and other hidden files.
git add org.jboss.ide.eclipse.as.new.feature; \
svn ci -m "JBIDE-123456 Initial commit of new as.new feature"
*7.* If your component's new feature builds successfully, you can commit the pom.xml file, and add a reference to the new plugin (module) in the container pom:
cd ~/git/jbosstools-server/as/features; \
vim /features/pom.xml
h3. Verifying your new feature/plugin can be built and installed:
*8.* Next, ensure that the feature appears in all appropriate JBoss Tools update sites:
vi ~/git/jbosstools-server/site/category.xml # (the component's update site)
+
+
+ and one of the following+
vi ~/jbosstools-build-sites/aggregate/site/category.xml # (the JBoss Tools aggregate update site)
vi ~/jbosstools-build-sites/aggregate/coretests-site/category.xml # (the JBoss Tools aggregate update site for test plugins)
+ or one of these two sites:+
vi ~/jbosstools-build-sites/aggregate/soa-site/category.xml # (the JBoss Tools aggregate update site for SOA Tooling)
vi ~/jbosstools-build-sites/aggregate/soatests-site/category.xml # (the JBoss Tools aggregate update site for SOA Tooling test plugins)
+ Note: for *AS, and any DEPENDENCIES of AS,* you MAY want to add your new feature to this site too, if and only if astools makes use of that plugin / feature:+
vi ~/jbosstools-build-sites/aggregate/webtools-site/category.xml # (the JBoss Tools aggregate update site for WTP adapters)
*9.* Finally, build the sites locally to ensure the XML is valid and the contents appear correctly. You can then install the new feature from the sites into Eclipse or JBDS to verify it runs as expected (no missing dependencies which prevent the plugin from being activated, no missing metadata such as description, provider, license or copyright while installing, etc.)
cd ~/git/jbosstools-server/; mvn clean verify; # then point Eclipse at ~/git/jbosstools-server/site/target/repository/
+ and+
cd ~/git/jbosstools-build-site/aggregate/site; mvn clean verify; # then point Eclipse at ~/git/jbosstools-build-site/aggregate/site/target/site/
h2.
h2. Adding a new plugin or feature to JBoss Developer Studio
*10.* Next, ensure that the feature appears in all appropriate JBoss Developer Studio update site:
vi ~/git/jbdevstudio-product/site/category.xml # (the JBoss Developer Studio aggregate update site)
*11.* If you added a new feature, be sure that the feature is included in the JBDS feature (or wrapped inside another feature) so that it will appear in the installer.
vi ~/git/jbdevstudio-product/features/com.jboss.jbds.product.feature/feature.xml
h3.
h3. Verifying your new feature/plugin can be built and installed:
*12.* Finally, build the sites locally to ensure the XML is valid and the contents appear correctly. You can then install the new feature from the sites into Eclipse or JBDS to verify it runs as expected (no missing dependencies which prevent the plugin from being activated, no missing metadata such as description, provider, license or copyright while installing, etc.)
*
*
cd ~/git/jbdevstudio-product; mvn clean verify # then point JBDS at ~/git/jbdevstudio-product/features/com.jboss.jbds/target/repository/ (search for "Branded Product" feature, *com.jboss.jbds.all*)*
+* - The product site in+ ~/git/jbdevstudio-product+/site/target/site/ does not contain the "Branded Product" feature, *com.jboss.jbds.all*, so you cannot use that site to update an existing JBDS install, only an Eclipse install.+
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-18373]
Create a new document in JBoss Tools Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
11 years, 7 months
[JBoss Remoting Development] - Isolated EJB2 Access from a Client - Jboss 4.3 EAP
by Rodel Talampas
Rodel Talampas [https://community.jboss.org/people/limacon] created the discussion
"Isolated EJB2 Access from a Client - Jboss 4.3 EAP"
To view the discussion, visit: https://community.jboss.org/message/823582#823582
--------------------------------------------------------------
Hi..
I have a task to Isolate Class libraries between 2 Enterprise Application A.ear and B.ear. B EJB requires to Access A's Remote EJB, but it is throwing exception. But calling A's client to call A's ejb does not have a problem.What am I missing? The failure is very very odd because it is saying ClassNotfound for an object in B while B is accessing EJB in A. The class is in B's lib directory. Stacktrace below:
2013-06-18 13:22:51,644 ERROR [com.cassis.reqmgr.jobmgr.ExecuteJob_Bean] executeAsyncJob(): Exception: java.rmi.MarshalException: MarshalException; nested exception is:
org.jboss.invocation.JBossLazyUnmarshallingException: getArguments failed
2013-06-18 13:22:51,645 ERROR [STDERR] java.lang.Exception: java.rmi.MarshalException: MarshalException; nested exception is:
org.jboss.invocation.JBossLazyUnmarshallingException: getArguments failed
2013-06-18 13:22:51,645 ERROR [STDERR] at com.cassis.reqmgr.jobmgr.ExecuteJob_Bean.performIPU(ExecuteJob_Bean.java:209)
2013-06-18 13:22:51,645 ERROR [STDERR] at com.cassis.reqmgr.jobmgr.ExecuteJob_Bean.executeAsyncJob(ExecuteJob_Bean.java:95)
2013-06-18 13:22:51,645 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
2013-06-18 13:22:51,645 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
2013-06-18 13:22:51,645 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
2013-06-18 13:22:51,645 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:597)
2013-06-18 13:22:51,645 ERROR [STDERR] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
2013-06-18 13:22:51,646 ERROR [STDERR] at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:166)
2013-06-18 13:22:51,646 ERROR [STDERR] at org.jboss.ejb3.interceptor.EJB3InterceptorsInterceptor.invoke(EJB3InterceptorsInterceptor.java:63)
2013-06-18 13:22:51,646 ERROR [STDERR] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
2013-06-18 13:22:51,646 ERROR [STDERR] at org.jboss.ejb3.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:57)
2013-06-18 13:22:51,646 ERROR [STDERR] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
2013-06-18 13:22:51,646 ERROR [STDERR] at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:54)
2013-06-18 13:22:51,646 ERROR [STDERR] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
2013-06-18 13:22:51,646 ERROR [STDERR] at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
2013-06-18 13:22:51,646 ERROR [STDERR] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
2013-06-18 13:22:51,646 ERROR [STDERR] at org.jboss.ejb3.timer.TimerTxRegistrationInterceptor.invoke(TimerTxRegistrationInterceptor.java:38)
2013-06-18 13:22:51,646 ERROR [STDERR] at org.jboss.ejb3.timer.TimerTxRegistrationInterceptor.invoke(TimerTxRegistrationInterceptor.java:29)
2013-06-18 13:22:51,646 ERROR [STDERR] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
2013-06-18 13:22:51,646 ERROR [STDERR] at org.jboss.aspects.tx.TxPolicy.invokeInNoTx(TxPolicy.java:66)
2013-06-18 13:22:51,646 ERROR [STDERR] at org.jboss.aspects.tx.TxInterceptor$NotSupported.invoke(TxInterceptor.java:112)
2013-06-18 13:22:51,646 ERROR [STDERR] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
2013-06-18 13:22:51,646 ERROR [STDERR] at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:94)
2013-06-18 13:22:51,647 ERROR [STDERR] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
2013-06-18 13:22:51,647 ERROR [STDERR] at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:70)
2013-06-18 13:22:51,647 ERROR [STDERR] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
2013-06-18 13:22:51,647 ERROR [STDERR] at org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
2013-06-18 13:22:51,647 ERROR [STDERR] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
2013-06-18 13:22:51,647 ERROR [STDERR] at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:77)
2013-06-18 13:22:51,647 ERROR [STDERR] at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:139)
2013-06-18 13:22:51,647 ERROR [STDERR] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
2013-06-18 13:22:51,647 ERROR [STDERR] at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:46)
2013-06-18 13:22:51,647 ERROR [STDERR] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
2013-06-18 13:22:51,647 ERROR [STDERR] at org.jboss.ejb3.interceptor.EJB3TCCLInterceptor.invoke(EJB3TCCLInterceptor.java:86)
2013-06-18 13:22:51,647 ERROR [STDERR] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
2013-06-18 13:22:51,647 ERROR [STDERR] at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
2013-06-18 13:22:51,647 ERROR [STDERR] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
2013-06-18 13:22:51,647 ERROR [STDERR] at org.jboss.ejb3.stateless.StatelessContainer.localInvoke(StatelessContainer.java:217)
2013-06-18 13:22:51,647 ERROR [STDERR] at org.jboss.ejb3.stateless.StatelessContainer.localInvoke(StatelessContainer.java:187)
2013-06-18 13:22:51,648 ERROR [STDERR] at org.jboss.ejb3.stateless.StatelessLocalProxy.invoke(StatelessLocalProxy.java:81)
2013-06-18 13:22:51,648 ERROR [STDERR] at $Proxy586.executeAsyncJob(Unknown Source)
2013-06-18 13:22:51,648 ERROR [STDERR] at com.cassis.reqmgr.jobmgr.ExecuteJobInvoker.invokeExecuteAsyncJob(ExecuteJobInvoker.java:74)
2013-06-18 13:22:51,648 ERROR [STDERR] at com.cassis.reqmgr.jobmgr.ExecuteJobInvoker.run(ExecuteJobInvoker.java:63)
2013-06-18 13:22:51,648 ERROR [STDERR] at java.lang.Thread.run(Thread.java:662)
2013-06-18 13:22:51,648 ERROR [STDERR] Caused by: java.rmi.MarshalException: MarshalException; nested exception is:
org.jboss.invocation.JBossLazyUnmarshallingException: getArguments failed
2013-06-18 13:22:51,648 ERROR [STDERR] at org.jboss.ejb.Container.invoke(Container.java:1010)
2013-06-18 13:22:51,648 ERROR [STDERR] at sun.reflect.GeneratedMethodAccessor137.invoke(Unknown Source)
2013-06-18 13:22:51,648 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
2013-06-18 13:22:51,648 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:597)
2013-06-18 13:22:51,648 ERROR [STDERR] at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
2013-06-18 13:22:51,648 ERROR [STDERR] at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
2013-06-18 13:22:51,648 ERROR [STDERR] at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
2013-06-18 13:22:51,648 ERROR [STDERR] at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
2013-06-18 13:22:51,649 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
2013-06-18 13:22:51,649 ERROR [STDERR] at org.jboss.invocation.local.LocalInvoker$MBeanServerAction.invoke(LocalInvoker.java:169)
2013-06-18 13:22:51,649 ERROR [STDERR] at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:118)
2013-06-18 13:22:51,649 ERROR [STDERR] at org.jboss.invocation.InvokerInterceptor.invokeLocalMarshalled(InvokerInterceptor.java:295)
2013-06-18 13:22:51,649 ERROR [STDERR] at org.jboss.invocation.MarshallingInvokerInterceptor.invoke(MarshallingInvokerInterceptor.java:61)
2013-06-18 13:22:51,649 ERROR [STDERR] at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:61)
2013-06-18 13:22:51,649 ERROR [STDERR] at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:70)
2013-06-18 13:22:51,649 ERROR [STDERR] at org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionInterceptor.java:112)
2013-06-18 13:22:51,649 ERROR [STDERR] at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:100)
2013-06-18 13:22:51,649 ERROR [STDERR] at $Proxy588.execute(Unknown Source)
2013-06-18 13:22:51,649 ERROR [STDERR] at com.cassis.reqmgr.jobmgr.ExecuteJob_Bean.performIPU(ExecuteJob_Bean.java:199)
2013-06-18 13:22:51,649 ERROR [STDERR] ... 43 more
2013-06-18 13:22:51,649 ERROR [STDERR] Caused by: org.jboss.invocation.JBossLazyUnmarshallingException: getArguments failed
2013-06-18 13:22:51,650 ERROR [STDERR] at org.jboss.invocation.MarshalledInvocation.getArguments(MarshalledInvocation.java:513)
2013-06-18 13:22:51,650 ERROR [STDERR] at org.jboss.ejb.Container.invoke(Container.java:924)
2013-06-18 13:22:51,650 ERROR [STDERR] ... 61 more
2013-06-18 13:22:51,650 ERROR [STDERR] Caused by: java.lang.ClassNotFoundException: No ClassLoaders found for: com.cassis.reqmgr.bo.basic.ProgramUnitType
2013-06-18 13:22:51,650 ERROR [STDERR] at org.jboss.mx.loading.LoadMgr3.beginLoadTask(LoadMgr3.java:306)
2013-06-18 13:22:51,650 ERROR [STDERR] at org.jboss.mx.loading.RepositoryClassLoader.loadClassImpl(RepositoryClassLoader.java:534)
2013-06-18 13:22:51,650 ERROR [STDERR] at org.jboss.mx.loading.RepositoryClassLoader.loadClass(RepositoryClassLoader.java:428)
2013-06-18 13:22:51,650 ERROR [STDERR] at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
2013-06-18 13:22:51,650 ERROR [STDERR] at java.lang.Class.forName0(Native Method)
2013-06-18 13:22:51,650 ERROR [STDERR] at java.lang.Class.forName(Class.java:247)
2013-06-18 13:22:51,650 ERROR [STDERR] at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:603)
2013-06-18 13:22:51,650 ERROR [STDERR] at org.jboss.invocation.MarshalledValueInputStream.resolveClass(MarshalledValueInputStream.java:109)
2013-06-18 13:22:51,650 ERROR [STDERR] at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1574)
2013-06-18 13:22:51,650 ERROR [STDERR] at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1495)
2013-06-18 13:22:51,651 ERROR [STDERR] at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1731)
2013-06-18 13:22:51,651 ERROR [STDERR] at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
2013-06-18 13:22:51,651 ERROR [STDERR] at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1946)
2013-06-18 13:22:51,651 ERROR [STDERR] at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1870)
2013-06-18 13:22:51,651 ERROR [STDERR] at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752)
2013-06-18 13:22:51,651 ERROR [STDERR] at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
2013-06-18 13:22:51,651 ERROR [STDERR] at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1666)
2013-06-18 13:22:51,651 ERROR [STDERR] at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1322)
2013-06-18 13:22:51,651 ERROR [STDERR] at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1946)
2013-06-18 13:22:51,651 ERROR [STDERR] at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1870)
2013-06-18 13:22:51,651 ERROR [STDERR] at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752)
2013-06-18 13:22:51,651 ERROR [STDERR] at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
2013-06-18 13:22:51,651 ERROR [STDERR] at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1666)
2013-06-18 13:22:51,651 ERROR [STDERR] at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1322)
2013-06-18 13:22:51,651 ERROR [STDERR] at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350)
2013-06-18 13:22:51,652 ERROR [STDERR] at org.jboss.invocation.MarshalledValue.get(MarshalledValue.java:91)
2013-06-18 13:22:51,652 ERROR [STDERR] at org.jboss.invocation.MarshalledInvocation.getArguments(MarshalledInvocation.java:509)
2013-06-18 13:22:51,652 ERROR [STDERR] ... 62 more
I only saw a few having the same problem but no concrete solution. Any help will be very much appreciated.
*A's jboss-app.xml*
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE jboss-app PUBLIC
"-//JBoss//DTD J2EE Application 1.4//EN"
" http://www.jboss.org/j2ee/dtd/jboss-app_4_0.dtd http://www.jboss.org/j2ee/dtd/jboss-app_4_0.dtd">
<jboss-app>
<loader-repository>A:archive=A.ear</loader-repository>
</jboss-app>
*A's jboss-classloading xml*
<?xml version="1.0" encoding="UTF-8"?>
<classloading xmlns="urn:jboss:classloading:1.0"
parent-first="false"
domain="A.ear"
top-level-classloader="true"
parent-domain="DefaultDomain"
export-all="ALL"
import-all="true">
</classloading>
*A's ejb jboss.xml*
<loader-repository>A:archive=A.ear</loader-repository>
<classloading xmlns="urn:jboss:classloading:1.0"
parent-first="false"
domain="A_Ejb.jar"
top-level-classloader="true"
parent-domain="A.ear"
export-all="NON_EMPTY"
import-all="true">
</classloading>
*B's jboss-app xml*
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE jboss-app PUBLIC
"-//JBoss//DTD J2EE Application 1.4//EN"
" http://www.jboss.org/j2ee/dtd/jboss-app_4_0.dtd http://www.jboss.org/j2ee/dtd/jboss-app_4_0.dtd">
<jboss-app>
<loader-repository>B:archive=B.ear<loader-repository-config>java2ParentDelegation=false</loader-repository-config>
</loader-repository>
</jboss-app>
*B's jboss-classloading xml*
<?xml version="1.0" encoding="UTF-8"?>
<classloading xmlns="urn:jboss:classloading:1.0"
domain="B.ear"
top-level-classloader="true"
export-all="ALL"
import-all="true">
</classloading>
*B's ejb jboss xml*
<loader-repository>RequestManager:archive=TSM.ear<loader-repository-config>java2ParentDelegation=false</loader-repository-config>
*B's ejb jboss classloading xml*
<?xml version="1.0" encoding="UTF-8"?>
<classloading xmlns="urn:jboss:classloading:1.0"
parent-first="false"
domain="B_ejb.jar"
top-level-classloader="true"
parent-domain="B.ear"
export-all="NON_EMPTY"
import-all="true">
</classloading>
Any help will be very much appreaciated.
Thanks and regards,
Rodel
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/823582#823582]
Start a new discussion in JBoss Remoting Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
11 years, 7 months
[Clustering Development] - How to package and deploy partially distributed app?
by Mikal Henriksen
Mikal Henriksen [https://community.jboss.org/people/stylpe] created the discussion
"How to package and deploy partially distributed app?"
To view the discussion, visit: https://community.jboss.org/message/823524#823524
--------------------------------------------------------------
Disclamer: I might be thinking about this entirely wrong, so if this seems like nonsense, that's why :)
I've been working on extracting a bottleneck from a huge spaghetti ball of a project into a separate war, and I've gotten to the point where it works when deploying in the same ear as the rest of the components (two more wars, an ejb-jar, and a shared jar with common classes, remote interfaces etc), and all communication from the new war happens over remote interfaces to the ejb-jar (avoiding hitting the database in the new war).
My idea was to run this in a distributed setup using some form of JBoss (7.1.1 currently) clustering, where the 'master' node runs the big fat ear with everything and the database, and several cheaper nodes run only the newly-extracted war, communicating with the master node as needed (and caching the results obviousy). I'm planning to improve this later to take advantage of Infinispan for caching, and a managed domain for deployment, but for now I'm just trying to get as simple a case as possible to work. *How should I configure, package and deploy this?*
So far I've been able to run two standalone-full-ha servers, but when deploying the full ear on one and a slim-ear on the other (using the same <application-name> (this is probably stupid)), it is unable to lookup EJBs from the slim-ear to the full-eat. It feels like I'm not seeing something obvious here.
I'm not sure what details to provide, so please ask!
- Mikal
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/823524#823524]
Start a new discussion in Clustering Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
11 years, 7 months
[JBoss AS 7 Development] - Single Installation Patching
by Emanuel Muckenhuber
Emanuel Muckenhuber [https://community.jboss.org/people/emuckenhuber] modified the document:
"Single Installation Patching"
To view the document, visit: https://community.jboss.org/docs/DOC-47500
--------------------------------------------------------------
This article outlines design notes for the single instance patching feature being developed for AS 7.2.
The 7.2 version of the feature will be to apply a patch to a single installation of the AS (i.e. a single unzip of the AS distribution.) That single installation may be used for a standalone server or for a managed domain Host Controller and servers. However, the 7.2 version will not support coordinated patching by the patching tool of multiple installation in a managed domain. The user can of course independently patch multiple installations in a domain, coordinating the application of those patches themselves.
The basic patching process will consist of:
1. The user obtains a patch file.
2. The user uses the CLI tool to connect to a standalone server or Host Controller that is running on the installation that is to be patched.1. The server or Host Controller may be running in admin-only mode or running normally. However, some patches may not be able to be applied if the target process isn't running in admin-only mode
3. The user invokes a command on the CLI providing the location of the patch file. The CLI invokes an operation(s) on the target process telling it to stage the patch.
4. The target process stages the patch by applying the patch contents to the filesystem.1. The changes made to the filesystem during staging should not affect the running operation of the server. If this is not possible, the server should reject the patch with an error message indicating that it needs to be placed in admin-only mode before applying the patch.
5. The user uses the CLI tool to restart the target process. Upon restart the staged patch is visible in the runtime.
Patches can also be rolled back:
1. The CLI tool can be used to instruct the target process to revert a patch.
2. Patch reversion results in changes to the filesystem that are staged in the same manner as what is done with a patch installation.1. The changes made to the filesystem during patch rollback staging should not affect the running operation of the server. If this is not possible, the server should reject the patch rollback with an error message indicating that it needs to be placed in admin-only mode before rolling back the patch.
3. The CLI tool is used to restart the target process. Upon restart the rolled back patch is no longer visible in the runtime.
h1. Patch File
A patch file is a zip archive that contains a patch.xml file that is used to describe the patch along with the updated modules, OSGi bundles and miscellaneous files that comprise the patch. It's structure is as follows:
+ patch.xml
+ modules
++ patch modules in the same structure as they appear the modules dir in the normal AS dist
+ bundles
++ patch bundles in the same structure as they appear the bundles dir in the normal AS dist
+ misc
++ misc files that need to be updated, organized in a directory structure that matches the directory structure of the AS dist
h3. The patch.xml File
The patch.xml file describes the patch. It includes basic information about the patch along with metadata about the modules, bundles and misc files in the patch.
h5. Basic patch metadata
* The name of the patch
* The type of the patch (one-off vs cumulative, etc -- TODO list all)
* The version to which the patch applies
* A text description of the patch
* TODO others
h5. Module metadata
* The name of the module
* The slot of the module
* The hash of the module.xml file of the previous version of the module. Not present if the relevant module did not exist in the version being patched.
h5. Removed module metadata
Identifies modules that were available in the version being patched but which should no longer be accessible once the patch is applied
* The name of the removed module
* The slot of the removed module
h5. Bundle metadata
* TODO anything?
h5. Removed bundle metadata
Identifies bundles that were available in the version being patched but which should no longer be accessible once the patch is applied
* The name of the removed bundle
h5. Misc file metadata
* The path of the misc file, relative to the root of the AS distribution
* The hash of the version of the file that was in the version being patched. Not present if the relevant file did not exist in the version being patched, or if the relevant file is a directory.
* A boolean indicator as to whether the relevant file is a directory.
* A boolean indicator as to whether the file is in active use by a non-admin-mode Host Controller or server
h5. Removed misc file metadata
Identifies misc files that were available in the version being patched but which should no longer be accessible once the patch is applied
* The path of the misc file, relative to the root of the AS distribution
* The hash of the version of the file that was in the version being patched. Not present if the relevant file is a directory.
* A boolean indicator as to whether the relevant file is a directory.
* A boolean indicator as to whether the file is in active use by a non-admin-mode Host Controller or server
h2. Patch "Staging"
The target process when it applies a patch will create a patches directory directly underneath the root of the AS distribution. As with other directories, the location of this directory can be controlled via a system property passed to the JVM at process launch.
Before patch staging begins, a check is made as to whether the target process is in admin-only mode. If it is not, and an unresolvable conflict is detected between a module, bundle or miscellaneous file contained in the patch and a user-modification of the corresponding item in the installation being patched, the patch staging process will be aborted with an error message. See "Patch Conflict Detection" below.
h4. Modules
Patch modules will be staged by copying them to a patch-specific subdirectory of the patches directory. Information about the location of this directory will be stored in a location visible to the module loader used by JBoss Modules at boot. This patch-specific subdirectory is not visible to the module loader currently in use by the target process.
For modules that the patch "removes", the patch-specific subdirectory of the patches directory will include that module, but with a special module.xml file and no other contents. The module.xml file will include the tag <missing/>. The JBoss Modules release used with this will interpret that <missing/> tag and if seen will throw a ModuleNotFoundException (which is what it would throw if it were unable to locate a module. The nice thing about this approach is if a later patch adds back the removed module, that patch will take precedence in the module path, and the "missing" module.xml will be irrelevant.
h4. Bundles
Patch bundes will be staged by copying them to a patch-specific subdirectory of the patches directory. This patch-specific subdirectory is not visible to the OSGi subsystem currently in use by the target process.
Information about removed bundles will also be stored in a location visible to the OSGi subsystem at next boot. TODO see if an approach similar to the <missing/> approach can be used.
h4. Misc files
Misc files are staged by copying them directly to their normal location on the filesystem. A copy of the existing file at that location will be stored in the patch-specific subdirectory of the patches directory.
TODO describe check for user-modified misc files.
h4. Configuration files
Patches will not modify the configuration files of the target process. Configuration patching will not be supported in this version of the feature (and may never be supported.) Configuration files belong to the user. However, a copy of all existing configuration files will be made in a patch-specific subdirectory of the patches directory. During patch rollback, these configuration files will be restored. This backup is necessary because once the patch is applied to the runtime, any management operation that results in persistence of the configuration will use the xml schemas associated with the patched version of the core AS and any subsystems. If the patch is reverted, those schemas may not be intelligible to the version of the code to which the runtime has been reverted.
h2. Patch Application
A patch is "applied" by stopping the target process and then restarting it in a normal manner; e.g. from the command line or by using the :shutdown(restart=true) command from the CLI. The patch contents that have been staged are then used by the restarted process.
h4. Modules
In 7.2 the AS will use a custom implementation of the JBoss Modules ModuleLoader interface, instead of the default implementation used in previous AS 7 releases. The module loader works using a notion of a "module path", which is an ordered list of directories in which modules are located. When the module loader needs to find a module, it searches the directories in that path in order, and once it finds the desired module the search ends. Thus, directories earlier in the path listing take precedence over those found later. This is all very similar to how an OS uses the $PATH environment variable.
Previous AS7 releases allowed the user to specify a $JBOSS_MODULES_PATH environment variable to declare the "module path", with a default value of $JBOSS_HOME/modules used if not specified. The startup scripts used to the AS pass that module path into JBoss Modules (via the -mp <the_path> argument to java.) In AS 7.2, the custom module loader we will use will support this behavior, but in addition the custom module loader we provide will be able to examine the patching metadata that will be persisted in the "staging" phase and from that will determine which of the patch-specific subdirectories of the patches directory need to be prepended to the module path. In addition, for modules that have been removed in patches, the custom module loader will know to not load those modules, even though the modules will still remain on the filesystem.
h4. Bundles
Bundles get selected using a similar mechanism like the modules
h4. Misc Files
Application of miscellaneous files to the runtime is straightforward. The staging step places the patch's miscellaneous files in the normal location that the runtime services will expect, so when the target process is restarted, the runtime services see them.
h2. Patch rollback
Rolling back a patch works in a similar to the applying process. The target process has to be in --admin-only mode or completely shutdown. The backup copies of the miscellaneous files stored during the "Patch Staging" process will be restored to their normal locations. Any misc files that were added as part of the "Patch Staging" process (i.e. those that were new in the patch) will be removed. Modules and bundle overlay directories will get removed when the staging process is completed.
A patch rollback is "applied" by stopping the target process and then restarting it in a normal manner; e.g. from the command line or by using the :shutdown(restart=true) command from the CLI. The modules, bundles and miscellaneous files that have been staged are then used by the restarted process.
h4. Configuration (!)
The backup copies of the configuration files stored during the "Patch Staging" process will be restored. *+Any configuration changes made while the patch was in place will be lost.+*
h4. Modules
See the discussion in "Patch Application" above of how the module path works. When a patch is rolled back, the metadata the custom module loader uses to construct the module path will no longer indicate the patch's modules should be on the path, so they will not be available for loading.
h4. Bundles
Works similar to the way modules are handled.
h4. Misc Files
As was the case in the discussion in "Patch Application" above, the patch rollback staging step places the correct miscellaneous files in the normal location that the runtime services will expect, so when the target process is restarted, the runtime services see them.
h2. Patch Conflict Detection
At the beginning of the patch staging process, a check will be made for conflicts between the patch and any user modifications to the same item. The user when executing the patch command can provide information to guide the tool in resolving conflicts. Any conflicts that cannot be resolved will result in the patch staging being aborted with no changes to the filesystem. Conflict types are:
* Modules. If the patch is updating or removing an existing module, the patch.xml file will include the hash of the existing module's contents. The patching process will hash the current module's contents to check for modifications. If any affected module is found to have been modified, the patch command will have to have been provided with a parameter indicating that "overriding" modified modules is ok. No option will be given to optionally override some modules and leave others unmodified. If the user wishes to retain some modification they made to a module, they will need to make an equivalent change to the patch module. The sole purpose of this "module conflict detection" is to provide information to users.
* Bundles: If the patch is updating or removing an existing bundle, the patch.xml file will include the hash of the existing bundle's contents. The patching process will hash the current bundle's contents to check for modifications. If any affected bundle is found to have been modified, the patch command will have to have been provided with a parameter indicating that "overriding" modified bundles is ok. No option will be given to optionally override some bundles and leave others unmodified. If the user wishes to retain some modification they made to a bundle, they will need to make an equivalent change to the patch bundle. The sole purpose of this "bundle conflict detection" is to provide information to users.
* Misc files: If the patch is updating an existing misc file, the patch.xml file will include the hash of the existing file. If the patch is removing an existing directory, the patch.xml file will include the hash of the existing directory's contents. The patching process will hash the current file or directory to check for modifications. If any affected file/directory is found to have been modified, the patch command will have to have been provided with a permission indicating that "overriding" modified modules is ok. If no permission is available for a particular file or directory, the conflict will be treated as unresolved. These permissions can come in four forms:* A global permission to update all conflicting misc files, provided as a param to the CLI tool's patching command
* A global permission to not update any conflicting misc files, provided as a param to the CLI tool's patching command
* A file containing* a list of paths (relative to $JBOSS_HOME) for which update permission is granted.
* a list of paths (relative to $JBOSS_HOME) for which update permission is denied, meaning the existing file should be retained.
The patching feature will also include a command that can apply this conflict detection process and provide a report of conflicts. Users can use this command to check for conflicts in advance.
TODO describe how this will work for patch rollback.
h2. Patch Generation Tool
* Accepts basic metadata along with the location of a distribution of the new version along with a distribution of the old version* Also includes details on any misc files that are expected to be in active use
* Generates a patch.xml file
* Can generate a full patch file
* Optional: Can be run from inside the bin/ dir of the full distribution of the new version and if provided with the patch.xml file can generate a patch file from the contents of the full dist* Idea here is the patch.xml file could be distributed as part of the new version and the user could use it to generate patch
h4. (Layered) Directory structure
h4.
${JBOSS_HOME}
|-- bin
|-- bundles
| |-- system (system bundles contains only bundles, no patches metadata)
| | |-- layers
| | | |-- xyz
| | | | `-- patches (overlay directory)
| | | | |-- patch-xyz-1
| | | | `-- patch-xyz-2
| | | |-- vuw
| | | | `-- patches (overlay directory)
| | | | `-- patch-vuw-1
| | | `-- base
| | | |-- patches (overlay directory)
| | | | |-- patch-base-1
| | | | `-- patch-base-2
| | | `-- org/jboss/as/osgi
| | `-- add-ons
| | `-- def
| | `-- patches (overlay directory)
| | |-- patch-def-1
| | `-- patch-def-2
| |
| `-- my/own/bundle/path/thing
|
|-- docs
|-- modules
| |-- layers.conf (xyz,vuw)
| |-- system (system modules contains only modules, no patches metadata)
| | |-- layers
| | | |-- xyz
| | | | `-- patches (overlay directory)
| | | | |-- patch-xyz-1
| | | | `-- patch-xyz-2
| | | |-- vuw
| | | | `-- patches (overlay directory)
| | | | `-- patch-vuw-1
| | | ` -- base
| | | |-- patches (overlay directory)
| | | | |-- patch-base-1
| | | | `-- patch-base-2
| | | |-- org/jboss/as/...
| | | `-- org/jboss/as/server/main/module.xml
| | `-- add-ons
| | `-- def
| | `-- patches (overlay directory)
| | |-- patch-def-1
| | `-- patch-def-2
| |
| `-- my/own/module/root/repo
|
|-- .installation (metadata directory for the installation)
| |-- identity.conf (patched state for the installed identity)
| `-- patches (history of the patches applied to the identity)
| `-- patch-identity-1
| |-- patch.xml
| |-- rollback.xml
| |-- timestamp
| |-- configuration (configuration backup)
| `-- misc (misc backup)
| |-- layers (metadata for patched layers)
| | |-- base
| | | `-- layer.conf (patched state for the layer)
| | |-- xyz
| | | `-- layer.conf
| | |-- vuw
| | | `-- layer.conf
| `-- add-ons (metadata for patched add-ons)
| `-- def
| `-- layer.conf
`-- jboss-modules.jar
*For more information on layering: https://community.jboss.org/docs/DOC-47927 https://community.jboss.org/wiki/LayeredDistributionsAndModulePathOrganiz...
h3. Patching Deployments
There has been some confusion related to how the patching tool can be used to patch a deployment that comes as part of some set of functionality that gets added onto the base AS (e.g. by a layered product that builds on top of EAP 6.) This section will attempt to address some of that confusion.
See the https://community.jboss.org/docs/DOC-25627 Extending AS7 wiki page for basic information on different approaches to adding more functionality to the AS.
First, this patching tool is irrelevant when it comes to end user application deployments. Once the patching feature is available, end users should install an updated version of their application using the same mechanisms they've used for updating their application deployments in previous AS releases (CLI, deployment scanner, admin-console, JON.) The patching tool is not intended to replace or supplement these mechanisms.
Second, the patching tool +will be capable of patching deployment archives provided by some add-on that uses the underlying AS+. However, there is an important consideration that needs to be understood. *It must be possible to stage a patch by copying the patch contents onto the filesystem without having that updated content become immediately visible to a running server that is reading that filesystem*. The staged content should sit there having no affect on the running server until the user chooses to restart the server. If a deployment archive is installed into the server by placing it in the deployments/ folder (or any other folder periodically scanned by a deployment scanner), this requirement cannot be reliably met. The scanner will notice the new deployment as soon as it is staged and will deploy it. Similarly, if the deployment archive is exploded, even if it is not installed by a deployment scanner, if the server is using the original exploded directory as the source of the live deployment, the "staging requirement" cannot be met. When the patch tool updates a file in the exploded archive, it will immediately be visible to the runtime services (e.g. to the running deployment's classloader.)
How can AS add-ons install services while still supporting stageable patches? There are 4 approaches, two based on using modules, two that don't use modules
Using modules:
1. Create an AS Extension implementation. Package it in a module. Have the Extension implement install your runtime services. This is the preferred approach wherever practical.
2. Create an AS Extension implementation. Package it in a module. Include the deployment archive inside the module. Have the Extension implementation programatically deploy it when the subsystem starts. See "A Mixed Approach" on the https://community.jboss.org/docs/DOC-25627 Extending AS7 wiki page for an example extension that does this.
Both of these approaches have no problems with patch staging, because when a module is patched, the patch is not visible to the running server's module loader until the server is restarted.
If the deployment archive is not packaged inside a module, then it is a "Misc File" in terms of the previous discussion on this document. Therefore the rules for staging an update to a misc file described above apply. Given this, there are two mechanisms for making such a deployment "patchable":
1. Place the deployment in some location on the filesystem, but not in a directory scanned by a deployment-scanner. Create an AS Extension implementation. Package it in a module. Have the Extension implementation, when the subsystem is added, copy the deployment content into an internal location (i.e. the data/ dir) and then invoke management operations to deploy the content from that location. The portal team was investigating installing their ear (which must be exploded and end user-modifiable) in this manner. The original deployment can be patched because it's the copy of the deployment that is being used by the running server.
2. Accept that the deployment archive cannot be truly staged. Include in the patch.xml file metadata indicating that the file is in active use by a non-admin-mode Host Controller or server. When the patching tool goes to stage the patch, if it sees this metadata, it will check if the process is in admin-only mode. If it is not, it will refuse to install the patch until the process is placed in admin-only mode.
This last mechanism of not truly supporting patch staging is only intended to serve as a fallback scenario for cases where no alternative is available for patching a particular file. It was not intended to serve as a mechanism for patching deployments installed by layered products, for which the other three alternatives are available.
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-47500]
Create a new document in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
11 years, 7 months
