svn commit: r1588279 - /ace/site/trunk/content/news.mdtext

2014-04-17 Thread marrs
Author: marrs
Date: Thu Apr 17 15:14:57 2014
New Revision: 1588279

URL: http://svn.apache.org/r1588279
Log:
Added our talk at ApacheCon.

Modified:
ace/site/trunk/content/news.mdtext

Modified: ace/site/trunk/content/news.mdtext
URL: 
http://svn.apache.org/viewvc/ace/site/trunk/content/news.mdtext?rev=1588279&r1=1588278&r2=1588279&view=diff
==
--- ace/site/trunk/content/news.mdtext (original)
+++ ace/site/trunk/content/news.mdtext Thu Apr 17 15:14:57 2014
@@ -1,5 +1,6 @@
 Title: News
 
+* *April 8th, 2014* - [Continuous Automated Deployment with Apache 
ACE](http://apacheconnorthamerica2014.sched.org/event/39456b8b6aa54b56b5851702333e8471)
 talk at ApacheCon NA 2014 by Jan Willem Janssen and Marcel Offermans. [Slides 
are 
here](http://events.linuxfoundation.org/sites/events/files/slides/Continuous%20Automated%20Deployment%20with%20Apache%20ACE.pdf);
 * *July 18th, 2013* - The PMC is proud to announce that Bram de Kruijff, Jan 
Willem Janssen and Paul Bakker have accepted to join the ACE PMC;
 * *June 17th, 2013* - We're proud to announce the Apache ACE 1.0.0 release! 
[Get it here](/downloads.html);
 * *February 27th, 2012* - Press Release: [The Apache Software Foundation 
Announces Apache ACE as a Top-Level 
Project](https://blogs.apache.org/foundation/entry/the_apache_software_foundation_announces23);




svn commit: r1588277 - /ace/site/trunk/content/dev-doc/release-guide.mdtext

2014-04-17 Thread marrs
Author: marrs
Date: Thu Apr 17 15:13:14 2014
New Revision: 1588277

URL: http://svn.apache.org/r1588277
Log:
Small updates to the release guide to better align with the 2.0.1 release I 
just staged.

Modified:
ace/site/trunk/content/dev-doc/release-guide.mdtext

Modified: ace/site/trunk/content/dev-doc/release-guide.mdtext
URL: 
http://svn.apache.org/viewvc/ace/site/trunk/content/dev-doc/release-guide.mdtext?rev=1588277&r1=1588276&r2=1588277&view=diff
==
--- ace/site/trunk/content/dev-doc/release-guide.mdtext (original)
+++ ace/site/trunk/content/dev-doc/release-guide.mdtext Thu Apr 17 15:13:14 2014
@@ -17,21 +17,24 @@ To create a release you *must*:
 
 Before you can start staging a release candidate, you must:
 
-* Make sure there are no dependencies on snapshots/unreleased versions;
+* make sure there are no dependencies on snapshots/unreleased versions;
 * double check that the version you want to create is correctly filled in in 
build/build.xml;
-* create a tagged version of the sources in preparation of the release 
candidate.
+* create a tagged version of the sources in preparation of the release 
candidate:
+
+   ::sh
+   svn copy https://svn.apache.org/repos/asf/ace/trunk/ 
https://svn.apache.org/repos/asf/ace/releases/X.Y.Z -m "Release X.Y.Z"
 
 ## Staging a release candidate
 
 Staging a release starts by checking out a tagged version of the sources:
 
:::sh
-   $ svn co https://svn.apache.org/repos/asf/ace/tags/ace-sources-X.Y.Z 
ace-sources-X.Y.Z
+   $ svn co https://svn.apache.org/repos/asf/ace/releases/X.Y.Z ace-X.Y.Z
 
 The next step is to build the software and create the archives:
 
:::sh
-   $ cd ace-sources-X.Y.Z/build
+   $ cd ace-X.Y.Z/build
$ ant
$ ant package
 
@@ -53,7 +56,6 @@ be done using "svnpubsub" which is taken
 Start a vote on the d...@ace.apache.org list, for example (be sure to replace
 X.Y.Z with the *correct* version!):
 
-   :::sh
To: "Apache ACE developers list" 
Subject: [VOTE] Release ACE version X.Y.Z

@@ -111,11 +113,6 @@ following target:
:::sh
$ ant promote-to-release
 
-Then update the tag in subversion, for example for the *X.Y.Z* release like 
this:
-
-   :::sh
-   $ svn move https://svn.apache.org/repos/asf/ace/tags/ace-sources-X.Y.Z 
https://svn.apache.org/repos/asf/ace/releases/ace-sources-X.Y.Z -m "Apache ACE 
release X.Y.Z tagged."
-
 Now wait at least 24 hours to allow the release to be properly mirrored and
 then update the news and download page on the Apache ACE website and announce
 the release:
@@ -128,6 +125,10 @@ the release:
This release is available from our download page at:
http://ace.apache.org/downloads.html
 
+After announcing the release, please update the baseline bundles contained in
+trunk/cnf/releaserepo based on the released artifacts (remove old versions, 
keep
+only the latest one).
+
 
 ## Cancelling the release
 




svn commit: r5075 - /dev/ace/apache-ace-2.0.1/

2014-04-17 Thread marrs
Author: marrs
Date: Thu Apr 17 11:36:58 2014
New Revision: 5075

Log:
Staging Apache ACE version 2.0.1.

Added:
dev/ace/apache-ace-2.0.1/
dev/ace/apache-ace-2.0.1/apache-ace-2.0.1-bin.zip   (with props)
dev/ace/apache-ace-2.0.1/apache-ace-2.0.1-bin.zip.asc
dev/ace/apache-ace-2.0.1/apache-ace-2.0.1-bin.zip.md5
dev/ace/apache-ace-2.0.1/apache-ace-2.0.1-bin.zip.sha
dev/ace/apache-ace-2.0.1/apache-ace-2.0.1-deps.zip   (with props)
dev/ace/apache-ace-2.0.1/apache-ace-2.0.1-deps.zip.asc
dev/ace/apache-ace-2.0.1/apache-ace-2.0.1-deps.zip.md5
dev/ace/apache-ace-2.0.1/apache-ace-2.0.1-deps.zip.sha
dev/ace/apache-ace-2.0.1/apache-ace-2.0.1-src.zip   (with props)
dev/ace/apache-ace-2.0.1/apache-ace-2.0.1-src.zip.asc
dev/ace/apache-ace-2.0.1/apache-ace-2.0.1-src.zip.md5
dev/ace/apache-ace-2.0.1/apache-ace-2.0.1-src.zip.sha

Added: dev/ace/apache-ace-2.0.1/apache-ace-2.0.1-bin.zip
==
Binary file - no diff available.

Propchange: dev/ace/apache-ace-2.0.1/apache-ace-2.0.1-bin.zip
--
svn:mime-type = application/octet-stream

Added: dev/ace/apache-ace-2.0.1/apache-ace-2.0.1-bin.zip.asc
==
--- dev/ace/apache-ace-2.0.1/apache-ace-2.0.1-bin.zip.asc (added)
+++ dev/ace/apache-ace-2.0.1/apache-ace-2.0.1-bin.zip.asc Thu Apr 17 11:36:58 
2014
@@ -0,0 +1,7 @@
+-BEGIN PGP SIGNATURE-
+Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
+
+iEYEABECAAYFAlNPu+EACgkQdKIfk8XpYE9n1wCfYy0Fpb56LxwPkGWkW7ZqlFEG
+miQAoN1sxDvriYSymOFO7h+PvDwPfKQx
+=aMuK
+-END PGP SIGNATURE-

Added: dev/ace/apache-ace-2.0.1/apache-ace-2.0.1-bin.zip.md5
==
--- dev/ace/apache-ace-2.0.1/apache-ace-2.0.1-bin.zip.md5 (added)
+++ dev/ace/apache-ace-2.0.1/apache-ace-2.0.1-bin.zip.md5 Thu Apr 17 11:36:58 
2014
@@ -0,0 +1 @@
+apache-ace-2.0.1-bin.zip: CE FF DA 1F 8F 65 58 FB  A5 47 CD 5E 5B 04 15 9A

Added: dev/ace/apache-ace-2.0.1/apache-ace-2.0.1-bin.zip.sha
==
--- dev/ace/apache-ace-2.0.1/apache-ace-2.0.1-bin.zip.sha (added)
+++ dev/ace/apache-ace-2.0.1/apache-ace-2.0.1-bin.zip.sha Thu Apr 17 11:36:58 
2014
@@ -0,0 +1,3 @@
+apache-ace-2.0.1-bin.zip: E6C58549 3258CD25 C2D201F8 6482D869 AE299FDC 0B11D9A5
+  F4408FFD 7C9308A3 CEAA69CC ABCEDB8F 98635234 DB23F32C
+  8C0CCBA5 3C9B17AB 88737AAD 0D31886C

Added: dev/ace/apache-ace-2.0.1/apache-ace-2.0.1-deps.zip
==
Binary file - no diff available.

Propchange: dev/ace/apache-ace-2.0.1/apache-ace-2.0.1-deps.zip
--
svn:mime-type = application/octet-stream

Added: dev/ace/apache-ace-2.0.1/apache-ace-2.0.1-deps.zip.asc
==
--- dev/ace/apache-ace-2.0.1/apache-ace-2.0.1-deps.zip.asc (added)
+++ dev/ace/apache-ace-2.0.1/apache-ace-2.0.1-deps.zip.asc Thu Apr 17 11:36:58 
2014
@@ -0,0 +1,7 @@
+-BEGIN PGP SIGNATURE-
+Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
+
+iEYEABECAAYFAlNPu9kACgkQdKIfk8XpYE8cQACcChiFSbpn8+aL8MW/4DNg8HNp
+utsAoJwhoDEY+qz22DCFl54omofVB9lF
+=muZd
+-END PGP SIGNATURE-

Added: dev/ace/apache-ace-2.0.1/apache-ace-2.0.1-deps.zip.md5
==
--- dev/ace/apache-ace-2.0.1/apache-ace-2.0.1-deps.zip.md5 (added)
+++ dev/ace/apache-ace-2.0.1/apache-ace-2.0.1-deps.zip.md5 Thu Apr 17 11:36:58 
2014
@@ -0,0 +1 @@
+apache-ace-2.0.1-deps.zip: 96 E8 8F 00 AD 4F 6F C3  0E FD 03 1A D8 0B 2D 14

Added: dev/ace/apache-ace-2.0.1/apache-ace-2.0.1-deps.zip.sha
==
--- dev/ace/apache-ace-2.0.1/apache-ace-2.0.1-deps.zip.sha (added)
+++ dev/ace/apache-ace-2.0.1/apache-ace-2.0.1-deps.zip.sha Thu Apr 17 11:36:58 
2014
@@ -0,0 +1,3 @@
+apache-ace-2.0.1-deps.zip: 91C5816D 95A98509 4B0F9F92 24B24765 049F44E0 
F805B755
+   0928F6B5 126D2606 F5911822 CA64702D E068F9E7 
0B1E753A
+   88178036 F0F93916 A422091C DA5B9149

Added: dev/ace/apache-ace-2.0.1/apache-ace-2.0.1-src.zip
==
Binary file - no diff available.

Propchange: dev/ace/apache-ace-2.0.1/apache-ace-2.0.1-src.zip
--
svn:mime-type = application/octet-stream

Added: dev/ace/apache-ace-2.0.1/apache-ace-2.0.1-src.zip.asc
==
--- dev/ace/apache-ace-2.0.1/apache

svn commit: r1588215 - /ace/releases/2.0.1/

2014-04-17 Thread marrs
Author: marrs
Date: Thu Apr 17 11:27:49 2014
New Revision: 1588215

URL: http://svn.apache.org/r1588215
Log:
Release 2.0.1

Added:
ace/releases/2.0.1/
  - copied from r1588214, ace/trunk/



svn commit: r5074 - /dev/ace/apache-ace-2.0.0/

2014-04-17 Thread marrs
Author: marrs
Date: Thu Apr 17 11:26:48 2014
New Revision: 5074

Log:
Removing Apache ACE version 2.0.0 from staging.

Removed:
dev/ace/apache-ace-2.0.0/



svn commit: r1588211 - /ace/trunk/build/resources/deps/LICENSE

2014-04-17 Thread marrs
Author: marrs
Date: Thu Apr 17 11:16:38 2014
New Revision: 1588211

URL: http://svn.apache.org/r1588211
Log:
Included an actual copy of the EPL instead of just a reference.

Modified:
ace/trunk/build/resources/deps/LICENSE

Modified: ace/trunk/build/resources/deps/LICENSE
URL: 
http://svn.apache.org/viewvc/ace/trunk/build/resources/deps/LICENSE?rev=1588211&r1=1588210&r2=1588211&view=diff
==
--- ace/trunk/build/resources/deps/LICENSE (original)
+++ ace/trunk/build/resources/deps/LICENSE Thu Apr 17 11:16:38 2014
@@ -497,3 +497,75 @@ If you did not receive this Content dire
 Disassembler
 
 This plug-in contains a bytecode disassembler ("Disassembler") that can 
produce a listing of the Java assembler mnemonics ("Assembler Mnemonics") for a 
Java method. If you use the Disassembler to view the Assembler Mnemonics for a 
method, you should ensure that doing so will not violate the terms of any 
licenses that apply to your use of that method, as such licenses may not permit 
you to reverse engineer, decompile, or disassemble method bytecodes.
+
+Eclipse Public License - v 1.0
+
+THE ACCOMPANYING PROGRAM IS PROVIDED UNDER THE TERMS OF THIS ECLIPSE PUBLIC 
LICENSE ("AGREEMENT"). ANY USE, REPRODUCTION OR DISTRIBUTION OF THE PROGRAM 
CONSTITUTES RECIPIENT'S ACCEPTANCE OF THIS AGREEMENT.
+
+1. DEFINITIONS
+
+"Contribution" means:
+
+a) in the case of the initial Contributor, the initial code and documentation 
distributed under this Agreement, and
+b) in the case of each subsequent Contributor:
+i) changes to the Program, and
+ii) additions to the Program;
+where such changes and/or additions to the Program originate from and are 
distributed by that particular Contributor. A Contribution 'originates' from a 
Contributor if it was added to the Program by such Contributor itself or anyone 
acting on such Contributor's behalf. Contributions do not include additions to 
the Program which: (i) are separate modules of software distributed in 
conjunction with the Program under their own license agreement, and (ii) are 
not derivative works of the Program.
+"Contributor" means any person or entity that distributes the Program.
+
+"Licensed Patents" mean patent claims licensable by a Contributor which are 
necessarily infringed by the use or sale of its Contribution alone or when 
combined with the Program.
+
+"Program" means the Contributions distributed in accordance with this 
Agreement.
+
+"Recipient" means anyone who receives the Program under this Agreement, 
including all Contributors.
+
+2. GRANT OF RIGHTS
+
+a) Subject to the terms of this Agreement, each Contributor hereby grants 
Recipient a non-exclusive, worldwide, royalty-free copyright license to 
reproduce, prepare derivative works of, publicly display, publicly perform, 
distribute and sublicense the Contribution of such Contributor, if any, and 
such derivative works, in source code and object code form.
+b) Subject to the terms of this Agreement, each Contributor hereby grants 
Recipient a non-exclusive, worldwide, royalty-free patent license under 
Licensed Patents to make, use, sell, offer to sell, import and otherwise 
transfer the Contribution of such Contributor, if any, in source code and 
object code form. This patent license shall apply to the combination of the 
Contribution and the Program if, at the time the Contribution is added by the 
Contributor, such addition of the Contribution causes such combination to be 
covered by the Licensed Patents. The patent license shall not apply to any 
other combinations which include the Contribution. No hardware per se is 
licensed hereunder.
+c) Recipient understands that although each Contributor grants the licenses to 
its Contributions set forth herein, no assurances are provided by any 
Contributor that the Program does not infringe the patent or other intellectual 
property rights of any other entity. Each Contributor disclaims any liability 
to Recipient for claims brought by any other entity based on infringement of 
intellectual property rights or otherwise. As a condition to exercising the 
rights and licenses granted hereunder, each Recipient hereby assumes sole 
responsibility to secure any other intellectual property rights needed, if any. 
For example, if a third party patent license is required to allow Recipient to 
distribute the Program, it is Recipient's responsibility to acquire that 
license before distributing the Program.
+d) Each Contributor represents that to its knowledge it has sufficient 
copyright rights in its Contribution, if any, to grant the copyright license 
set forth in this Agreement.
+3. REQUIREMENTS
+
+A Contributor may choose to distribute the Program in object code form under 
its own license agreement, provided that:
+
+a) it complies with the terms and conditions of this Agreement; and
+b) its license agreement:
+i) effectively disclaims on behalf of all Contributors all warranties an

