That's interesting, Donal. I see that the scripts in 
target/cloud-client-ui-4.3.0-SNAPSHOT do NOT have +x as you alluded to, however 
this has never been an issue for me.

However, the scripts aren't really the issue I'm having. When the jetty target 
was changed to generated-webapp, the lib/ folder isn't copied/generated as it 
is in cloud-client-ui-4.3.0-SNAPSHOT.

Is there a reason you made this change in addition to the permissions fix?

               <maxIdleTime>60000</maxIdleTime>
             </connector>
           </connectors>
-          
<webXml>${project.build.directory}/${project.build.finalName}/WEB-INF/web.xml</webXml>
-          
<webAppSourceDirectory>${project.build.directory}/${project.build.finalName}</webAppSourceDirectory>
+          
<webXml>${project.build.directory}/generated-webapp/WEB-INF/web.xml</webXml>
+          
<webAppSourceDirectory>${project.build.directory}/generated-webapp</webAppSourceDirectory>
           <webAppConfig>
             <contextPath>/client</contextPath>
             
<extraClasspath>${project.build.directory}/utilities/scripts/db/;${project.build.directory}/utilities/scripts/db/db/</extraClasspath>

As a workaround to the lib/ directory not being in generated-webapp, I've added 
the following to client/pom.xml (locally):

@@ -393,6 +393,11 @@
                     <include name="resources/**/*" />
                   </fileset>
                 </copy>
+                <copy todir="${basedir}/target/generated-webapp/WEB-INF/lib">
+                  <fileset 
dir="${basedir}/target/${project.build.finalName}/WEB-INF/lib/">
+                    <include name="*.jar"/>
+                  </fileset>
+                </copy>
                 <copy todir="${basedir}/target/generated-webapp">
                   <fileset dir="${basedir}/../ui" />
                 </copy>

On Aug 16, 2013, at 5:46 AM, Hugo Trippaers 
<trip...@gmail.com<mailto:trip...@gmail.com>> wrote:

Heya,

An easier solution could be to explicitly start the scripts with /bin/sh. No 
need to set executable bits anymore, this makes a lot of stuff easier when 
handling scripts.

Cheers,

Hugo

Sent from my iPhone

On 16 aug. 2013, at 01:12, Donal Lafferty 
<donal.laffe...@citrix.com<mailto:donal.laffe...@citrix.com>> wrote:

Hi Christopher,

Could you take a quick look at the permissions on scripts in the ./client 
folder?

I raised https://issues.apache.org/jira/browse/CLOUDSTACK-3650, because the 
Maven project that launched Jetty does not set execution permissions for 
scripts in  
<webAppSourceDirectory>${project.build.directory}/${project.build.finalName}</webAppSourceDirectory>
  E.g.

root@mgmtserver:~/github/cshv3/client# ls -al 
./target/cloud-client-ui-4.2.0-SNAPSHOT/WEB-INF/classes/scripts/vm/hypervisor/versions.sh
-rw-r--r-- 1 root root 1636 Aug 14 15:42 
./target/cloud-client-ui-4.2.0-SNAPSHOT/WEB-INF/classes/scripts/vm/hypervisor/versions.sh

versus

root@mgmtserver:~/github/cshv3/client# ls -al 
./target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/versions.sh
-rwxr-xr-x 1 root 1636 Aug 14 15:42 
./target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/versions.sh


I'm confused as to how other systems were able to run scripts.  I can't get 
them to run to run on Debian 7.

root@mgmtserver:~/github/cshv3/client# 
./target/cloud-client-ui-4.2.0-SNAPSHOT/WEB-INF/classes/scripts/vm/hypervisor/versions.sh
-bash: 
./target/cloud-client-ui-4.2.0-SNAPSHOT/WEB-INF/classes/scripts/vm/hypervisor/versions.sh:
 Permission denied

root@mgmtserver:~/github/cshv3/client# 
./target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/versions.sh
Host.OS=Unknown Linux
Host.OS.Version=X.Y
Host.OS.Kernel.Version=3.2.0-4-amd64


Are you using an O/S with permissions disabled?


DL



-----Original Message-----
From: SuichII, Christopher [mailto:chris.su...@netapp.com<http://netapp.com>]
Sent: 15 August 2013 20:13
To: <dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>>
Cc: Donal Lafferty; Alex Huang
Subject: Re: Changes to cloud-client-ui jetty webAppSourceDirectory and hot
deploying API Plugins

As I look in to this, it looks like the problem definitely comes from switching
Jetty from using the target/...4.3.0/ to target/generated-webapp/

The maven-war-plugin creates all the war files in target/cloud-client-ui-4.3.0-
SNAPSHOT/ then copies *some* of it to target/generated-webapp/ from
client/ and then create the cloud-client-ui-4.3.0-SNAPSHOT.war.

I'm not all that strong with maven, so despite some digging, I can't figure out
why it creates and copies WEB-INF/classes/ from client/ but not WEB-INF/lib/

Still not sure why the mvn repo is used? Maybe it falls back to that to
populate the classpath?

On Aug 15, 2013, at 2:28 PM, Chiradeep Vittal 
<chiradeep.vit...@citrix.com<mailto:chiradeep.vit...@citrix.com>>
wrote:

Seems related to https://issues.apache.org/jira/browse/CLOUDSTACK-
3650
Not sure about why the mvn repo is used. Have you tried clean install?

On 8/15/13 11:05 AM, "SuichII, Christopher" 
<chris.su...@netapp.com<mailto:chris.su...@netapp.com>>
wrote:

Some of you may remember a previous thread where I talked a bit about
this, so bear with me:

We are working on an API plugin that we would like to be hot
deployable (not committed to source and can be deployed at any time).
In a previous discussion, I was told that this had not been tested
with CloudStack, but luckily it worked with no fancy tricks. This was
because I could drop our jar into
client/target/cloud-client-ui-4.2.0-SNAPSHOT/WEB-INF/lib and the jar
would automagically get picked up on the class path.

This changed a couple days ago. It looks like with commit
49c9fbfb70413f86642956423c4bbba2e43d8aec this was changed to use the
client/target/generated-webapp/ folder instead. The issue I'm running
in to is that this jetty deployment does not have a WEB-INF/lib
folder - it appears to use the dependencies straight from the local
maven repo instead.

Can someone briefly explain the reasoning behind this change? I am
now unable to hot deploy our jar to a compiled build without editing
client/pom.xml to add an additional folder to the <extraClasspath> tag.

This raises another question I've been meaning to ask. How is the
jetty folder hierarchy structured when someone downloads a release
build of CloudStack? Is there a lib folder where jars like this could
be dropped, or is everything packaged into a single file?

Thanks,
Chris


Reply via email to