{"id":6925,"date":"2014-04-22T05:55:18","date_gmt":"2014-04-22T12:55:18","guid":{"rendered":"http:\/\/localhost\/exoblog\/?p=6925"},"modified":"2014-04-22T05:55:18","modified_gmt":"2014-04-22T12:55:18","slug":"master-portlet-packaging-jboss","status":"publish","type":"post","link":"https:\/\/www.exoplatform.com\/blog\/master-portlet-packaging-jboss\/","title":{"rendered":"Master Your Portlet Packaging in JBoss"},"content":{"rendered":"<p>eXo Platform 4.0 has a Tomcat 7 version and a JBoss EAP 6.1 version. In the JBoss version, eXo is packaged as a unique (exploded) EAR containing all the JARs and all the WARs. To install your portlets, the default procedure is to install your WARs and your JARs inside the eXo EAR. This can be done manually (copy the WARs into <span class=\"navCode\">platform.ear<\/span>, copy the JARs into <span class=\"navCode\">platform.ear\/lib<\/span>, then update the <span class=\"navCode\">application.xml<\/span>) or with the <a href=\"https:\/\/www.exoplatform.com\/blog\/2013\/12\/20\/boost-platform-new-add-ons-manage\" target=\"_blank\" rel=\"noopener\">extension manager<\/a>.<\/p>\n<p>This method has the benefit of being really easy, especially with the extension manager, but it also has some drawbacks:<\/p>\n<ul>\n<li>eXo artifacts and custom portlets artifacts are not well separated<\/li>\n<li>portlets cannot be hot deployed<\/li>\n<li>it can lead to class-path issues if your portlet needs a different version of a JAR already present in eXo<\/li>\n<\/ul>\n<p>Hopefully, there are solutions to avoid all these drawbacks. With JBoss AS 7 (JBoss EAP 6), a new class-path system has been introduced: JBoss Modules. Its goal is to get rid of the classic monolithic class-loader system and replace it by a more modular one. In this system, each library is a module that is linked to other modules that it depends on. So every library has its own made-to-measure class loader, which avoids many of the class-loader issues.<\/p>\n<p>Thanks to this system, one EAR\/WAR can depend on a second EAR\/WAR, for example, and this makes all the classes of the second EAR\/WAR available to the first. This is used to package portlets in separate WARs or EARs.<\/p>\n<p><!--more--><\/p>\n<p><a href=\"https:\/\/www.exoplatform.com\/blog\/wp-content\/uploads\/2014\/04\/01-packaging.jpg\"><img decoding=\"async\" class=\"aligncenter size-medium wp-image-6928\" src=\"https:\/\/www.exoplatform.com\/blog\/wp-content\/uploads\/2014\/04\/01-packaging.jpg\" alt=\"01-packaging\" width=\"200\" srcset=\"https:\/\/www.exoplatform.com\/blog\/wp-content\/uploads\/2014\/04\/01-packaging.jpg 277w, https:\/\/www.exoplatform.com\/blog\/wp-content\/uploads\/2014\/04\/01-packaging-218x236.jpg 218w, https:\/\/www.exoplatform.com\/blog\/wp-content\/uploads\/2014\/04\/01-packaging-121x131.jpg 121w, https:\/\/www.exoplatform.com\/blog\/wp-content\/uploads\/2014\/04\/01-packaging-83x90.jpg 83w, https:\/\/www.exoplatform.com\/blog\/wp-content\/uploads\/2014\/04\/01-packaging-28x30.jpg 28w\" sizes=\"(max-width: 277px) 100vw, 277px\" \/><\/a><\/p>\n<h2>Portlet in a WAR or EAR alongside platform.ear<\/h2>\n<p>To make a portlet hot deployable, it needs to be packaged in a separate artifact other than the eXo EAR (platform.ear). This can be done in a WAR or EAR, which will be deployed alongside the eXo EAR (in the deployments folder).<\/p>\n<p>Building an EAR containing a portlet is really simple, thanks to the <a href=\"http:\/\/maven.apache.org\/plugins\/maven-ear-plugin\/\" target=\"_blank\" rel=\"noopener\">Maven EAR plugin<\/a>. There are many examples available (<a href=\"https:\/\/github.com\/exo-addons\/pagesjaunes-extension\/blob\/master\/ear\/pom.xml\" target=\"_blank\" rel=\"noopener\">here<\/a> or <a href=\"https:\/\/github.com\/exo-addons\/pagesjaunes-extension\/blob\/master\/ear\/pom.xml\" target=\"_blank\" rel=\"noopener\">here<\/a>). The file only contains the WAR of the portlet (and the application.xml file, of course, which declares the WAR). But simply deploying this EAR in the deployments folder, alongside the eXo EAR, is not sufficient, since the portlet needs libraries present in the eXo EAR and because the class paths of EARs are isolated by default. This is where we use JBoss Modules. As we said before, each EAR is a JBoss module. So all that is required is to make the portlet EAR depend on the eXo EAR.<\/p>\n<p><a href=\"https:\/\/www.exoplatform.com\/blog\/wp-content\/uploads\/2014\/04\/02-jboss-module.png\"><img decoding=\"async\" class=\"aligncenter size-medium wp-image-6927\" src=\"https:\/\/www.exoplatform.com\/blog\/wp-content\/uploads\/2014\/04\/02-jboss-module.png\" alt=\"02-jboss-module\" width=\"650\" srcset=\"https:\/\/www.exoplatform.com\/blog\/wp-content\/uploads\/2014\/04\/02-jboss-module.png 843w, https:\/\/www.exoplatform.com\/blog\/wp-content\/uploads\/2014\/04\/02-jboss-module-300x139.png 300w, https:\/\/www.exoplatform.com\/blog\/wp-content\/uploads\/2014\/04\/02-jboss-module-768x356.png 768w, https:\/\/www.exoplatform.com\/blog\/wp-content\/uploads\/2014\/04\/02-jboss-module-720x334.png 720w, https:\/\/www.exoplatform.com\/blog\/wp-content\/uploads\/2014\/04\/02-jboss-module-500x232.png 500w, https:\/\/www.exoplatform.com\/blog\/wp-content\/uploads\/2014\/04\/02-jboss-module-360x167.png 360w, https:\/\/www.exoplatform.com\/blog\/wp-content\/uploads\/2014\/04\/02-jboss-module-200x93.png 200w, https:\/\/www.exoplatform.com\/blog\/wp-content\/uploads\/2014\/04\/02-jboss-module-100x46.png 100w, https:\/\/www.exoplatform.com\/blog\/wp-content\/uploads\/2014\/04\/02-jboss-module-65x30.png 65w\" sizes=\"(max-width: 843px) 100vw, 843px\" \/><\/a><\/p>\n<p>JBoss provides two ways for declaring dependencies in an artifact: in <span class=\"navCode\">META-INF\/MANIFEST.MF<\/span> or in <span class=\"navCode\">META-INF\/jboss-deployment-structure.xml<\/span>. Both ways are equivalent.<\/p>\n<p>The syntax for <span class=\"navCode\">MANIFEST.MF<\/span> is:<\/p>\n<pre class=\"lang:default decode:true \">Dependencies: deployment.platform.ear\n<\/pre>\n<p>Note: deployment.platform.ear is the JBoss module name of the eXo EAR. Every artifact deployed in JBoss is a module and can be referenced with <span class=\"navCode\">namedeployment.&lt;artifact-name&gt;<\/span><\/p>\n<p>The syntax for <span class=\"navCode\">jboss-deployment-structure.xml<\/span> is:<\/p>\n<pre class=\"lang:default decode:true \">&lt;jboss-deployment-structure xmlns=\"urn:jboss:deployment-structure:1.2\"&gt;\n\t&lt;deployment&gt;\n\t\t&lt;dependencies&gt;\n\t\t\t&lt;module name=\"deployment.platform.ear\"\/&gt;\n\t\t&lt;\/dependencies&gt;\n\t&lt;\/deployment&gt;\n&lt;\/jboss-deployment-structure&gt;<\/pre>\n<p>Once one of these files has been added into the EAR, the portlet can be deployed (and hot deployed) successfully.<\/p>\n<p>If the portlet project is a Maven project, the <span class=\"navCode\">MANIFEST.MF<\/span> file can be generated automatically with the following lines in your <span class=\"navCode\">pom.xml<\/span>:<\/p>\n<pre class=\"lang:default decode:true \">&lt;build&gt;\n\t&lt;plugins&gt;\n\t\t&lt;plugin&gt;\n\t\t\t&lt;groupId&gt;org.apache.maven.plugins&lt;\/groupId&gt;\n\t\t\t&lt;artifactId&gt;maven-war-plugin&lt;\/artifactId&gt;\n\t\t\t&lt;configuration&gt;\n\t\t\t\t&lt;archive&gt;\n\t\t\t\t\t&lt;manifestEntries&gt;\n\t\t\t\t\t\t&lt;Dependencies&gt;deployment.platform.ear&lt;\/Dependencies&gt;\n\t\t\t\t\t&lt;\/manifestEntries&gt;  \n\t\t\t\t&lt;\/archive&gt;\n\t\t\t&lt;\/configuration&gt;\n\t\t&lt;\/plugin&gt;\n\t&lt;\/plugins&gt;\n&lt;\/build&gt;<\/pre>\n<h2>Portlet in a WAR or an EAR, alongside platform.ear, but where JARs conflicts with eXo<\/h2>\n<p>Now that our portlet is in its own EAR and can be hot deployed, let&#8217;s deal with a more tricky case.<\/p>\n<p>eXo comes with a bunch of third-party libraries. Thanks to the dependency on deployment.platform.ear, the portlet sees all of them. This can be useful, as they can be used without being embedded in the portlet EAR, but it can also be an issue if the portlet needs to use a different version of a library. For example, let&#8217;s say I want to create a Groovy portlet and use the latest Groovy version to benefit from its new features. eXo comes with version 1.7.6 and I want to use a feature available from version 2: the new String methods &#8220;takeWhile&#8221; and &#8220;dropWhile&#8221;.<\/p>\n<p>If the Groovy 2 JAR is simply added into the libraries of the WAR (<span class=\"navCode\">WEB-INF\/lib<\/span>) or the EAR (<span class=\"navCode\">EAR\/lib<\/span>), then since eXo EAR is set as a dependency, JBoss gives priority to it, so it will use the version embedded in eXo. So if the portlet is deployed with this structure, this error will show up:<\/p>\n<pre class=\"lang:default decode:true \">17:39:08,267 ERROR [portal:UIPortletLifecycle] (http-\/127.0.0.1:8080-1) Error processing the action: No signature of method: java.lang.String.dropWhile() is applicable for argument types: (org.exoplatform.portlet.groovy.GroovyPortlet$_processAction_closure1) values: [org.exoplatform.portlet.groovy.GroovyPortlet$_processAction_closure1@3417595d]: groovy.lang.MissingMethodException: No signature of method: java.lang.String.dropWhile() is applicable for argument types: (org.exoplatform.portlet.groovy.GroovyPortlet$_processAction_closure1) values: [org.exoplatform.portlet.groovy.GroovyPortlet$_processAction_closure1@3417595d]\n<\/pre>\n<p>The Groovy JAR of the portlet must have priority. The first thing to do is to make a JBoss module of this JAR (remember that a JAR deployed in <span class=\"navCode\">WEB-INF\/lib<\/span> of a WAR or in the lib folder of an EAR is not considered as a standalone JBoss module). To do this, the JAR can be set as an EAR Java module (which will turn it automatically into a JBoss module) or declared as a server JBoss module.<\/p>\n<p><a href=\"https:\/\/www.exoplatform.com\/blog\/wp-content\/uploads\/2014\/04\/03-jboss-module.png\"><img decoding=\"async\" class=\"aligncenter size-full wp-image-6926\" src=\"https:\/\/www.exoplatform.com\/blog\/wp-content\/uploads\/2014\/04\/03-jboss-module.png\" alt=\"03-jboss-module\" width=\"650\" srcset=\"https:\/\/www.exoplatform.com\/blog\/wp-content\/uploads\/2014\/04\/03-jboss-module.png 1026w, https:\/\/www.exoplatform.com\/blog\/wp-content\/uploads\/2014\/04\/03-jboss-module-300x155.png 300w, https:\/\/www.exoplatform.com\/blog\/wp-content\/uploads\/2014\/04\/03-jboss-module-1024x530.png 1024w, https:\/\/www.exoplatform.com\/blog\/wp-content\/uploads\/2014\/04\/03-jboss-module-768x397.png 768w, https:\/\/www.exoplatform.com\/blog\/wp-content\/uploads\/2014\/04\/03-jboss-module-720x373.png 720w, https:\/\/www.exoplatform.com\/blog\/wp-content\/uploads\/2014\/04\/03-jboss-module-500x259.png 500w, https:\/\/www.exoplatform.com\/blog\/wp-content\/uploads\/2014\/04\/03-jboss-module-360x186.png 360w, https:\/\/www.exoplatform.com\/blog\/wp-content\/uploads\/2014\/04\/03-jboss-module-200x104.png 200w, https:\/\/www.exoplatform.com\/blog\/wp-content\/uploads\/2014\/04\/03-jboss-module-100x52.png 100w, https:\/\/www.exoplatform.com\/blog\/wp-content\/uploads\/2014\/04\/03-jboss-module-58x30.png 58w\" sizes=\"(max-width: 1026px) 100vw, 1026px\" \/><\/a><\/p>\n<p>A Java module can be declared in an EAR with the following XML snippet in the <span class=\"navCode\">META-INF\/application.xml<\/span> file of the EAR:<\/p>\n<pre class=\"lang:default decode:true \">&lt;module&gt;\n    &lt;java&gt;groovy-all-2.2.1.jar&lt;\/java&gt;\n&lt;\/module&gt;<\/pre>\n<p>Here, the Groovy JAR, located at the root of the EAR, is available to all the artifacts of the EAR, and is automatically registered as a JBoss module with the name <span class=\"navCode\">deployment.ear.groovy-all-2.2.1.jar<\/span>.<\/p>\n<p>So it can be now set as a dependency in the MANIFEST.MF of the EAR, in order to give it a higher priority than the eXo EAR:<\/p>\n<pre class=\"lang:default decode:true \">Dependencies: deployment.&lt;name-of-the-ear&gt;.ear.groovy-all-2.2.1.jar, deployment.platform.ear\n<\/pre>\n<p>The order of the names in the Dependencies field is important. It is from the highest to the lowest priority. With this method, EAR artifacts will first look in the <span class=\"navCode\">groovy-all-2.2.1.jar<\/span> before looking in the eXo EAR libs. So the portlet will use version 2.2.1 of the Groovy library and will run successfully, while eXo will still use its own embedded Groovy version.<\/p>\n<h2>Conclusion<\/h2>\n<p>The new JBoss Modules class-path system is very powerful and is used to package portlets as needed. Hot redeployment, resolution of library conflicts and well-separated artifacts are now possible. And JBoss Modules has many more options for resolving tricky cases (but be careful not to fall into the JBoss Modules class-path hell ;-))!<\/p>\n<p>Enjoy!<\/p>\n","protected":false},"excerpt":{"rendered":"eXo Platform 4.0 has a Tomcat 7 version and a JBoss EAP 6.1 version. In the JBoss version, eXo is packaged as a unique (exploded) EAR containing all the JARs and all the WARs. To install your portlets, the default procedure is to install your WARs and your JARs inside the eXo EAR. This can [&hellip;]","protected":false},"author":7,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[699],"tags":[],"lang":"en","translations":{"en":6925},"pll_sync_post":[],"_links":{"self":[{"href":"https:\/\/www.exoplatform.com\/blog\/wp-json\/wp\/v2\/posts\/6925"}],"collection":[{"href":"https:\/\/www.exoplatform.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.exoplatform.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.exoplatform.com\/blog\/wp-json\/wp\/v2\/users\/7"}],"replies":[{"embeddable":true,"href":"https:\/\/www.exoplatform.com\/blog\/wp-json\/wp\/v2\/comments?post=6925"}],"version-history":[{"count":0,"href":"https:\/\/www.exoplatform.com\/blog\/wp-json\/wp\/v2\/posts\/6925\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.exoplatform.com\/blog\/wp-json\/wp\/v2\/media?parent=6925"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.exoplatform.com\/blog\/wp-json\/wp\/v2\/categories?post=6925"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.exoplatform.com\/blog\/wp-json\/wp\/v2\/tags?post=6925"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}