You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by "SuichII, Christopher" <Ch...@netapp.com> on 2013/08/15 20:05:19 UTC
Changes to cloud-client-ui jetty webAppSourceDirectory and hot
deploying API Plugins
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
RE: Changes to cloud-client-ui jetty webAppSourceDirectory and hot
deploying API Plugins
Posted by Donal Lafferty <do...@citrix.com>.
Hi Hugo,
Have a read of the log snippet in https://issues.apache.org/jira/browse/CLOUDSTACK-3650
DL
> -----Original Message-----
> From: Hugo Trippaers [mailto:trippie@gmail.com]
> Sent: 16 August 2013 10:46
> To: dev@cloudstack.apache.org
> Cc: SuichII, Christopher; <de...@cloudstack.apache.org>; Alex Huang
> Subject: Re: Changes to cloud-client-ui jetty webAppSourceDirectory and hot
> deploying API Plugins
>
> 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 <do...@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.finalNa
> me}</webAppSourceDirectory> E.g.
> >
> > root@mgmtserver:~/github/cshv3/client# ls -al
> > ./target/cloud-client-ui-4.2.0-SNAPSHOT/WEB-INF/classes/scripts/vm/hyp
> > ervisor/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/hyp
> > ervisor/versions.sh
> >
> > versus
> >
> > root@mgmtserver:~/github/cshv3/client# ls -al
> > ./target/generated-webapp/WEB-
> INF/classes/scripts/vm/hypervisor/versio
> > ns.sh -rwxr-xr-x 1 root 1636 Aug 14 15:42
> > ./target/generated-webapp/WEB-
> INF/classes/scripts/vm/hypervisor/versio
> > ns.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/hyp
> > ervisor/versions.sh
> > -bash:
> > ./target/cloud-client-ui-4.2.0-SNAPSHOT/WEB-INF/classes/scripts/vm/hyp
> > ervisor/versions.sh: Permission denied
> >
> > root@mgmtserver:~/github/cshv3/client#
> > ./target/generated-webapp/WEB-
> INF/classes/scripts/vm/hypervisor/versio
> > ns.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.Suich@netapp.com]
> >> Sent: 15 August 2013 20:13
> >> To: <de...@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
> >> <Ch...@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" <Ch...@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
> >
RE: Changes to cloud-client-ui jetty webAppSourceDirectory and hot
deploying API Plugins
Posted by Donal Lafferty <do...@citrix.com>.
Hi Chris,
I didn't change which files had their permissions set to executable.
You should see a problem if you register a template and are using S3 secondary storage.
You're welcome to rejig the pom.xml. Make sure that Jetty uses scripts with their permissions set to executable.
DL
From: SuichII, Christopher [mailto:Chris.Suich@netapp.com]
Sent: 16 August 2013 13:00
To: Donal Lafferty
Cc: dev@cloudstack.apache.org; Alex Huang
Subject: Re: Changes to cloud-client-ui jetty webAppSourceDirectory and hot deploying API Plugins
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 <tr...@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 <do...@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.Suich@netapp.com<http://netapp.com>]
Sent: 15 August 2013 20:13
To: <de...@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 <Ch...@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" <Ch...@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
Re: Changes to cloud-client-ui jetty webAppSourceDirectory and hot
deploying API Plugins
Posted by "SuichII, Christopher" <Ch...@netapp.com>.
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 <tr...@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 <do...@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.Suich@netapp.com<http://netapp.com>]
Sent: 15 August 2013 20:13
To: <de...@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 <Ch...@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" <Ch...@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
Re: Changes to cloud-client-ui jetty webAppSourceDirectory and hot deploying API Plugins
Posted by Hugo Trippaers <tr...@gmail.com>.
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 <do...@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.Suich@netapp.com]
>> Sent: 15 August 2013 20:13
>> To: <de...@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 <Ch...@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" <Ch...@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
>
RE: Changes to cloud-client-ui jetty webAppSourceDirectory and hot
deploying API Plugins
Posted by Donal Lafferty <do...@citrix.com>.
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.Suich@netapp.com]
> Sent: 15 August 2013 20:13
> To: <de...@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 <Ch...@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" <Ch...@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
> >
Re: Changes to cloud-client-ui jetty webAppSourceDirectory and hot
deploying API Plugins
Posted by "SuichII, Christopher" <Ch...@netapp.com>.
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 <Ch...@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" <Ch...@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
>
Re: Changes to cloud-client-ui jetty webAppSourceDirectory and hot
deploying API Plugins
Posted by Chiradeep Vittal <Ch...@citrix.com>.
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" <Ch...@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