svn commit: r1588210 - in /ace/trunk/build: build.xml resources/deps/LICENSE

2014-04-17 Thread marrs
Author: marrs
Date: Thu Apr 17 11:12:08 2014
New Revision: 1588210

URL: http://svn.apache.org/r1588210
Log:
Bumped version to 2.0.1 and added a license reference for ECJ.

Modified:
ace/trunk/build/build.xml
ace/trunk/build/resources/deps/LICENSE

Modified: ace/trunk/build/build.xml
URL: 
http://svn.apache.org/viewvc/ace/trunk/build/build.xml?rev=1588210&r1=1588209&r2=1588210&view=diff
==
--- ace/trunk/build/build.xml (original)
+++ ace/trunk/build/build.xml Thu Apr 17 11:12:08 2014
@@ -2,7 +2,7 @@
  


-   
+   




Modified: ace/trunk/build/resources/deps/LICENSE
URL: 
http://svn.apache.org/viewvc/ace/trunk/build/resources/deps/LICENSE?rev=1588210&r1=1588209&r2=1588210&view=diff
==
--- ace/trunk/build/resources/deps/LICENSE (original)
+++ ace/trunk/build/resources/deps/LICENSE Thu Apr 17 11:12:08 2014
@@ -484,4 +484,16 @@ The above copyright notice and this perm
 
 THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
SOFTWARE.
 
+=
+==  ECJ License==
+=
 
+License
+
+The Eclipse Foundation makes available all content in this plug-in 
("Content"). Unless otherwise indicated below, the Content is provided to you 
under the terms and conditions of the Eclipse Public License Version 1.0 
("EPL"). A copy of the EPL is available at 
http://www.eclipse.org/legal/epl-v10.html. For purposes of the EPL, "Program" 
will mean the Content.
+
+If you did not receive this Content directly from the Eclipse Foundation, the 
Content is being redistributed by another party ("Redistributor") and different 
terms and conditions may apply to your use of any object code in the Content. 
Check the Redistributor's license that was provided with the Content. If no 
such license exists, contact the Redistributor. Unless otherwise indicated 
below, the terms and conditions of the EPL still apply to any source code in 
the Content and such source code may be obtained at http://www.eclipse.org.
+
+Disassembler
+
+This plug-in contains a bytecode disassembler ("Disassembler") that can 
produce a listing of the Java assembler mnemonics ("Assembler Mnemonics") for a 
Java method. If you use the Disassembler to view the Assembler Mnemonics for a 
method, you should ensure that doing so will not violate the terms of any 
licenses that apply to your use of that method, as such licenses may not permit 
you to reverse engineer, decompile, or disassemble method bytecodes.




