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@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/web/resources/src/main/java/org/exoplatform/web/application/javascript/JavascriptConfigDeployer.java#L72

Thanks,

Peter

_______________________________________________
gatein-dev mailing list
gatein-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev



--
Trong Tran
(+84) 983841909 | trongtt@gmail.com
Twitter: http://twitter.com/trongtt