Hi Peter, I have got following test failures when applying your PR. However, it looks OK in general ========== /Failed tests: testCompositeSkin(org.exoplatform.portal.resource.TestSkinServiceInDevelopingMode): expected:<@import url(/portal[/skins/PORTAL-VERSION/mockwebapp/skin/FirstPortlet-lt.css);(..) testProcessImportCSS(org.exoplatform.portal.resource.TestSkinServiceInDevelopingMode): expected:<@import url(/portal[/skins/PORTAL-VERSION/process/import/Portlet/Stylesheet-lt.css]); aaa;> but was:<@import url(/portal[]); aaa;>/ ========== For the prevention of an app deployment, I don't see yet any way to do that. The PortalContainerPostInitTask is executed during PortalContainer starting, after the application is deployed. On 27 May 2014 15:22, Peter Palaga <ppalaga(a)redhat.com <mailto:ppalaga@redhat.com>> wrote: Hi *, could you please have a look at this pull request (the last two commits)? https://github.com/gatein/gatein-portal/pull/863 A quickstart using the new feature can be found in this branch: https://github.com/ppalaga/arcgis-gears-portlet/tree/GTNPORTAL-3485 We would like to include this in a milestone that we need to tag by Thursday, 2014-05-29 EoD. So, please comment before that date if possible. Esp. your comments are welcome on this topic: Within JBoss Portal team, we have been discussing what should happen, if an application wants to add a path mapping that is available in the portal already. Example: * An application app.war wants to register the AMD module ID prefix "dojo" to be mapped to "http://fastcdn.com/dojo/1.7.0". * But the prefix "dojo" was registered already for "http://othercdn.com/dojo/1.9.1" by some other application. * What should the portal do upon a deployment of app.war? In the present proposal, the solution is (A) to warn and ignore such prefixes in new deployments. The problem with (A) is clearly that although app.war requires dojo 1.7.0, it may get something wholly different and there is no guarantee that the app will work with a path mapping that it has not provided itself. After some discussion, we came to a conclusion, that (B) rejecting the whole deployment would be a cleaner solution. I was not able to find a way how I could cause the whole deployment to fail cleanly from the context of PortalContainerPostInitTask.execute() [1]. There are no checked exceptions defined for PortalContainerPostInitTask.execute(). I have not tried to throw a RuntimeException, but I do not believe that would cleanly reject the whole deployment. Any ideas how to reach (B)? [1] https://github.com/ppalaga/gatein-portal/blob/GTNPORTAL-3485.1/component/... Thanks, Peter _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org <mailto:gatein-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/gatein-dev -- *Trong Tran* /(+84) 983841909 | /trongtt(a)gmail.com <mailto:trongtt@gmail.com> Twitter: http://twitter.com/trongtt//