[jira] [Closed] (ACE-405) Split out ACE Bnd repository from gogo bundle

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-405.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Split out ACE Bnd repository from gogo bundle
> -
>
> Key: ACE-405
> URL: https://issues.apache.org/jira/browse/ACE-405
> Project: ACE
>  Issue Type: Bug
>  Components: OBR
>Reporter: Bram de Kruijff
>Assignee: Marcel Offermans
> Fix For: next
>
>
> The AceObrRepository embedded in the gogo bundle can be used as a Bnd(Tools) 
> plugin allowing developers to use an ACE OBR as a writeable/release 
> repository.
> However, as the gogo bundle embed bnd code this may conflict with other bnd 
> libs on the flat ANT classpath during an offline build.
> Therefore this could should be split out into a separate clean bundle.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-375) Build initial scenario for batch job support

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-375.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Build initial scenario for batch job support
> 
>
> Key: ACE-375
> URL: https://issues.apache.org/jira/browse/ACE-375
> Project: ACE
>  Issue Type: Task
>  Components: Client Repository
>Reporter: Marcel Offermans
>Assignee: Marcel Offermans
> Fix For: next
>
>
> Implement a batch job initial scenario, based on a single server and single 
> queue. Requires ACE-374 to be done first.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-342) Design and implement a mechanism to update the management agent itself.

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-342.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Design and implement a mechanism to update the management agent itself.
> ---
>
> Key: ACE-342
> URL: https://issues.apache.org/jira/browse/ACE-342
> Project: ACE
>  Issue Type: New Feature
>  Components: Management Agent
>Reporter: Marcel Offermans
>Assignee: Marcel Offermans
> Fix For: next
>
>
> It would be nice if we could also update the management agent itself. We need 
> to do a bit of design for this upfront, because a bundle cannot just update 
> itself. A common pattern is to install some other bundle to do it for him, 
> but we need to design all possible paths and failures here, so we don't end 
> up with a non-working target.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-462) Event incorrectly handles dictionary parameter

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-462.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Event incorrectly handles dictionary parameter
> --
>
> Key: ACE-462
> URL: https://issues.apache.org/jira/browse/ACE-462
> Project: ACE
>  Issue Type: Bug
>Reporter: J.W. Janssen
>Assignee: Marcel Offermans
>Priority: Critical
> Fix For: next
>
>
> In the construction of org.apache.ace.feedback.Event, a dictionary can be 
> passed that is copied into the created event. However, the code walks through 
> all values of the given dictionary, and handles them as keys, which is not 
> correct.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-436) AgentDeploymentServlet resource leak

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-436.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> AgentDeploymentServlet resource leak
> 
>
> Key: ACE-436
> URL: https://issues.apache.org/jira/browse/ACE-436
> Project: ACE
>  Issue Type: Bug
>  Components: Deployment
>Reporter: J.W. Janssen
>Assignee: Marcel Offermans
> Fix For: next
>
>
> The handlePackageDelivery of the AgentDeploymentServlet does not close the 
> output stream it writes to, causing a potential resource leak, especially 
> when using the {{ContentRangeResponseWrapper}}.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-421) Do not bump repository version when nothing is changed in commit

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-421.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Do not bump repository version when nothing is changed in commit
> 
>
> Key: ACE-421
> URL: https://issues.apache.org/jira/browse/ACE-421
> Project: ACE
>  Issue Type: Bug
>  Components: Repository
>Reporter: J.W. Janssen
>Assignee: Marcel Offermans
> Fix For: next
>
>
> When something is committed to a repository, it always gets a new version 
> regardless whether an actual change has been committed. This makes it hard to 
> detect whether something was actually changed in a repository (for example, 
> to detect whether we need to update other shops).
> The version of a repository should only be bumped in case of real changes. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-411) Build deeptest does not set user.dir to itest project basedir

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-411.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Build deeptest does not set user.dir to itest project basedir
> -
>
> Key: ACE-411
> URL: https://issues.apache.org/jira/browse/ACE-411
> Project: ACE
>  Issue Type: Bug
>  Components: Build
>Reporter: Bram de Kruijff
>Assignee: Marcel Offermans
> Fix For: next
>
>
> Since org.apache.ace.agent.update.itest was added to the build dependson list 
> it fails during a deeptest because it can not locate the relative 'conf' dir. 
> Running the test from the project itself works and this is the first itest 
> project to use a 'conf' dir.
> The log hint is:
> "  [bndtest] ! Failed to start bundle org.apache.ace.configurator.impl-1.0.0, 
> exception activator error Bad arguments; either not an existing directory or 
> an invalid interval. from: org.apache.ace.configurator.Configurator:#83"



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-426) Client bndrun is missing store config

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-426.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Client bndrun is missing store config
> -
>
> Key: ACE-426
> URL: https://issues.apache.org/jira/browse/ACE-426
> Project: ACE
>  Issue Type: Bug
>  Components: Build
>Reporter: Bram de Kruijff
>Assignee: Marcel Offermans
> Fix For: next
>
>
> The run-client definition is missing some config. As a result clients 
> launched with this profile (which is used for the binary release) do not have 
> access to the auditlog.
> {code}
> g! dm notavail
> [35] org.apache.ace.log.server.task
>   java.lang.Runnable, 
> org.apache.ace.log.LogSync(taskName=org.apache.ace.log.server.task.LogSyncTask,name=auditlog,description=Syncs
>  log (name=auditlog, mode=PULL) with a server.) unregistered
> org.apache.ace.connectionfactory.ConnectionFactory service required 
> available
> org.apache.ace.log.server.store.LogStore 
> (&(objectClass=org.apache.ace.log.server.store.LogStore)(name=auditlog)) 
> service required unavailable
> org.apache.ace.discovery.Discovery service required available
> org.osgi.service.log.LogService service optional (not tracking)
> [37] org.apache.ace.nodelauncher.amazon
>   
> org.apache.ace.nodelauncher.NodeLauncher(osgi.command.function={start,stop,properties},osgi.command.scope=node)
>  unregistered
> org.apache.ace.nodelauncher.amazon configuration required unavailable
> [39] org.apache.ace.nodelauncher.ui
>   org.apache.ace.webui.UIExtensionFactory(extension_point=target) unregistered
> org.apache.ace.nodelauncher.NodeLauncher service required unavailable
> org.osgi.service.log.LogService service optional (not tracking)
> [46] org.apache.ace.log.server.store.file
>   org.apache.ace.log.server.store.LogStore(name=auditlog) unregistered
> org.osgi.service.event.EventAdmin service optional (not tracking)
> org.apache.ace.log.server.store.filebased configuration required 
> unavailable
> [47] org.apache.ace.log.server.ui
>   
> org.apache.ace.webui.UIExtensionFactory(service.ranking=10,extension_point=target)
>  unregistered
> org.apache.ace.log.server.store.LogStore service required unavailable
> org.osgi.service.log.LogService service optional (not tracking)
> [52] org.apache.ace.gogo
>   
> java.lang.Object(osgi.command.function={cleanup},osgi.command.scope=ace-log) 
> unregistered
> org.apache.ace.log.server.store.LogStore service required unavailable
> {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-363) Dependencies release package has an empty README

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-363.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Dependencies release package has an empty README
> 
>
> Key: ACE-363
> URL: https://issues.apache.org/jira/browse/ACE-363
> Project: ACE
>  Issue Type: Bug
>Affects Versions: 1.0.0
>Reporter: Bram de Kruijff
>Assignee: Marcel Offermans
>Priority: Minor
> Fix For: next
>
>
> The deps package in the 1.0 release candidate has an empty README in the 
> root. As the instruction is to unzip it over the src package this also 
> overwrites the src README.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-414) Check for new/already downloaded and completed DPs on startup

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-414.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Check for new/already downloaded and completed DPs on startup
> -
>
> Key: ACE-414
> URL: https://issues.apache.org/jira/browse/ACE-414
> Project: ACE
>  Issue Type: Improvement
>  Components: Deployment
>Affects Versions: 1.0.0
>Reporter: Wilfried Sibla
>Assignee: Marcel Offermans
> Fix For: next
>
>
> if the new agent couldn't install a completely downloaded DP (e.g. caused by 
> a JVM crash/OSGi container restart), the DP isn't installed after restart.
> The DP is downloadad again.
> This is not a good solution in embedded scenarios.
> A complete DP should/could be installed without any online checks. If there 
> already is a new DP version on server side, it could be updated.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-305) Start level problems with devserver

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-305.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Start level problems with devserver
> ---
>
> Key: ACE-305
> URL: https://issues.apache.org/jira/browse/ACE-305
> Project: ACE
>  Issue Type: Bug
>  Components: Build
>Reporter: Tuomas Kiviaho
>Assignee: Marcel Offermans
> Fix For: next
>
>
> Pax runner script gives followind exception in certain cases. This is easily 
> avoided by lowering start level for required bundles.
> java.lang.IllegalStateException: Can only register services while bundle is 
> active or activating.
> at org.apache.felix.framework.Felix.registerService(Felix.java:3209)
> at 
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346)
> at 
> org.apache.felix.http.base.internal.HttpServiceController.register(HttpServiceController.java:135)
> at 
> org.apache.felix.http.base.internal.DispatcherServlet.init(DispatcherServlet.java:48)
> at 
> org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:440)
> at 
> org.mortbay.jetty.servlet.ServletHolder.doStart(ServletHolder.java:263)
> at 
> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
> at 
> org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:685)
> at org.mortbay.jetty.servlet.Context.startContext(Context.java:140)
> at 
> org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)
> at 
> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
> at 
> org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
> at org.mortbay.jetty.Server.doStart(Server.java:224)
> at 
> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
> at 
> org.apache.felix.http.jetty.internal.JettyService.initializeJetty(JettyService.java:164)
> at 
> org.apache.felix.http.jetty.internal.JettyService.startJetty(JettyService.java:115)
> at 
> org.apache.felix.http.jetty.internal.JettyService.run(JettyService.java:290)
> at java.lang.Thread.run(Thread.java:662)
> [INFO] Started jetty 6.1.x at port(s) HTTP:8082



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-424) Remove the "old" managementagent from the codebase.

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-424.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Remove the "old" managementagent from the codebase.
> ---
>
> Key: ACE-424
> URL: https://issues.apache.org/jira/browse/ACE-424
> Project: ACE
>  Issue Type: Bug
>Reporter: Marcel Offermans
>Assignee: Marcel Offermans
> Fix For: next
>
>
> The "old" managementagent, which has recently been replaced by 
> org.apache.ace.agent, should be removed from the codebase. That means we need 
> to remove org.apache.ace.managementagent as well as various pieces of code 
> from other projects that were specific to the agent.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-330) Refactor the deployment repository to optionally limit the number of "old" versions for a target

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-330.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Refactor the deployment repository to optionally limit the number of "old" 
> versions for a target
> 
>
> Key: ACE-330
> URL: https://issues.apache.org/jira/browse/ACE-330
> Project: ACE
>  Issue Type: Improvement
>  Components: Deployment
>Reporter: Marcel Offermans
>Assignee: Marcel Offermans
> Fix For: next
>
>
> Currently, the deployment repository contains a full history of versions for 
> each target, from the 1st one up til the current one. Optionally, we can 
> limit the number of old versions for a target (to, for example 10, or any 
> other limit a user sets). The downside is that you won't be able to go back 
> to older versions. The upside is that this can significantly reduce the size 
> of the repository.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-463) RepositoryObjectImpl optimalisation

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-463.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> RepositoryObjectImpl optimalisation
> ---
>
> Key: ACE-463
> URL: https://issues.apache.org/jira/browse/ACE-463
> Project: ACE
>  Issue Type: Improvement
>Reporter: J.W. Janssen
>Assignee: Marcel Offermans
> Fix For: next
>
>
> During some profiling sessions, it appears that the keys() method of 
> RepositoryObjectImpl is called quite often and recreates a new HashSet upon 
> each call. This is not really necessary, as we have full control of the 
> attributes and keys objects used in this method.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-439) Launcher not finished

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-439.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Launcher not finished
> -
>
> Key: ACE-439
> URL: https://issues.apache.org/jira/browse/ACE-439
> Project: ACE
>  Issue Type: Bug
>Reporter: Jago de Vreede
>Assignee: Marcel Offermans
> Fix For: next
>
> Attachments: Launcher.diff
>
>
> There were some problems with the new Launcher
> -  some typo's
> -  was not able to give a server url or agent id as command line param while 
> help stated that that was possible
> -  Help had a TODO left in it
> Attached patch will fix that, and thus have a functioning Launcher



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-396) StatefulTargetRepository updates asynchonously

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-396.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> StatefulTargetRepository updates asynchonously 
> ---
>
> Key: ACE-396
> URL: https://issues.apache.org/jira/browse/ACE-396
> Project: ACE
>  Issue Type: Bug
>Reporter: Bram de Kruijff
>Assignee: Marcel Offermans
>Priority: Critical
> Fix For: next
>
>
> The StatefulTargetRepository listens to and acts upon events sent over public 
> (asynchronous) topics resulting in all kinds of race conditions



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-431) Agent configuration is not set correctly in any case

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-431.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Agent configuration is not set correctly in any case
> 
>
> Key: ACE-431
> URL: https://issues.apache.org/jira/browse/ACE-431
> Project: ACE
>  Issue Type: Bug
>  Components: Management Agent
>Affects Versions: 1.0.0
>Reporter: Wilfried Sibla
>Assignee: Marcel Offermans
> Fix For: next
>
>
> Occasionally it happens that the config parameter agent.controller.syncdelay 
> is not set in DefaultController.handle before it is used in 
> DefaultController.start.
> This seems to be a concurrency issue.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Updated] (ACE-391) Make file repository storage location configurable

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans updated ACE-391:
-

Fix Version/s: next

> Make file repository storage location configurable
> --
>
> Key: ACE-391
> URL: https://issues.apache.org/jira/browse/ACE-391
> Project: ACE
>  Issue Type: Improvement
>Reporter: Bram de Kruijff
>Assignee: Marcel Offermans
> Fix For: next
>
>
> Currently all repository files are stored in the bundle cache. In some 
> integration/management/backup cases it is desirable to maintain a configured 
> deterministic location on the filesystem.
> To support these cases configuration of a non-default location outside the 
> bundle cache should be an option.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Updated] (ACE-397) Change the "approve changes" process.

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans updated ACE-397:
-

Fix Version/s: next

> Change the "approve changes" process.
> -
>
> Key: ACE-397
> URL: https://issues.apache.org/jira/browse/ACE-397
> Project: ACE
>  Issue Type: Improvement
>  Components: Client Repository
>Affects Versions: 1.0.0
>Reporter: Marcel Offermans
>Assignee: Marcel Offermans
> Fix For: next
>
>
> Before any change becomes visible for a target, it has to be approved. This 
> can either be done manually or automatically (by setting auto approve for 
> that target). Conceptually this is fine, but the current implementation has a 
> problem.
> As soon as you "approve" a change for a target, it will generate a new 
> deployment version for that target. This happens before you commit your 
> workspace, and it can happen multiple times. The problems this creates, 
> potentially, are:
> 1) When you approve more than once, you get more than one new version of the 
> software for that target. This is probably not what you want, and can even 
> lead to unnecessary deployment traffic.
> 2) When you rollback (or just don't commit) your changes, a side effect of 
> the creation of new deployment versions is that template processors generate 
> and upload new artifacts. These are not cleaned up. To make matters worse, if 
> you lateron do try to commit new changes, you will probably end up with a 
> name clash as the same names will be used again (but with different content).
> These problems can be resolved by redesigning the way the approve process 
> works:
> When you approve changes, you still state to the system that any changes for 
> this target should lead to a new deployment version, but instead of 
> generating that deployment version immediately, we should defer that action 
> to a "pre-commit" phase that happens just before the final commit of the 
> repositories. That solves problem 1) because you can now never generate more 
> than one new version and problem 2) because nothing is generated until you 
> commit.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Updated] (ACE-268) Make methods for supplying credentials in ConnectionFactory configurable.

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans updated ACE-268:
-

Fix Version/s: next

> Make methods for supplying credentials in ConnectionFactory configurable.
> -
>
> Key: ACE-268
> URL: https://issues.apache.org/jira/browse/ACE-268
> Project: ACE
>  Issue Type: Improvement
>  Components: Connection Factory
>Reporter: J.W. Janssen
>Assignee: Marcel Offermans
> Fix For: next
>
>
> Currently, the connection factory only handles basic authentication. This is 
> not very configurable. It should be possible to add other means of passing 
> credentials as well.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Updated] (ACE-365) OBR non-bundle metadata has no symbolicname/version metadata

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans updated ACE-365:
-

Fix Version/s: next

> OBR non-bundle metadata has no symbolicname/version metadata
> 
>
> Key: ACE-365
> URL: https://issues.apache.org/jira/browse/ACE-365
> Project: ACE
>  Issue Type: Improvement
>Affects Versions: 1.0.0
>Reporter: Bram de Kruijff
>Assignee: Marcel Offermans
> Fix For: next
>
>
> Although the ACE OBR support uploading non-bundle resources based on the 
> filename := -.  heuristic, this metadata is not reflected 
> in the respository.xml index. Infact it only species the resource.uri.
> As a result it is impossible to find these resources by querying the 
> repository in a sensible way, such as using a requirement with an 
> osgi.identity= filter directive.
> Therefore, I suggest to at least add the resource.symbolicname and 
> resource.version to the current implementation. This is in line with R5 where 
> every resource will have an osgi.identity and osgi.content namespace 
> capability.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Updated] (ACE-392) Add some scripts for delivering ACE in various binary formats

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans updated ACE-392:
-

Fix Version/s: next

> Add some scripts for delivering ACE in various binary formats
> -
>
> Key: ACE-392
> URL: https://issues.apache.org/jira/browse/ACE-392
> Project: ACE
>  Issue Type: Task
>Reporter: Marcel Offermans
>Assignee: Marcel Offermans
> Fix For: next
>
>
> Right now, we have a binary distribution package that is part of our build 
> that is usable out of the box. However, there are many more possible 
> distribution formats we could support, to make it easier for people to create 
> a distribution that suits their needs. This issue is about creating a 
> flexible distribution package that can easily be customized.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Updated] (ACE-458) improve logging when adding entity to workspace failed

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans updated ACE-458:
-

Fix Version/s: next

