Marcus A. Il y a 15 années If you do not use the plugin sdk and just develop the plugin as a web app which ends with one of the plugin type names e.g. hook liferay will not be able to deploy the plugin.If the war file ends with a different name it just deployes as expected. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Ray Augé Marcus A. Il y a 15 années This might be the case if you don't use the build files that are provided by the SDK.I should have clarified "if you created your project from scratch" with "but still using the liferay build scripts". I this case, you will produce a WAR which might be like project-name-5.1.3.7.war and so it'll be deployed as /project-name-5.1.3.7 which is often not expected. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Ray Augé Marcus A. Il y a 15 années This might be the case if you don't use the build files that are provided by the SDK.I should have clarified "if you created your project from scratch" with "but still using the liferay build scripts". I this case, you will produce a WAR which might be like project-name-5.1.3.7.war and so it'll be deployed as /project-name-5.1.3.7 which is often not expected. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Jim Klo Il y a 15 années Recently, using my own patched version of 5.1.1 to fix hook plugins, I built a single 'theme' based plugin, that incorporated the functionality provided by a hook, layout, portlet, and theme. While my plugin worked fine, how does this naming convention apply to what I'd consider a mixed mode plugin? Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Ray Augé Jim Klo Il y a 15 années This is a special case. Any plugin should be able to contain components of other plugin types. This is why I think we should ultimately drop the naming convention and go with pure descriptor configuration. The naming I find is just a source of error and confusion. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Ray Augé Jim Klo Il y a 15 années This is a special case. Any plugin should be able to contain components of other plugin types. This is why I think we should ultimately drop the naming convention and go with pure descriptor configuration. The naming I find is just a source of error and confusion. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Jens Volgmann Il y a 15 années Thanks for all these hints. I didnot know these conventions. So i had a problem deploying a plugin package that doesn't match this conventions. They aren't documented outside of this blod, are they?I found an other way to deploy a plugin package with a custom name (Liferay 5.2.2): the liferay-plugin-package.xml. In this file you have to define the module id like <groupid>/<artifactid>/<plugin version>/<type></module-id>. The artifactid is used for deployment context. I know that this is a workaround. So we use the properties file to configure the required libraries and we use the xml file to configure deployment context. Actually you can configure the recommended-deployment-context in the xml, too (see liferay-plugin-package_5_2_0.dtd).Perhaps you can explain the differences between these two files needed for compilation and deployment? Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Mickey Fox Jens Volgmann Il y a 14 années Dude [Shakeeb] you are absolutely without a clue that you felt this was the proper forum to SPAM-vertise here. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Ray Augé Mickey Fox Il y a 14 années Thanks Mickey (deleted the previous commentisment), I was super busy when this comment came in and didn't check it. Thanks for commenting otherwise it might have stayed up indefinitely. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Mickey Fox Jens Volgmann Il y a 14 années Dude [Shakeeb] you are absolutely without a clue that you felt this was the proper forum to SPAM-vertise here. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Ray Augé Mickey Fox Il y a 14 années Thanks Mickey (deleted the previous commentisment), I was super busy when this comment came in and didn't check it. Thanks for commenting otherwise it might have stayed up indefinitely. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Ray Augé Mickey Fox Il y a 14 années Thanks Mickey (deleted the previous commentisment), I was super busy when this comment came in and didn't check it. Thanks for commenting otherwise it might have stayed up indefinitely. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
pascale bizet Il y a 13 années Hi Ray,Thank you for this interesting blog.Do you know if it is possible to specify a context path for plugins using the recommended-deployment-context that will use a name such as "/portal_root_context/plugin1". I did a try using tomcat but then plugins are not working properly.Our customer have a requirement to use a unified context root for their portal where all links (portal and plugins, theme )have to start with the same /portal_root_context.I Investigated also the <virtual-path> element but does not work either.I wonder if this is possible to achieve with Liferay ?Any input on this ? ThanksOur Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Ray Augé pascale bizet Il y a 13 années - Edité Bonjour Pascale,I tested with the following property:recommended-deployment-context=portal/service-builder-portlet(note that I omitted the starting slash) and this worked fine with one major issue; Tomcat did not itself deploy the application.Liferay's deployer work perfectly, processed the plugin and exploded it to the correct path. The problem seems to be that the app server must support the subcontexts. Tomcat is supposed to have support for this, but it requires that you manually create a context file something like:conf/Catalina/[hostname]/portal#service-builder-portlet.xml (where the # will be replaced with path separator)I tried this quickly and still tomcat would not initialize the webapp. I stopped there as I didn't not have time to do more.This type of deployment might work for other app servers (although they may have quirks to get it working as well).The bottom line is that the app servers must support it. If they support it, then it seems that at least from first glance Liferay has no problem doing it as well. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler pascale bizet Ray Augé Il y a 13 années Thank you for your response. I obtained the same problem as you.Tomcat seems to support sub context, it works for regular web app. It seems to use "#" to separate context level. As long as you name your web app level1#level2, your web app can be accessed using url /level1/level2For liferay, I tried the following :recommended-deployment-context=portal#service-builder-portletThe plugins deployment is then done properly. All seems ok. However, the plugins does not work anymore and even broke the database (we are not able to remove the portlet anymore, instead liferay renders a blank page).Do you think this is a deployment compatibility problem between tomcat using "#" caracter for multi level context and Liferay ?Thanks Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Ray Augé Ray Augé Il y a 13 années FYI: I just confirmed that there is a bug in tomcat 6.0.29 which causes the deployment of web apps using their own context file naming convention to fail.i.e. when a war is deployed to a subcontext, for example:/portal/service-builder-portletand having a context file:conf/Catalina/[host]/portal#service-builder-portlet.xml (this file contains only <Context />)The deployment fails. I also tried many variations of docBase and path with no success. While debugging the code, I replace the runtime value returned from:org.apache.catalina.core.StandardContext.getBasePath() from an incorrect value (which still includes the #) with a correct one, and the deployment worked perfectly. The plugin was completely usable. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Ray Augé Ray Augé Il y a 13 années Strange that it works for a normal app. We're not doing anything abnormal with our wars. Could you try to identify what is different between our deployments and a regular war (I mean with respect to tomcat)? Veuillez vous identifier pour voter. Répondre en tant que ... Annuler pascale bizet Ray Augé Il y a 13 années Actually, the deployment is successfull with Liferay and tomcat (version6.0.18) as long as the recommended-deployment-context include "#". The problem then is that (I guess) , Liferay is using the context path as portlet reference internally and . The "#" seems to mess up everything.Another issue for us : do you know if that is possible to modify the plugin context path but keep the internal plugin reference as before. The idea here is to be able to modify the plugin context path without having to reconfigure each portlet instance on the portal ( for a portal running on production already with possible portal user customization). Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Diego Paton pascale bizet Il y a 13 années Hi,I have the same problemDid you solve it?Thanks in advance.Diego. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Ray Augé pascale bizet Il y a 13 années - Edité Bonjour Pascale,I tested with the following property:recommended-deployment-context=portal/service-builder-portlet(note that I omitted the starting slash) and this worked fine with one major issue; Tomcat did not itself deploy the application.Liferay's deployer work perfectly, processed the plugin and exploded it to the correct path. The problem seems to be that the app server must support the subcontexts. Tomcat is supposed to have support for this, but it requires that you manually create a context file something like:conf/Catalina/[hostname]/portal#service-builder-portlet.xml (where the # will be replaced with path separator)I tried this quickly and still tomcat would not initialize the webapp. I stopped there as I didn't not have time to do more.This type of deployment might work for other app servers (although they may have quirks to get it working as well).The bottom line is that the app servers must support it. If they support it, then it seems that at least from first glance Liferay has no problem doing it as well. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler pascale bizet Ray Augé Il y a 13 années Thank you for your response. I obtained the same problem as you.Tomcat seems to support sub context, it works for regular web app. It seems to use "#" to separate context level. As long as you name your web app level1#level2, your web app can be accessed using url /level1/level2For liferay, I tried the following :recommended-deployment-context=portal#service-builder-portletThe plugins deployment is then done properly. All seems ok. However, the plugins does not work anymore and even broke the database (we are not able to remove the portlet anymore, instead liferay renders a blank page).Do you think this is a deployment compatibility problem between tomcat using "#" caracter for multi level context and Liferay ?Thanks Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Ray Augé Ray Augé Il y a 13 années FYI: I just confirmed that there is a bug in tomcat 6.0.29 which causes the deployment of web apps using their own context file naming convention to fail.i.e. when a war is deployed to a subcontext, for example:/portal/service-builder-portletand having a context file:conf/Catalina/[host]/portal#service-builder-portlet.xml (this file contains only <Context />)The deployment fails. I also tried many variations of docBase and path with no success. While debugging the code, I replace the runtime value returned from:org.apache.catalina.core.StandardContext.getBasePath() from an incorrect value (which still includes the #) with a correct one, and the deployment worked perfectly. The plugin was completely usable. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Ray Augé Ray Augé Il y a 13 années Strange that it works for a normal app. We're not doing anything abnormal with our wars. Could you try to identify what is different between our deployments and a regular war (I mean with respect to tomcat)? Veuillez vous identifier pour voter. Répondre en tant que ... Annuler pascale bizet Ray Augé Il y a 13 années Actually, the deployment is successfull with Liferay and tomcat (version6.0.18) as long as the recommended-deployment-context include "#". The problem then is that (I guess) , Liferay is using the context path as portlet reference internally and . The "#" seems to mess up everything.Another issue for us : do you know if that is possible to modify the plugin context path but keep the internal plugin reference as before. The idea here is to be able to modify the plugin context path without having to reconfigure each portlet instance on the portal ( for a portal running on production already with possible portal user customization). Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Diego Paton pascale bizet Il y a 13 années Hi,I have the same problemDid you solve it?Thanks in advance.Diego. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
pascale bizet Ray Augé Il y a 13 années Thank you for your response. I obtained the same problem as you.Tomcat seems to support sub context, it works for regular web app. It seems to use "#" to separate context level. As long as you name your web app level1#level2, your web app can be accessed using url /level1/level2For liferay, I tried the following :recommended-deployment-context=portal#service-builder-portletThe plugins deployment is then done properly. All seems ok. However, the plugins does not work anymore and even broke the database (we are not able to remove the portlet anymore, instead liferay renders a blank page).Do you think this is a deployment compatibility problem between tomcat using "#" caracter for multi level context and Liferay ?Thanks Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Ray Augé Ray Augé Il y a 13 années FYI: I just confirmed that there is a bug in tomcat 6.0.29 which causes the deployment of web apps using their own context file naming convention to fail.i.e. when a war is deployed to a subcontext, for example:/portal/service-builder-portletand having a context file:conf/Catalina/[host]/portal#service-builder-portlet.xml (this file contains only <Context />)The deployment fails. I also tried many variations of docBase and path with no success. While debugging the code, I replace the runtime value returned from:org.apache.catalina.core.StandardContext.getBasePath() from an incorrect value (which still includes the #) with a correct one, and the deployment worked perfectly. The plugin was completely usable. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Ray Augé Ray Augé Il y a 13 années Strange that it works for a normal app. We're not doing anything abnormal with our wars. Could you try to identify what is different between our deployments and a regular war (I mean with respect to tomcat)? Veuillez vous identifier pour voter. Répondre en tant que ... Annuler pascale bizet Ray Augé Il y a 13 années Actually, the deployment is successfull with Liferay and tomcat (version6.0.18) as long as the recommended-deployment-context include "#". The problem then is that (I guess) , Liferay is using the context path as portlet reference internally and . The "#" seems to mess up everything.Another issue for us : do you know if that is possible to modify the plugin context path but keep the internal plugin reference as before. The idea here is to be able to modify the plugin context path without having to reconfigure each portlet instance on the portal ( for a portal running on production already with possible portal user customization). Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Diego Paton pascale bizet Il y a 13 années Hi,I have the same problemDid you solve it?Thanks in advance.Diego. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Ray Augé Ray Augé Il y a 13 années Strange that it works for a normal app. We're not doing anything abnormal with our wars. Could you try to identify what is different between our deployments and a regular war (I mean with respect to tomcat)? Veuillez vous identifier pour voter. Répondre en tant que ... Annuler pascale bizet Ray Augé Il y a 13 années Actually, the deployment is successfull with Liferay and tomcat (version6.0.18) as long as the recommended-deployment-context include "#". The problem then is that (I guess) , Liferay is using the context path as portlet reference internally and . The "#" seems to mess up everything.Another issue for us : do you know if that is possible to modify the plugin context path but keep the internal plugin reference as before. The idea here is to be able to modify the plugin context path without having to reconfigure each portlet instance on the portal ( for a portal running on production already with possible portal user customization). Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Diego Paton pascale bizet Il y a 13 années Hi,I have the same problemDid you solve it?Thanks in advance.Diego. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
pascale bizet Ray Augé Il y a 13 années Actually, the deployment is successfull with Liferay and tomcat (version6.0.18) as long as the recommended-deployment-context include "#". The problem then is that (I guess) , Liferay is using the context path as portlet reference internally and . The "#" seems to mess up everything.Another issue for us : do you know if that is possible to modify the plugin context path but keep the internal plugin reference as before. The idea here is to be able to modify the plugin context path without having to reconfigure each portlet instance on the portal ( for a portal running on production already with possible portal user customization). Veuillez vous identifier pour voter. Répondre en tant que ... Annuler Diego Paton pascale bizet Il y a 13 années Hi,I have the same problemDid you solve it?Thanks in advance.Diego. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler
Diego Paton pascale bizet Il y a 13 années Hi,I have the same problemDid you solve it?Thanks in advance.Diego. Veuillez vous identifier pour voter. Répondre en tant que ... Annuler