> improve logging when adding entity to workspace failed
> --
>
> Key: ACE-458
> URL: https://issues.apache.org/jira/browse/ACE-458
> Project: ACE
>  Issue Type: Improvement
>Reporter: Arjan Schaaf
>Assignee: Marcel Offermans
>Priority: Minor
> Fix For: next
>
> Attachments: ACE-458.patch
>
>
> I tried to add a target with the same ID through the REST interface twice. Of 
> course this fails at the second attempt. The log shows an error message 
> without any data to identify which entity failed to be added and the attached 
> stacktrace doesn't help either:
> {code}
> 2014.02.15 04:04:04 WARNING - Bundle: org.apache.ace.client.rest - Failed to 
> add entity of type: target - java.lang.IllegalArgumentException: Failed to 
> add new object: entity already exists!
> at 
> org.apache.ace.client.repository.impl.ObjectRepositoryImpl.create(ObjectRepositoryImpl.java:93)
> at 
> org.apache.ace.client.repository.stateful.impl.StatefulTargetRepositoryImpl.preregister(StatefulTargetRepositoryImpl.java:136)
> at 
> org.apache.ace.client.rest.Workspace.addRepositoryObject(Workspace.java:213)
> at 
> org.apache.ace.client.rest.RESTClientServlet.createRepositoryObject(RESTClientServlet.java:429)
> at 
> org.apache.ace.client.rest.RESTClientServlet.doPost(RESTClientServlet.java:370)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
> at 
> org.apache.felix.http.base.internal.handler.ServletHandler.doHandle(ServletHandler.java:96)
> at 
> org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:79)
> at 
> org.apache.felix.http.base.internal.dispatch.ServletPipeline.handle(ServletPipeline.java:42)
> at 
> org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:49)
> at 
> org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:33)
> at 
> org.apache.felix.http.base.internal.dispatch.FilterPipeline.dispatch(FilterPipeline.java:48)
> at 
> org.apache.felix.http.base.internal.dispatch.Dispatcher.dispatch(Dispatcher.java:39)
> at 
> org.apache.felix.http.base.internal.DispatcherServlet.service(DispatcherServlet.java:67)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
> at 
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:654)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:445)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:225)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1044)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:372)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:189)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:978)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
> at org.eclipse.jetty.server.Server.handle(Server.java:369)
> at 
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:486)
> at 
> org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:944)
> at 
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1005)
> at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:865)
> at 
> org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)
> at 
> org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
> at 
> org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:668)
> at 
> org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
> at java.lang.Thread.run(Thread.java:744)
> {code}
> I have created a patch that logs the data describing the entity that caused 
> the failure.



--
This messa

[jira] [Updated] (ACE-372) Add support for getting and updating target attributes.

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans updated ACE-372:
-

Fix Version/s: next

> Add support for getting and updating target attributes.
> ---
>
> Key: ACE-372
> URL: https://issues.apache.org/jira/browse/ACE-372
> Project: ACE
>  Issue Type: Task
>  Components: Client Repository, Management Agent
>Reporter: Marcel Offermans
>Assignee: Marcel Offermans
> Fix For: next
>
>
> Targets might want to propagate certain attributes back to the server. Those 
> might include things like detected screen sizes, available memory and 
> specific devices that have been detected. By sending those attributes back 
> via the feedback mechanism, we can set them on the target (as tags) so they 
> can be used for example to create smart associations.
> This task is about designing a way to add/update/delete these attributes on 
> the target, send them to the server and pick them up there for inclusion as 
> tags.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Updated] (ACE-384) Add support for deployment package size estimations on the server.

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans updated ACE-384:
-

Fix Version/s: next

> Add support for deployment package size estimations on the server.
> --
>
> Key: ACE-384
> URL: https://issues.apache.org/jira/browse/ACE-384
> Project: ACE
>  Issue Type: Task
>  Components: Deployment
>Reporter: Marcel Offermans
>Assignee: Marcel Offermans
> Fix For: next
>
>
> A management agent currently cannot ask for the size of a deployment package 
> upfront. It might need that to calculate if this would be a good time to 
> update. We should add sizes of artifacts (as attributes) and make sure we 
> also add those to the deployment repository so we can calculate (for normal 
> deployment packages and fix packages) the approximate size of the resulting 
> deployment package.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Updated] (ACE-465) Switch from Filter.match() to Filter.matchCase().

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans updated ACE-465:
-

Fix Version/s: next

> Switch from Filter.match() to Filter.matchCase().
> -
>
> Key: ACE-465
> URL: https://issues.apache.org/jira/browse/ACE-465
> Project: ACE
>  Issue Type: Improvement
>  Components: Client Repository
>Reporter: Marcel Offermans
>Assignee: Marcel Offermans
> Fix For: next
>
>
> Throughout the client codebase a lot of OSGi filter expressions are used (to 
> associate different entities, and to look them up). These are currently all 
> matched based on the match() method in Filter, even though we internally have 
> properties that are case sensitive. Therefore, and because it is quicker, we 
> should switch to matchCase() instead.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Updated] (ACE-445) Add an option to the launcher to set system properties

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans updated ACE-445:
-

Fix Version/s: next

> Add an option to the launcher to set system properties
> --
>
> Key: ACE-445
> URL: https://issues.apache.org/jira/browse/ACE-445
> Project: ACE
>  Issue Type: Bug
>  Components: Launcher
>Reporter: Marcel Offermans
>Assignee: Marcel Offermans
> Fix For: next
>
>
> The launcher supports an option file that can set various kinds of 
> properties, but no system properties. Add an option to set them (via a 
> "system." prefix).



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Updated] (ACE-439) Launcher not finished

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans updated ACE-439:
-

Fix Version/s: next

> Launcher not finished
> -
>
> Key: ACE-439
> URL: https://issues.apache.org/jira/browse/ACE-439
> Project: ACE
>  Issue Type: Bug
>Reporter: Jago de Vreede
>Assignee: Marcel Offermans
> Fix For: next
>
> Attachments: Launcher.diff
>
>
> There were some problems with the new Launcher
> -  some typo's
> -  was not able to give a server url or agent id as command line param while 
> help stated that that was possible
> -  Help had a TODO left in it
> Attached patch will fix that, and thus have a functioning Launcher



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Updated] (ACE-261) Provisioning artifacts without resource processor doesn't give any feedback

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans updated ACE-261:
-

Fix Version/s: next

> Provisioning artifacts without resource processor doesn't give any feedback
> ---
>
> Key: ACE-261
> URL: https://issues.apache.org/jira/browse/ACE-261
> Project: ACE
>  Issue Type: Bug
>  Components: Deployment
>Reporter: J.W. Janssen
>Assignee: Marcel Offermans
> Fix For: next
>
>
> When provisioning configuration files that do not have an associated resource 
> processor cause the deployment to fail without any trace.
> Use case:
> 1. create a feature, distribution & registered target and associate them;
> 2. add a metatype configuration file to the artifacts;
> 3. associate configuration file to feature;
> 4. observe that the target is not marked as changed, however, the 
> retrieve/store/revert buttons are enabled.
> Expected behavior:
> * a warning that the deployment cannot be performed due to missing resource 
> processor. Some feedback should be given to the user about the missing RP 
> (perhaps at upload?)



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Updated] (ACE-413) DP download could not be resumed if download was complete but DP not installed

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans updated ACE-413:
-

Fix Version/s: next

> DP download could not be resumed if download was complete but DP not installed
> --
>
> Key: ACE-413
> URL: https://issues.apache.org/jira/browse/ACE-413
> Project: ACE
>  Issue Type: Bug
>  Components: Deployment
>Affects Versions: 1.0.0
>Reporter: Wilfried Sibla
>Assignee: Marcel Offermans
> Fix For: next
>
>
> If a DP could be downloaded compeletely but not installed (crash/restart of 
> containe etc.), it could not be continued with installing the DP.
> One reason: there is no check on startup if there already is a complete DB
> After asking the server for the new DP version and trying to complete the 
> download (of the DP which is already stored locally and complete), the server 
> returns a http error 416.
> http range header could not be set to the total length of the stream.
> see [http://stackoverflow.com/questions/3303029/http-range-header]



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Updated] (ACE-230) Avoid removed targets to be resurrected by their audit log.

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans updated ACE-230:
-

Fix Version/s: next

> Avoid removed targets to be resurrected by their audit log.
> ---
>
> Key: ACE-230
> URL: https://issues.apache.org/jira/browse/ACE-230
> Project: ACE
>  Issue Type: New Feature
>  Components: Architecture
>Reporter: J.W. Janssen
>Assignee: Marcel Offermans
> Fix For: next
>
>
> The basic fix for ACE-167 allows targets to be removed. However, when there's 
> an audit log present for a target, it will cause the target to be resurrected 
> upon synchronization of the logs. This is not desired. Either the audit log 
> for a target should be purged, or during the audit log synchronization it 
> should detect somehow that a target is removed, thereby avoiding it to be 
> resurrected.
> There are several possibilities for fixing this:
> * purge the entire audit log at the server; when the target is no longer 
> running, the audit log will be recreated for the remaining targets. This 
> won't work if the target is still running (which is rather exotic in this 
> situation), or if there are relay server(s) present to which the removed 
> target once talked. These relay(s) do not have a notion that the target is 
> removed, thus will happily sent their audit logs to the main server, 
> including the one for the removed target. For development situations, this 
> might not be an issue as there are probably no relays involved;
> * add a deleted timestamp attribute to the target object, and not really 
> remove it from the repository. This timestamp will be used during the 
> synchronization process to determine whether there are *new* events that 
> should cause the target to be resurrected. If there are no newer events 
> (i.e., the event timestamp > deleted timestamp), the target will not be 
> recreated. The only thing is that removed targets still remain in the 
> repository, thus need to be hidden in the UI;
> * make the audit log merge process smarted, for example, by only merging 
> audit logs for targets seen in the last N seconds. In combination with a 
> purge of the entire audit log at the server and some patience, it would 
> prevent a removed target to be resurrected.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Updated] (ACE-399) Properly deal with situation where the SAX parser invokes characters() multiple times for a tag

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans updated ACE-399:
-

Fix Version/s: next

> Properly deal with situation where the SAX parser invokes characters() 
> multiple times for a tag
> ---
>
> Key: ACE-399
> URL: https://issues.apache.org/jira/browse/ACE-399
> Project: ACE
>  Issue Type: Bug
>  Components: Deployment
>Affects Versions: 1.0.0
>Reporter: Marcel Offermans
>Assignee: Marcel Offermans
> Fix For: next
>
>
> In some circumstances, the SAX parser will call characters() multiple times 
> for a tag. Whenever its internal buffer overflows. We do not handle that 
> situation correctly in our DeploymentServlet when we parse the contents of 
> tags. Stackoverflow discusses the situation here: 
> http://stackoverflow.com/questions/4567636/java-sax-parser-split-calls-to-characters
> We need to fix our parser! :)



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Updated] (ACE-433) New deployment needs two check cycles to download and to install a new DP

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans updated ACE-433:
-

Fix Version/s: next

> New deployment needs two check cycles to download and to install a new DP
> -
>
> Key: ACE-433
> URL: https://issues.apache.org/jira/browse/ACE-433
> Project: ACE
>  Issue Type: Bug
>  Components: Management Agent
>Affects Versions: 1.0.0
>Reporter: Wilfried Sibla
>Assignee: Marcel Offermans
>Priority: Critical
> Fix For: next
>
> Attachments: AgentError.log
>
>
> I tested the new agent implementation but I observed a little bit curious 
> behavior:
> * At first check, the agent detects and downloads the update DP
> * Then it stops with log entry: [DEBUG] 21:50:31 (downloads) Download stopped 
> early: 926530 of -1 bytes downloaded... (0)
> * on the next check: [DEBUG] 21:50:39 (controller) Checking for deployment 
> updates..
> * new DP is detected: [DEBUG] 21:50:39 (controller) Need to install update: 
> newer deployment version available!
> * Download is resumed: [INFO] 21:50:39 (controller) Download of deployment 
> update is STOPPED. Resuming download...
> * and completed: [DEBUG] 21:51:00 (downloads) Download completed: 926530 
> bytes downloaded...
> This indicates that it needs to cycles to download and really install a DP.
> In DownloadCallableImpl.call():
> * is.getContentSize() return -1 during download
> * afterwards downloadComplete==false (line 100) and stoppedEarly==true (line 
> 101) indicates that the download seems to be stopped (DownloadState.STOPPED 
> in DownloadResult).
> Or is this behaviour (installing a downloaded DP during the next check cycle) 
> intended?



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Updated] (ACE-428) Make uploading to a bundle store more robust and configurable

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans updated ACE-428:
-

Fix Version/s: next

> Make uploading to a bundle store more robust and configurable
> -
>
> Key: ACE-428
> URL: https://issues.apache.org/jira/browse/ACE-428
> Project: ACE
>  Issue Type: Improvement
>  Components: OBR
>Reporter: Marcel Offermans
>Assignee: Marcel Offermans
> Fix For: next
>
>
> There are a couple of issues with the current bundle store:
> 1. The interface extends ManagedService, which is wrong as there is no 
> fundamental reason why every implementation should be configurable.
> 2. If you currently upload the exact same artifact again, the implementation 
> signals this as an error. It would be better if it only did that if the 
> artifact was different (but its metadata the same).
> 3. You cannot currently "forcefully" replace an existing artifact. In 99% of 
> the cases, that is a good thing, but there are a few corner cases where you 
> might want to be able to replace an artifact, so it would be good to add that 
> as an option. One example is the Velocity based artifact preprocessor. It 
> uploads filled out templates which normally have unique names. However, in a 
> specific corner case, if a client commit fails, you might end up with a few 
> artifacts that need to be replaced the next time you commit.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Updated] (ACE-251) Document the configuration template mechanism.

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans updated ACE-251:
-

Fix Version/s: next

> Document the configuration template mechanism.
> --
>
> Key: ACE-251
> URL: https://issues.apache.org/jira/browse/ACE-251
> Project: ACE
>  Issue Type: Task
>  Components: Site
>Reporter: Marcel Offermans
>Assignee: Marcel Offermans
> Fix For: next
>
>
> Our templating mechanism, which is based on Velocity and uses properties of 
> all entities (in)directly related to the target, is currently not documented.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Updated] (ACE-381) Truncate target logs in a configurable way.

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans updated ACE-381:
-

Fix Version/s: next

> Truncate target logs in a configurable way.
> ---
>
> Key: ACE-381
> URL: https://issues.apache.org/jira/browse/ACE-381
> Project: ACE
>  Issue Type: Improvement
>  Components: Log, Management Agent
>Reporter: Marcel Offermans
>Assignee: Marcel Offermans
> Fix For: next
>
> Attachments: 0001-Fixed.patch, ACE-381.patch
>
>
> Target logs should be truncated to a fixed maximum size to prevent disk 
> storage from overflowing.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Updated] (ACE-396) StatefulTargetRepository updates asynchonously

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans updated ACE-396:
-

Fix Version/s: next

> StatefulTargetRepository updates asynchonously 
> ---
>
> Key: ACE-396
> URL: https://issues.apache.org/jira/browse/ACE-396
> Project: ACE
>  Issue Type: Bug
>Reporter: Bram de Kruijff
>Assignee: Marcel Offermans
>Priority: Critical
> Fix For: next
>
>
> The StatefulTargetRepository listens to and acts upon events sent over public 
> (asynchronous) topics resulting in all kinds of race conditions



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Updated] (ACE-407) Upgrade to HTTP service 2.2.1

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans updated ACE-407:
-

Fix Version/s: next

> Upgrade to HTTP service 2.2.1
> -
>
> Key: ACE-407
> URL: https://issues.apache.org/jira/browse/ACE-407
> Project: ACE
>  Issue Type: Improvement
>  Components: Build
>Affects Versions: 1.0.0
>Reporter: Bram de Kruijff
>Assignee: Marcel Offermans
> Fix For: next
>
>
> The Felix HTTP service upgraded to Jetty 7 (see FELIX-2905) and they intend 
> to move to a release. Aside from numerous bug-fixes, improvements and general 
> compatibility concerns, this specifically seems to resolve our startup 
> problem (see ACE-348), allows us to drop our own jetty bundles from the 
> localrepo used for testing and may also help address some HTTP related itest 
> stability issues.
> As I understand Felix intends to release this update in the foreseeable 
> future. Therefore, I suggest we move trunk to the 2.2.1 snapshot so we can 
> properly test it.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


svn commit: r1588178 - /ace/trunk/etc/check_staged_ace.sh

2014-04-17 Thread jawi
Author: jawi
Date: Thu Apr 17 09:01:10 2014
New Revision: 1588178

URL: http://svn.apache.org/r1588178
Log:
Minor corrections for bash.

Modified:
ace/trunk/etc/check_staged_ace.sh

Modified: ace/trunk/etc/check_staged_ace.sh
URL: 
http://svn.apache.org/viewvc/ace/trunk/etc/check_staged_ace.sh?rev=1588178&r1=1588177&r2=1588178&view=diff
==
--- ace/trunk/etc/check_staged_ace.sh (original)
+++ ace/trunk/etc/check_staged_ace.sh Thu Apr 17 09:01:10 2014
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/bash
 #
 # Licensed to the Apache Software Foundation (ASF) under one
 # or more contributor license agreements.  See the NOTICE file
@@ -43,7 +43,7 @@ if [ -z "${version}" -o ! -d "${tmpDir}"
 exit
 fi
 
-function checkSig() {
+checkSig() {
 sigFile="$1.asc"
 if [ ! -f $sigFile ]; then
 echo "$sigFile is missing!!!"
@@ -54,7 +54,7 @@ function checkSig() {
 if [ "$?" = "0" ]; then echo "OK"; else echo "BAD!!!"; fi
 }
 
-function checkSum() {
+checkSum() {
 archive=$1
 sumFile=$2
 alg=$3
@@ -105,12 +105,13 @@ cd ${tmpDir}/apache-ace-${version}
 for f in `find . -type f | grep -v '\.\(asc\|sha1\?\|md5\)$'`; do
 echo "checking $f" 
 
-echo "\tASC: \c"
+echo -e "ASC: \c"
 checkSig $f
-echo "\tMD5: \c"
+echo -e "MD5: \c"
 checkSum $f "$f.md5" MD5
-echo "\tSHA: \c"
+echo -e "SHA: \c"
 checkSum $f "$f.sha" SHA512
+echo ""
 done
 
 cd $PWD




[jira] [Closed] (ACE-397) Change the "approve changes" process.

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-397.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Change the "approve changes" process.
> -
>
> Key: ACE-397
> URL: https://issues.apache.org/jira/browse/ACE-397
> Project: ACE
>  Issue Type: Improvement
>  Components: Client Repository
>Affects Versions: 1.0.0
>Reporter: Marcel Offermans
>Assignee: Marcel Offermans
> Fix For: next
>
>
> Before any change becomes visible for a target, it has to be approved. This 
> can either be done manually or automatically (by setting auto approve for 
> that target). Conceptually this is fine, but the current implementation has a 
> problem.
> As soon as you "approve" a change for a target, it will generate a new 
> deployment version for that target. This happens before you commit your 
> workspace, and it can happen multiple times. The problems this creates, 
> potentially, are:
> 1) When you approve more than once, you get more than one new version of the 
> software for that target. This is probably not what you want, and can even 
> lead to unnecessary deployment traffic.
> 2) When you rollback (or just don't commit) your changes, a side effect of 
> the creation of new deployment versions is that template processors generate 
> and upload new artifacts. These are not cleaned up. To make matters worse, if 
> you lateron do try to commit new changes, you will probably end up with a 
> name clash as the same names will be used again (but with different content).
> These problems can be resolved by redesigning the way the approve process 
> works:
> When you approve changes, you still state to the system that any changes for 
> this target should lead to a new deployment version, but instead of 
> generating that deployment version immediately, we should defer that action 
> to a "pre-commit" phase that happens just before the final commit of the 
> repositories. That solves problem 1) because you can now never generate more 
> than one new version and problem 2) because nothing is generated until you 
> commit.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-161) Create services that complement the tasks in the management agent

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-161.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Create services that complement the tasks in the management agent
> -
>
> Key: ACE-161
> URL: https://issues.apache.org/jira/browse/ACE-161
> Project: ACE
>  Issue Type: Task
>  Components: Management Agent
>Reporter: Marcel Offermans
>Assignee: Marcel Offermans
> Fix For: next
>
>
> Currently, the functionality exposed by the management agent is visible via a 
> set of tasks that can be scheduled. Whilst this is a common use case, it 
> would be nice to also expose the same tasks as OSGi services so they can be 
> invoked directly (in cases where a scheduler is not needed or wanted).
> There are a couple of tasks that can be complemented like this:
>  - deployment
>  - sync logs
>  - subscriptions (still under construction).



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-417) ACE agent launcher should use the same bundle directory as felix (bundle instead of bundles)

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-417.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> ACE agent launcher should use the same bundle directory as felix (bundle 
> instead of bundles)
> 
>
> Key: ACE-417
> URL: https://issues.apache.org/jira/browse/ACE-417
> Project: ACE
>  Issue Type: Improvement
>  Components: Launcher
>Reporter: Wilfried Sibla
>Assignee: Marcel Offermans
>Priority: Minor
> Fix For: next
>
>
> currently the Launcher uses bundles as default bundle directory.
> This should be changed to bundle to be very simple compatible to the default 
> felix configuration.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-378) Truncate server logs.

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-378.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Truncate server logs.
> -
>
> Key: ACE-378
> URL: https://issues.apache.org/jira/browse/ACE-378
> Project: ACE
>  Issue Type: Improvement
>  Components: Log
>Reporter: Marcel Offermans
>Assignee: Marcel Offermans
> Fix For: next
>
> Attachments: ACE-378.patch
>
>
> We need a configurable way to truncate the logs that are stored on the 
> server. At least we should be able to limit them to some maximum size.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-340) Client rest itests unstable

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-340.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Client rest itests unstable
> ---
>
> Key: ACE-340
> URL: https://issues.apache.org/jira/browse/ACE-340
> Project: ACE
>  Issue Type: Bug
>Reporter: Bram de Kruijff
>Assignee: Marcel Offermans
> Fix For: next
>
>
> RESTClientTest fails every now and then. It also does not clean its store 
> making it fail if you run it twice without manually cleaning the store 
> directory.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-384) Add support for deployment package size estimations on the server.

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-384.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Add support for deployment package size estimations on the server.
> --
>
> Key: ACE-384
> URL: https://issues.apache.org/jira/browse/ACE-384
> Project: ACE
>  Issue Type: Task
>  Components: Deployment
>Reporter: Marcel Offermans
>Assignee: Marcel Offermans
> Fix For: next
>
>
> A management agent currently cannot ask for the size of a deployment package 
> upfront. It might need that to calculate if this would be a good time to 
> update. We should add sizes of artifacts (as attributes) and make sure we 
> also add those to the deployment repository so we can calculate (for normal 
> deployment packages and fix packages) the approximate size of the resulting 
> deployment package.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-458) improve logging when adding entity to workspace failed

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-458.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> improve logging when adding entity to workspace failed
> --
>
> Key: ACE-458
> URL: https://issues.apache.org/jira/browse/ACE-458
> Project: ACE
>  Issue Type: Improvement
>Reporter: Arjan Schaaf
>Assignee: Marcel Offermans
>Priority: Minor
> Fix For: next
>
> Attachments: ACE-458.patch
>
>
> I tried to add a target with the same ID through the REST interface twice. Of 
> course this fails at the second attempt. The log shows an error message 
> without any data to identify which entity failed to be added and the attached 
> stacktrace doesn't help either:
> {code}
> 2014.02.15 04:04:04 WARNING - Bundle: org.apache.ace.client.rest - Failed to 
> add entity of type: target - java.lang.IllegalArgumentException: Failed to 
> add new object: entity already exists!
> at 
> org.apache.ace.client.repository.impl.ObjectRepositoryImpl.create(ObjectRepositoryImpl.java:93)
> at 
> org.apache.ace.client.repository.stateful.impl.StatefulTargetRepositoryImpl.preregister(StatefulTargetRepositoryImpl.java:136)
> at 
> org.apache.ace.client.rest.Workspace.addRepositoryObject(Workspace.java:213)
> at 
> org.apache.ace.client.rest.RESTClientServlet.createRepositoryObject(RESTClientServlet.java:429)
> at 
> org.apache.ace.client.rest.RESTClientServlet.doPost(RESTClientServlet.java:370)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
> at 
> org.apache.felix.http.base.internal.handler.ServletHandler.doHandle(ServletHandler.java:96)
> at 
> org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:79)
> at 
> org.apache.felix.http.base.internal.dispatch.ServletPipeline.handle(ServletPipeline.java:42)
> at 
> org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:49)
> at 
> org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:33)
> at 
> org.apache.felix.http.base.internal.dispatch.FilterPipeline.dispatch(FilterPipeline.java:48)
> at 
> org.apache.felix.http.base.internal.dispatch.Dispatcher.dispatch(Dispatcher.java:39)
> at 
> org.apache.felix.http.base.internal.DispatcherServlet.service(DispatcherServlet.java:67)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
> at 
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:654)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:445)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:225)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1044)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:372)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:189)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:978)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
> at org.eclipse.jetty.server.Server.handle(Server.java:369)
> at 
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:486)
> at 
> org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:944)
> at 
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1005)
> at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:865)
> at 
> org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)
> at 
> org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
> at 
> org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:668)
> at 
> org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
> at java.lang.Thread.run(Thread.java:744)
> {code}
> I have created a patch that logs the data de

[jira] [Closed] (ACE-230) Avoid removed targets to be resurrected by their audit log.

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-230.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Avoid removed targets to be resurrected by their audit log.
> ---
>
> Key: ACE-230
> URL: https://issues.apache.org/jira/browse/ACE-230
> Project: ACE
>  Issue Type: New Feature
>  Components: Architecture
>Reporter: J.W. Janssen
>Assignee: Marcel Offermans
> Fix For: next
>
>
> The basic fix for ACE-167 allows targets to be removed. However, when there's 
> an audit log present for a target, it will cause the target to be resurrected 
> upon synchronization of the logs. This is not desired. Either the audit log 
> for a target should be purged, or during the audit log synchronization it 
> should detect somehow that a target is removed, thereby avoiding it to be 
> resurrected.
> There are several possibilities for fixing this:
> * purge the entire audit log at the server; when the target is no longer 
> running, the audit log will be recreated for the remaining targets. This 
> won't work if the target is still running (which is rather exotic in this 
> situation), or if there are relay server(s) present to which the removed 
> target once talked. These relay(s) do not have a notion that the target is 
> removed, thus will happily sent their audit logs to the main server, 
> including the one for the removed target. For development situations, this 
> might not be an issue as there are probably no relays involved;
> * add a deleted timestamp attribute to the target object, and not really 
> remove it from the repository. This timestamp will be used during the 
> synchronization process to determine whether there are *new* events that 
> should cause the target to be resurrected. If there are no newer events 
> (i.e., the event timestamp > deleted timestamp), the target will not be 
> recreated. The only thing is that removed targets still remain in the 
> repository, thus need to be hidden in the UI;
> * make the audit log merge process smarted, for example, by only merging 
> audit logs for targets seen in the last N seconds. In combination with a 
> purge of the entire audit log at the server and some patience, it would 
> prevent a removed target to be resurrected.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-323) Improve management agent update logic

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-323.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Improve management agent update logic
> -
>
> Key: ACE-323
> URL: https://issues.apache.org/jira/browse/ACE-323
> Project: ACE
>  Issue Type: Improvement
>  Components: Management Agent
>Reporter: Marcel Offermans
>Assignee: Marcel Offermans
> Fix For: next
>
>
> The management agent currently keeps retrying a version of the software, even 
> if the previous attempt failed. It could probably become smarter and not 
> retry a version that failed (since the contents of that version cannot 
> change). Or maybe at most, retry once after a restart of the framework. It 
> should of course retry an even newer version.
> This probably also means we need to refactor some of the flow and/or tasks 
> that are currently being executed.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-389) Document how to configure scaling with relays for operation.

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-389.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Document how to configure scaling with relays for operation.
> 
>
> Key: ACE-389
> URL: https://issues.apache.org/jira/browse/ACE-389
> Project: ACE
>  Issue Type: Task
>  Components: Site
>Reporter: Marcel Offermans
>Assignee: Marcel Offermans
> Fix For: next
>
>
> Document how to configure scaling with relays, master and slave servers, etc. 
> This document should target devops that want to use Apache ACE.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-435) DeploymentServlet does not always set the Content-Length

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-435.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> DeploymentServlet does not always set the Content-Length
> 
>
> Key: ACE-435
> URL: https://issues.apache.org/jira/browse/ACE-435
> Project: ACE
>  Issue Type: Bug
>  Components: Deployment
>Reporter: J.W. Janssen
>Assignee: Marcel Offermans
> Fix For: next
>
>
> The DeploymentServlet currently does not always set the Content-Length of the 
> deployment package. This makes that the agent cannot correctly determine the 
> number of bytes it should download and when it is ready downloading.
> A quick glance indicates that we might need to leverage the use of 
> {{ContentRangeResponseWrapper}} for this...



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-430) Deployment events should propagate from the agent to EventAdmin, if available

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-430.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Deployment events should propagate from the agent to EventAdmin, if available
> -
>
> Key: ACE-430
> URL: https://issues.apache.org/jira/browse/ACE-430
> Project: ACE
>  Issue Type: Improvement
>Reporter: Marcel Offermans
>Assignee: Marcel Offermans
> Fix For: next
>
>
> Our new management agent contains an internal implementation of EventAdmin 
> that is used in the DeploymentAdmin bundle to capture the events it throws, 
> regardless of the availability of a "real" EventAdmin implementation.
> That is good.
> What it fails to do however, is propagate those events to a "real" EventAdmin 
> if that is available. That is bad because resource processors or other code 
> might want to listen to those events (or even depend on them, because the 
> specification requires them to be sent).
> We should therefore propagate events to an EventAdmin service, if we find 
> one, without creating a dependency on EventAdmin, which would break the 
> isolation we have now between the agent and the rest of the framework.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-433) New deployment needs two check cycles to download and to install a new DP

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-433.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> New deployment needs two check cycles to download and to install a new DP
> -
>
> Key: ACE-433
> URL: https://issues.apache.org/jira/browse/ACE-433
> Project: ACE
>  Issue Type: Bug
>  Components: Management Agent
>Affects Versions: 1.0.0
>Reporter: Wilfried Sibla
>Assignee: Marcel Offermans
>Priority: Critical
> Fix For: next
>
> Attachments: AgentError.log
>
>
> I tested the new agent implementation but I observed a little bit curious 
> behavior:
> * At first check, the agent detects and downloads the update DP
> * Then it stops with log entry: [DEBUG] 21:50:31 (downloads) Download stopped 
> early: 926530 of -1 bytes downloaded... (0)
> * on the next check: [DEBUG] 21:50:39 (controller) Checking for deployment 
> updates..
> * new DP is detected: [DEBUG] 21:50:39 (controller) Need to install update: 
> newer deployment version available!
> * Download is resumed: [INFO] 21:50:39 (controller) Download of deployment 
> update is STOPPED. Resuming download...
> * and completed: [DEBUG] 21:51:00 (downloads) Download completed: 926530 
> bytes downloaded...
> This indicates that it needs to cycles to download and really install a DP.
> In DownloadCallableImpl.call():
> * is.getContentSize() return -1 during download
> * afterwards downloadComplete==false (line 100) and stoppedEarly==true (line 
> 101) indicates that the download seems to be stopped (DownloadState.STOPPED 
> in DownloadResult).
> Or is this behaviour (installing a downloaded DP during the next check cycle) 
> intended?



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-434) Binary releases store dirs contain wrong artifacts

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-434.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Binary releases store dirs contain wrong artifacts
> --
>
> Key: ACE-434
> URL: https://issues.apache.org/jira/browse/ACE-434
> Project: ACE
>  Issue Type: Bug
>  Components: Build
>Reporter: Bram de Kruijff
>Assignee: Marcel Offermans
> Fix For: next
>
>
> The binary release server and server-allinone projects contain a store 
> directory that includes the old agent launcher and the ACE autofconf jar.
> I am not sure if it makes any sense to include the launcher here, but if so 
> it should be the new one. 
> The new agent is supposed to work with the standard Felix autoconf. I believe 
> [~marrs] is still working on releasing the correct version.
> {code}
> ./build.xml:   file="${target.server.dir}/store/org.apache.ace.launcher.jar" 
> toFile="${target.server.dir}/store/ace-launcher.jar"/>
> ./build.xml:   file="${target.server-allinone.dir}/store/org.apache.ace.launcher.jar" 
> toFile="${target.server-allinone.dir}/store/ace-launcher.jar"/>
> {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-449) IllegalStateException when deploymentversionlimit is re-configured to a value lower than the amount of deployment versions in the repository

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-449.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> IllegalStateException when deploymentversionlimit is re-configured to a value 
> lower than the amount of deployment versions in the repository
> 
>
> Key: ACE-449
> URL: https://issues.apache.org/jira/browse/ACE-449
> Project: ACE
>  Issue Type: Bug
>Reporter: Bram Pouwelse
>Assignee: Marcel Offermans
> Fix For: next
>
>
> When the deploymentversionlimit property in 
> org.apache.ace.client.repository.cfg is re-configured to a value that is 
> lower than the number of deployment versions currently available in the 
> repository I get an IllegalStateException when trying to create a workspace. 
> Steps to reproduce: 
>  - Create a new ace instance (with the default deploymentversionlimit of -1) 
>  - Add a few artifacts ( at least 3)
>  - create a feature, distribution and target
>  - link the feature, distribution and target
>  - add one artifact to the feature 
>  - store 
>  - add a second artifact to the feature 
>  - store 
>  - add a third artifact to the feature 
>  - store
>  - stop ace (at least the client when not using the allinone distibution)
>  - change the deploymentversionlimit to 2 
>  - start ace again
>  - run "ace:cw" in the gogo shell 
> For me this results in the following output: 
> g! ace:cw
> gogo: ConversionException: java.lang.IllegalStateException: The repository is 
> currently busy, so no objects can be removed.
>  Debugging information 
> message : java.lang.IllegalStateException: The repository is 
> currently busy, so no objects can be removed.
> cause-exception : java.lang.IllegalArgumentException
> cause-message   : java.lang.IllegalStateException: The repository is 
> currently busy, so no objects can be removed.
> class   : 
> org.apache.ace.client.repository.impl.RepositorySerializer
> required-type   : 
> org.apache.ace.client.repository.impl.RepositorySerializer
> path: /repository/deploymentversions/deploymentversion[3]
> line number : 68
> ---



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-334) Reintroduce the context menu for targets so we can, for example, approve selected targets

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-334.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Reintroduce the context menu for targets so we can, for example, approve 
> selected targets
> -
>
> Key: ACE-334
> URL: https://issues.apache.org/jira/browse/ACE-334
> Project: ACE
>  Issue Type: Improvement
>  Components: UI
>Reporter: Marcel Offermans
>Assignee: Marcel Offermans
> Fix For: next
>
>
> We need to reintroduce the context menu so we can, for example, approve all 
> selected targets at once and do other operations on selections. This specific 
> option is now hidden in a tab when you open the details of a target, which 
> means you need to visit all of them one by one.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-178) Add extra artifact metadata to generated deployment packages

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-178.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Add extra artifact metadata to generated deployment packages
> 
>
> Key: ACE-178
> URL: https://issues.apache.org/jira/browse/ACE-178
> Project: ACE
>  Issue Type: Task
>  Components: Deployment
>Reporter: Marcel Offermans
>Assignee: Marcel Offermans
> Fix For: next
>
>
> When generating deployment packages, we would like to add some extra metadata 
> to each artifact. This metadata should end up in the manifest of the 
> deployment package (for each entry). We want to add the following information:
> ApacheACE-Feature: a, b, c
> ApacheACE-Distribution: d, e, f
> So each artifact has a list of features and distributions it belongs to. This 
> list is determined based on the associations, but we're not actually listing 
> those so any dynamics and many to many relations will be lost. However, this 
> simplifies the model considerably, ensuring we can create those features and 
> distributions in another instance of ACE easily.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-400) Server should run in daemon mode

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-400.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Server should run in daemon mode
> 
>
> Key: ACE-400
> URL: https://issues.apache.org/jira/browse/ACE-400
> Project: ACE
>  Issue Type: Bug
>  Components: Launcher
>Affects Versions: 1.0.0
>Reporter: Bryan Hunt
>Assignee: Marcel Offermans
> Fix For: next
>
>
> The server runs with the OSGi console which does not allow you to background 
> the process and run the server as a daemon.  This makes deploying the server 
> in a production system impossible.  If you still want a console, you might 
> consider switching to the remote console.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-383) Make bundle event inclusion a configurable setting in the audit log.

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-383.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Make bundle event inclusion a configurable setting in the audit log.
> 
>
> Key: ACE-383
> URL: https://issues.apache.org/jira/browse/ACE-383
> Project: ACE
>  Issue Type: Task
>  Components: Log, Management Agent
>Reporter: Marcel Offermans
>Assignee: Marcel Offermans
> Fix For: next
>
> Attachments: ACE-383.patch
>
>
> Currently, the audit log always includes all bundle life cycle events. We 
> would like to optionally exclude that information. It is not used by the 
> server now, and it might not be interesting for everybody.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-147) Add ACE Karaf commands bundles

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-147.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Add ACE Karaf commands bundles
> --
>
> Key: ACE-147
> URL: https://issues.apache.org/jira/browse/ACE-147
> Project: ACE
>  Issue Type: New Feature
>Reporter: Jean-Baptiste Onofré
>Assignee: Marcel Offermans
>  Labels: karaf
> Fix For: next
>
>
> We can provide Karaf commands bundles (including completion, etc) per ACE 
> areas:
> * on the ACE agent runtime
> - command to show the ACE discover server
> - command to show the ACE agent ID
> - command to start/stop ACE agent and set properties
> * on the ACE server runtime
> - show/remove the registered agents
> - administrate the OBR, distributions, etc
> * on the ACE gateway runtime
> - list the gateway, etc
> ...



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-372) Add support for getting and updating target attributes.

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-372.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Add support for getting and updating target attributes.
> ---
>
> Key: ACE-372
> URL: https://issues.apache.org/jira/browse/ACE-372
> Project: ACE
>  Issue Type: Task
>  Components: Client Repository, Management Agent
>Reporter: Marcel Offermans
>Assignee: Marcel Offermans
> Fix For: next
>
>
> Targets might want to propagate certain attributes back to the server. Those 
> might include things like detected screen sizes, available memory and 
> specific devices that have been detected. By sending those attributes back 
> via the feedback mechanism, we can set them on the target (as tags) so they 
> can be used for example to create smart associations.
> This task is about designing a way to add/update/delete these attributes on 
> the target, send them to the server and pick them up there for inclusion as 
> tags.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-401) ACE configurator throws exception when consuming logging property file

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-401.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> ACE configurator throws exception when consuming logging property file
> --
>
> Key: ACE-401
> URL: https://issues.apache.org/jira/browse/ACE-401
> Project: ACE
>  Issue Type: Bug
>Affects Versions: 1.0.0
>Reporter: Wilfried Sibla
>Assignee: Marcel Offermans
> Fix For: next
>
>
> Exception in thread "Apache ACE Configurator" 
> java.lang.IllegalArgumentException: stop delimiter with no start delimiter: 
> %d{ISO8601} | %-5.5p | %C | %X{bundle.name} | %m%n
>   at 
> org.apache.ace.configurator.Configurator.substVars(Configurator.java:369)
>   at 
> org.apache.ace.configurator.Configurator.substVars(Configurator.java:307)
>   at 
> org.apache.ace.configurator.Configurator.processConfigFile(Configurator.java:201)
>   at 
> org.apache.ace.configurator.Configurator.doConfigs(Configurator.java:151)
>   at org.apache.ace.configurator.Configurator.run(Configurator.java:121)
>   at java.lang.Thread.run(Thread.java:722)
> This line from the cfg file causes the exception:
> log4j.appender.stdout.layout.ConversionPattern=%d{ISO8601} | %-5.5p | %C | 
> %X{bundle.name} | %m%n



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-385) Integrate a deployment package size estimate on the client side.

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-385.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Integrate a deployment package size estimate on the client side.
> 
>
> Key: ACE-385
> URL: https://issues.apache.org/jira/browse/ACE-385
> Project: ACE
>  Issue Type: Task
>  Components: Deployment
>Reporter: Marcel Offermans
>Assignee: Marcel Offermans
> Fix For: next
>
>
> Related to ACE-384 we also need to add support in the client for this.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-407) Upgrade to HTTP service 2.2.1

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-407.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Upgrade to HTTP service 2.2.1
> -
>
> Key: ACE-407
> URL: https://issues.apache.org/jira/browse/ACE-407
> Project: ACE
>  Issue Type: Improvement
>  Components: Build
>Affects Versions: 1.0.0
>Reporter: Bram de Kruijff
>Assignee: Marcel Offermans
> Fix For: next
>
>
> The Felix HTTP service upgraded to Jetty 7 (see FELIX-2905) and they intend 
> to move to a release. Aside from numerous bug-fixes, improvements and general 
> compatibility concerns, this specifically seems to resolve our startup 
> problem (see ACE-348), allows us to drop our own jetty bundles from the 
> localrepo used for testing and may also help address some HTTP related itest 
> stability issues.
> As I understand Felix intends to release this update in the foreseeable 
> future. Therefore, I suggest we move trunk to the 2.2.1 snapshot so we can 
> properly test it.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-373) Trigger a deployment to all targets that have a resource processor when that processor is updated.

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-373.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Trigger a deployment to all targets that have a resource processor when that 
> processor is updated.
> --
>
> Key: ACE-373
> URL: https://issues.apache.org/jira/browse/ACE-373
> Project: ACE
>  Issue Type: Task
>  Components: Client Repository
>Reporter: Marcel Offermans
>Assignee: Marcel Offermans
> Fix For: next
>
>
> Right now, when you upload a new version of a resource processor, it will 
> only be deployed to a target if you also at least upload one (new) artifact 
> of that type. We would like to add the option to send an update to a resource 
> processor to a target even if nothing else changed.
> We need to analyze what the best way is to do this and then implement this.
> Note that a resource processor might want to "reprocess" all artifacts it had 
> already installed in such cases, but that is beyond the scope of this 
> mechanism: it is the responsibility of the resource processor.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-469) Upgrade to latest Gogo Shell release

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-469.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Upgrade to latest Gogo Shell release
> 
>
> Key: ACE-469
> URL: https://issues.apache.org/jira/browse/ACE-469
> Project: ACE
>  Issue Type: Improvement
>  Components: Client Repository
>Reporter: Marcel Offermans
>Assignee: Marcel Offermans
> Fix For: next
>
>
> 0.12.0 versions have been released of runtime and command, which provide 
> bugfixes that affect executing scripts, so we should upgrade to the latest 
> versions before we cut a new release.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-429) Upgrade the build to Bndtools 2.2.2

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-429.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Upgrade the build to Bndtools 2.2.2
> ---
>
> Key: ACE-429
> URL: https://issues.apache.org/jira/browse/ACE-429
> Project: ACE
>  Issue Type: Improvement
>Reporter: Marcel Offermans
>Assignee: Marcel Offermans
> Fix For: next
>
>
> As discussed on the mailing list, we want to upgrade to Bndtools 2.2.2 and 
> enable support for baselining. Baselining will give us a lot of tool support 
> to ensure our code (bundles and exported packages) is semantically versioned. 
> To leverage baselining support there are a couple of things we need to do:
> * We need the to start putting @ProviderType and @ConsumerType annotations on 
> all our APIs. In fact, we need to “retrofit” this to our 1.0.0 release to 
> ensure the baselining works correctly. These annotations are not magically 
> available, but we can add them to the global build path 
> (cnf/ext/defaults.bnd).
> * We need to keep a copy of all released bundles (the latest version of each) 
> in a repository to baseline against. Because we don’t want our build to break 
> when we’re off-line I propose we put them in a local repository. We probably 
> need to build those artifacts with the Eclipse compiler to prevent problems 
> that will otherwise occur because of differences between ecj and javac so: 
> checkout with Eclipse, build, collect all bundles from "generated" folders 
> and publish them into the releaserepo in cnf. We also want to add them to the 
> -deps artifact so people can easily get started with a release with 
> baselining enabled.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-251) Document the configuration template mechanism.

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-251.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Document the configuration template mechanism.
> --
>
> Key: ACE-251
> URL: https://issues.apache.org/jira/browse/ACE-251
> Project: ACE
>  Issue Type: Task
>  Components: Site
>Reporter: Marcel Offermans
>Assignee: Marcel Offermans
> Fix For: next
>
>
> Our templating mechanism, which is based on Velocity and uses properties of 
> all entities (in)directly related to the target, is currently not documented.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-464) ObjectRepositoryImpl uses collections that are more thread-safe than needed

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-464.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> ObjectRepositoryImpl uses collections that are more thread-safe than needed
> ---
>
> Key: ACE-464
> URL: https://issues.apache.org/jira/browse/ACE-464
> Project: ACE
>  Issue Type: Improvement
>  Components: Client Repository
>Reporter: Marcel Offermans
>Assignee: Marcel Offermans
> Fix For: next
>
>
> Specifically, it uses a CopyOnWriteArrayList and a ConcurrentHashMap, but 
> both are protected by a lock.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-331) Refactor the deployment repository to optionally limit the number of old versions of the repository

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-331.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Refactor the deployment repository to optionally limit the number of old 
> versions of the repository
> ---
>
> Key: ACE-331
> URL: https://issues.apache.org/jira/browse/ACE-331
> Project: ACE
>  Issue Type: Improvement
>  Components: Deployment
>Reporter: Marcel Offermans
>Assignee: Marcel Offermans
> Fix For: next
>
>
> Currently, we keep all versions of the deployment repository as a whole. 
> Since this can be a rather large repository, storing all versions can cost a 
> lot of disk space, and right now we never revert to older versions anyway. An 
> option to set a limited number of old versions to keep seems to make sense.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-457) Add a binary distribution for the relay server.

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-457.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Add a binary distribution for the relay server.
> ---
>
> Key: ACE-457
> URL: https://issues.apache.org/jira/browse/ACE-457
> Project: ACE
>  Issue Type: Bug
>  Components: Build
>Reporter: Marcel Offermans
>Assignee: Marcel Offermans
> Fix For: next
>
>
> Currently, in our workspace, we have a relay server project, but it is not 
> yet exported as a binary as part of our build.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-380) Make the management agent work with multiple URLs.

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-380.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Make the management agent work with multiple URLs.
> --
>
> Key: ACE-380
> URL: https://issues.apache.org/jira/browse/ACE-380
> Project: ACE
>  Issue Type: Improvement
>  Components: Discovery, Management Agent
>Reporter: Marcel Offermans
>Assignee: Marcel Offermans
> Fix For: next
>
>
> In ACE-379 multiple URLs are introduced. The management agent specifically 
> should support using those and contacting them using some simple algorithm 
> (ie: if the first is busy, go on to the next).



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-315) Analyze if we can make our template support more dynamic

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-315.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Analyze if we can make our template support more dynamic
> 
>
> Key: ACE-315
> URL: https://issues.apache.org/jira/browse/ACE-315
> Project: ACE
>  Issue Type: Question
>  Components: OBR
>Reporter: Marcel Offermans
>Assignee: Marcel Offermans
> Fix For: next
>
>
> Currently, we support configuration templates that get filled out with 
> properties that come from associated targets (and everything inbetween). Such 
> templates are now processed and files are written to the OBR for each 
> instance. Analyze if this could also be done "on the fly" by a servlet 
> instead as that would produce less artifacts in such an OBR.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-453) the artefact org.apache.ace.feedback.common is missed in the build/bnd.bnd (dependson)

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-453.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> the artefact org.apache.ace.feedback.common is missed in the build/bnd.bnd 
> (dependson)
> --
>
> Key: ACE-453
> URL: https://issues.apache.org/jira/browse/ACE-453
> Project: ACE
>  Issue Type: Bug
>Reporter: Wilfried Sibla
>Assignee: Marcel Offermans
> Fix For: next
>
>




--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-371) DeploymentRepository corrupt after bulk update through REST client

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-371.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> DeploymentRepository corrupt after bulk update through REST client
> --
>
> Key: ACE-371
> URL: https://issues.apache.org/jira/browse/ACE-371
> Project: ACE
>  Issue Type: Bug
>  Components: Repository
>Affects Versions: 1.0.0
>Reporter: Bram de Kruijff
>Assignee: Marcel Offermans
>Priority: Critical
> Fix For: next
>
>
> After doing a bulk update on a REST client workspace. The deployment 
> repository seems to be corrupted. There are a few strange things;
> 1) The initial run succeeds and my target gets a dp with version 1.0.0
> 2) After a second run, that deletes and recreated the artifacts, I get;
>  -> the target reports remote version "undefined", caused by the deployment 
> api reporting no versions. The server logs reports the stacks below;  
>  -> the webui does report an available that is very high. In my case it 
> increases by about 150 per run
> It seems that the underlying cause to getVersions being null is in 
> {code}
> 2013.07.11 21:15:57 WARNING - Bundle: org.apache.ace.deployment.servlet - 
> 500:Error getting available versions. - org.apache.felix.log.LogException: 
> org.apache.ace.deployment.servlet.AceRestException: 500:Error getting 
> available versions.
>   at 
> org.apache.ace.deployment.servlet.DeploymentServlet.getVersions(DeploymentServlet.java:234)
>   at 
> org.apache.ace.deployment.servlet.DeploymentServlet.doGet(DeploymentServlet.java:92)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
>   at 
> org.apache.ace.deployment.servlet.DeploymentServlet.service(DeploymentServlet.java:132)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
>   at 
> org.apache.felix.http.base.internal.handler.ServletHandler.doHandle(ServletHandler.java:96)
>   at 
> org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:79)
>   at 
> org.apache.felix.http.base.internal.dispatch.ServletPipeline.handle(ServletPipeline.java:42)
>   at 
> org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:49)
>   at 
> org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:33)
>   at 
> org.apache.felix.http.base.internal.dispatch.FilterPipeline.dispatch(FilterPipeline.java:48)
>   at 
> org.apache.felix.http.base.internal.dispatch.Dispatcher.dispatch(Dispatcher.java:39)
>   at 
> org.apache.felix.http.base.internal.DispatcherServlet.service(DispatcherServlet.java:67)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
>   at 
> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
>   at 
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:390)
>   at 
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
>   at 
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
>   at 
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
>   at org.mortbay.jetty.Server.handle(Server.java:326)
>   at 
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
>   at 
> org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:926)
>   at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
>   at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
>   at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
>   at 
> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
>   at 
> org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
> 2013.07.11 21:15:57 WARNING - Bundle: org.apache.ace.deployment.servlet - 
> Error getting available versions. - java.io.EOFException
>   at java.util.zip.GZIPInputStream.readUByte(GZIPInputStream.java:264)
>   at java.util.zip.GZIPInputStream.readUShort(GZIPInputStream.java:254)
>   at java.util.zip.GZIPInputStream.readHeader(GZIPInputStream.java:163)
>   at java.util.zip.GZIPInputStream.(GZIPInputStream.java:78)
>   at java.util.zip.GZIPInputStream.(GZIPInputStream.java:90)
>   at 
> org.apache.ace.deployment.provider.repositorybased.RepositoryBasedProvider.getRepositoryStream(RepositoryBasedProvider.java:419)
>   at 
> org.apache.ace.deployment.provider.repositorybased.RepositoryBasedProvider.getVersions(RepositoryBasedProvider.java:211)
>   at 
> org.apache.ace.deployment.servlet.DeploymentServlet.getVersions(DeploymentServl

[jira] [Closed] (ACE-137) Add distribution powered by Karaf

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-137.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Add distribution powered by Karaf
> -
>
> Key: ACE-137
> URL: https://issues.apache.org/jira/browse/ACE-137
> Project: ACE
>  Issue Type: New Feature
>Reporter: Jean-Baptiste Onofré
>Assignee: Marcel Offermans
>  Labels: karaf
> Fix For: next
>
>
> In order to provide a "easy to start" distribution, I propose to provide ACE 
> shipped into Karaf.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-386) Support range headers when providing deployment packages.

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-386.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Support range headers when providing deployment packages.
> -
>
> Key: ACE-386
> URL: https://issues.apache.org/jira/browse/ACE-386
> Project: ACE
>  Issue Type: Task
>  Components: Deployment
>Reporter: Marcel Offermans
>Assignee: Marcel Offermans
> Fix For: next
>
>
> When downloading deployment packages, we should report and respect range 
> headers. This is part of our support for "resuming" partially downloaded 
> deployment packages.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-465) Switch from Filter.match() to Filter.matchCase().

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-465.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Switch from Filter.match() to Filter.matchCase().
> -
>
> Key: ACE-465
> URL: https://issues.apache.org/jira/browse/ACE-465
> Project: ACE
>  Issue Type: Improvement
>  Components: Client Repository
>Reporter: Marcel Offermans
>Assignee: Marcel Offermans
> Fix For: next
>
>
> Throughout the client codebase a lot of OSGi filter expressions are used (to 
> associate different entities, and to look them up). These are currently all 
> matched based on the match() method in Filter, even though we internally have 
> properties that are case sensitive. Therefore, and because it is quicker, we 
> should switch to matchCase() instead.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-370) Using configuration templates fails

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-370.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Using configuration templates fails
> ---
>
> Key: ACE-370
> URL: https://issues.apache.org/jira/browse/ACE-370
> Project: ACE
>  Issue Type: Bug
>  Components: Client Repository
>Affects Versions: 1.0.0
>Reporter: Marcel Offermans
>Assignee: Marcel Offermans
> Fix For: next
>
>
> When you start using configuration templates, ACE keeps generating new 
> deployments. The cause seems to be that during the generation of new filled 
> out templates, these get uploaded and lost in the OBR. The effect is that 
> another update is triggered.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-203) Include default eclipse settings in svn

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-203.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Include default eclipse settings in svn
> ---
>
> Key: ACE-203
> URL: https://issues.apache.org/jira/browse/ACE-203
> Project: ACE
>  Issue Type: Improvement
>  Components: Build
>Reporter: Denis Koelewijn
>Assignee: Marcel Offermans
> Fix For: next
>
> Attachments: eclipse-cleanup-settings.xml, 
> eclipse-formatter-settings.xml
>
>
> Include default eclipse settings in the repository to simplify following the 
> formatting rules as described on the website.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-448) Continuous deployment does not handle fragments well

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-448.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Continuous deployment does not handle fragments well
> 
>
> Key: ACE-448
> URL: https://issues.apache.org/jira/browse/ACE-448
> Project: ACE
>  Issue Type: Bug
>Reporter: Bram de Kruijff
>Assignee: Marcel Offermans
> Fix For: next
>
>
> When creating a cd snapshot bundles continuous deployment does not consider 
> fragments because it only checks for resource type 'osgi-bundle'. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-114) Replace helper-user default ErrorHandler

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-114.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Replace helper-user default ErrorHandler
> 
>
> Key: ACE-114
> URL: https://issues.apache.org/jira/browse/ACE-114
> Project: ACE
>  Issue Type: Improvement
>  Components: Deployment
>Reporter: Dennis Geurts
>Assignee: Marcel Offermans
> Fix For: next
>
> Attachments: helper-user.patch
>
>
> This means for all artifacts that do not conform to XML, that this outputs 
> "[Fatal Error] :1:1: Content is not allowed in prolog." to standard out.
> I will attach a patch that resolves this issue



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-432) Agent DefaultController does not log deployment problems

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-432.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Agent DefaultController does not log deployment problems
> 
>
> Key: ACE-432
> URL: https://issues.apache.org/jira/browse/ACE-432
> Project: ACE
>  Issue Type: Bug
>  Components: Management Agent
>Reporter: Bram de Kruijff
>Assignee: Marcel Offermans
> Fix For: next
>
>
> When installation of a deployment package fails nothing is logged. In my case 
> a resource processor does not resolve (autoconf missing dependencymanager 
> packages) resulting in a DeploymentException. Then..
> 1) DeploymentHandlerImpl#install(...) catches DeploymentException and wraps 
> it in an InstallationException
> 2) DefaultController$StreamingUpdateInstaller#doInstallUpdate catches 
> exception silently.
> As a result no logging is done. Obviously the message from the 
> DeploymentException would be most informative. I think this also applies to 
> the DowloadUpdateInstaller..



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-376) Add support for recalculation jobs (on-demand, lazy or on-poll)

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-376.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Add support for recalculation jobs (on-demand, lazy or on-poll)
> ---
>
> Key: ACE-376
> URL: https://issues.apache.org/jira/browse/ACE-376
> Project: ACE
>  Issue Type: Task
>  Components: Client Repository
>Reporter: Marcel Offermans
>Assignee: Marcel Offermans
> Fix For: next
>
>
> Implement recalculation jobs for individual customers (or tenants). These 
> jobs should then be triggered either on-demand, lazily or on-poll (of the 
> target belonging to that customer). Requires ACE-374 to be done first.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-438) Ghosting in Artifacts column while scrolling

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-438.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Ghosting in Artifacts column while scrolling
> 
>
> Key: ACE-438
> URL: https://issues.apache.org/jira/browse/ACE-438
> Project: ACE
>  Issue Type: Bug
>  Components: UI
> Environment: Using chrome with a build of ace of revision 1543431
>Reporter: Jago de Vreede
>Assignee: Marcel Offermans
>Priority: Minor
> Fix For: next
>
> Attachments: ace ghosting - Broadband.m4v
>
>




--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-446) Home page menu does not work using https and chrome

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-446.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Home page menu does not work using https and chrome
> ---
>
> Key: ACE-446
> URL: https://issues.apache.org/jira/browse/ACE-446
> Project: ACE
>  Issue Type: Bug
> Environment: Google Chrome
> Mac OS X Mountain Lion
>Reporter: Petter Remen
>Assignee: Marcel Offermans
> Fix For: next
>
>
> The menus are broken using chrome on https://ace.apache.org/ . The javascript 
> console claims:
> [blocked] The page at https://ace.apache.org/ was loaded over HTTPS, but ran 
> insecure content from http://code.jquery.com/jquery.js : this content should 
> also be loaded over HTTPS.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-437) DeploymentServlet should never set Content-Length

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-437.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> DeploymentServlet should never set Content-Length
> -
>
> Key: ACE-437
> URL: https://issues.apache.org/jira/browse/ACE-437
> Project: ACE
>  Issue Type: Bug
>  Components: Deployment
>Reporter: J.W. Janssen
>Assignee: Marcel Offermans
> Fix For: next
>
>
> ACE-435 stated that the DeploymentServlet did not always send a 
> Content-Length header. After some discussion, we came to the conclusion that 
> the effort we need to go through to determine the Content-Length in all 
> situations is beyond reasonable with regards to the performance. 
> Therefore, we need to remove the fix made for ACE-435 and ensure that the 
> Content-Length is no longer send for deployment packages. We deliberately 
> deviate from the HTTP-spec (RFC 2616) a bit, but this is acceptable in this 
> situation as we're not providing a general purpose implementation anyway...



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-113) Replace helper-configuration default Errorhandler

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-113.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Replace helper-configuration default Errorhandler
> -
>
> Key: ACE-113
> URL: https://issues.apache.org/jira/browse/ACE-113
> Project: ACE
>  Issue Type: Improvement
>  Components: Deployment
>Affects Versions: 0.8.0-incubator
>Reporter: Dennis Geurts
>Assignee: Marcel Offermans
> Fix For: next
>
> Attachments: helper-config.patch
>
>
> This means for all artifacts that do not conform to XML, that this outputs 
> "[Fatal Error] :1:1: Content is not allowed in prolog." to standard out.
> I will attach a patch that resolves this issue



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-379) Extend the discovery service to support multiple URLs

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-379.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Extend the discovery service to support multiple URLs
> -
>
> Key: ACE-379
> URL: https://issues.apache.org/jira/browse/ACE-379
> Project: ACE
>  Issue Type: Improvement
>  Components: Discovery
>Reporter: Marcel Offermans
>Assignee: Marcel Offermans
> Fix For: next
>
>
> Our discovery service now supports a maximum of one URL. We should change 
> that so it can support multiple URLs that can be used. The list should be 
> ranked, with the most important one at the front (the one to "try first").



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-381) Truncate target logs in a configurable way.

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-381.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Truncate target logs in a configurable way.
> ---
>
> Key: ACE-381
> URL: https://issues.apache.org/jira/browse/ACE-381
> Project: ACE
>  Issue Type: Improvement
>  Components: Log, Management Agent
>Reporter: Marcel Offermans
>Assignee: Marcel Offermans
> Fix For: next
>
> Attachments: 0001-Fixed.patch, ACE-381.patch
>
>
> Target logs should be truncated to a fixed maximum size to prevent disk 
> storage from overflowing.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-348) Ace server unavailable after (re)start

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-348.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Ace server unavailable after (re)start
> --
>
> Key: ACE-348
> URL: https://issues.apache.org/jira/browse/ACE-348
> Project: ACE
>  Issue Type: Bug
> Environment: ace trunk / linux x64 / java version "1.7.0_17"
> Java(TM) SE Runtime Environment (build 1.7.0_17-b02)
> Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)
>Reporter: Bram de Kruijff
>Assignee: Marcel Offermans
> Fix For: next
>
>
> Every now and then the server is unavailable over http throwing a 503. It's a 
> timing issue and seems to be reported at 
> https://issues.apache.org/jira/browse/FELIX-3846 
> {code}
> HTTP ERROR 503
> Problem accessing /ace. Reason:
> java.lang.IllegalStateException: Can only register services while bundle 
> is active or activating.
> Caused by:
> javax.servlet.UnavailableException: java.lang.IllegalStateException: Can only 
> register services while bundle is active or activating.
>   at 
> org.mortbay.jetty.servlet.ServletHolder.makeUnavailable(ServletHolder.java:415)
>   at 
> org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:458)
>   at 
> org.mortbay.jetty.servlet.ServletHolder.doStart(ServletHolder.java:263)
>   at 
> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
>   at 
> org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:685)
>   at org.mortbay.jetty.servlet.Context.startContext(Context.java:140)
>   at 
> org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)
>   at 
> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
>   at 
> org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
>   at org.mortbay.jetty.Server.doStart(Server.java:224)
>   at 
> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
>   at 
> org.apache.felix.http.jetty.internal.JettyService.initializeJetty(JettyService.java:164)
>   at 
> org.apache.felix.http.jetty.internal.JettyService.startJetty(JettyService.java:115)
>   at 
> org.apache.felix.http.jetty.internal.JettyService.run(JettyService.java:290)
>   at java.lang.Thread.run(Thread.java:722)
> {code}
> Same problem reported in the log.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-413) DP download could not be resumed if download was complete but DP not installed

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-413.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> DP download could not be resumed if download was complete but DP not installed
> --
>
> Key: ACE-413
> URL: https://issues.apache.org/jira/browse/ACE-413
> Project: ACE
>  Issue Type: Bug
>  Components: Deployment
>Affects Versions: 1.0.0
>Reporter: Wilfried Sibla
>Assignee: Marcel Offermans
> Fix For: next
>
>
> If a DP could be downloaded compeletely but not installed (crash/restart of 
> containe etc.), it could not be continued with installing the DP.
> One reason: there is no check on startup if there already is a complete DB
> After asking the server for the new DP version and trying to complete the 
> download (of the DP which is already stored locally and complete), the server 
> returns a http error 416.
> http range header could not be set to the total length of the stream.
> see [http://stackoverflow.com/questions/3303029/http-range-header]



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-337) Cleanup outdated information on the wiki

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-337.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Cleanup outdated information on the wiki
> 
>
> Key: ACE-337
> URL: https://issues.apache.org/jira/browse/ACE-337
> Project: ACE
>  Issue Type: Bug
>  Components: Site
>Reporter: Marcel Offermans
>Assignee: Marcel Offermans
> Fix For: next
>
>
> Our wiki used to be the source for generating the website, but that is no 
> longer the case. It therefore now contains lots of pages that are outdated. 
> We should clean those up and only keep the stuff that is still relevant and 
> actually complements what's on the website.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Closed] (ACE-404) Error in Comparator for sorting artifact recognizer: services are not really sorted depending on their SERVICE_RANKING

2014-04-17 Thread Marcel Offermans (JIRA)

 [ 
https://issues.apache.org/jira/browse/ACE-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marcel Offermans closed ACE-404.


Resolution: Fixed

Closed all issues I just reopened and targeted for 'next' release.

> Error in Comparator for sorting artifact recognizer: services are not really 
> sorted depending on their SERVICE_RANKING
> --
>
> Key: ACE-404
> URL: https://issues.apache.org/jira/browse/ACE-404
> Project: ACE
>  Issue Type: Bug
>  Components: Client Repository
>Affects Versions: 1.0.0
>Reporter: Wilfried Sibla
>Assignee: Marcel Offermans
> Fix For: next
>
>
> ArtifactRepositoryImpl.SERVICE_RANK_COMPARATOR, line 542
> is: rank1 = (rankObject2 == null) ? 0 : ((Integer) rankObject2).intValue();
> must be: rank2 = (rankObject2 == null) ? 0 : ((Integer) 
> rankObject2).intValue();



--
This message was sent by Atlassian JIRA
(v6.2#6252)


  1   2   3   >