ace-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pepijn Noltes <>
Subject Re: [feedback] hurdles when working with ACE
Date Mon, 25 Jan 2016 20:32:02 GMT
Hi All,

First of all I agree with Daan issue. I have also several
improvement/issues myself.

A bit of background. My use case for Apache ACE is a distributed
polyglot (Apache Felix / Apache Celix) system where the goal is
dynamic (runtime) reconfiguration of the software.
One of the project we used Apache ACE in is INAETICS
( I worked in this project – among others –
together with Jan Willlem.

My issues/improvements:

- Simpler setup out of the box.

The server-allinone contains a lot of feature I personally do not
use/need. This makes jumping into Apache ACE difficult.
For example - also mentioned by Daan - the need to approve targets is
not needed our current use case, but we have to work around this.
An other item is the four levels (artifacts, features, distributions
targets) as I understand this is adaptable, but out of the box there
are four.

Maybe different server configuration for different use case can be created.

- Support docker
Make it possible to "deploy" docker images using Apache ACE. Docker is
becoming more popular by the day and in my opinion rightly so.
Provisioning docker images in a more controlled manner is IMO still

Although using Apache ACE to runtime deploy sets of bundles can be
very flexible and powerful in my experience sometimes a pre-created
OSGi docker image is preferable.
This minimizes the "entropy" of the system by introducing composed
OSGi bundles used in a (more) deterministic manner. Although
theoretically continuously deploying/undeploying bundles on a OSGi
container should work, in practice this can lead to issues (note that
should be considered bugs, but still). Also pre-created docker images
can be tested as-is and therefore be qualified as whole.

A combination would be interesting, so default bundles and the
possibility to use Apache ACE to update default bundles / sprinkle on
additional bundles.

Provide A minimal OSGi client containing the ACE agent and make this
images easy extendable by adding additional bundles / configuration
files. (See INAETICS (github) for a minimal OSGi client example).

Focus on making development of cluster / distributed systems more easy
without restarting the cluster. So updated bundles / docker images and
restarting ACE client should be possible and easy.

– Use the capability-requirement model resolving

I would prefer using the capability requirement model to match what to
deploy instead of coupling artifact2feature, etc. Although this could
maybe be to complex, I think it's worth thinking about.

Especially combining this with docker images (e.g. using docker labels
to add Provide-Capability / Require-Capability ) could be a
interesting feature. This could help in solving a problem where OSGi
is very good at, running mircroservices with multiple versions of
services. But in this case mircoservices means REST services provided
by docker containers.

– Runtime configuration
When using Apache ACE I often ran in the desire the edit/update the
configuration file used. A more “inline” support to updating (e.g.
enable debug printing) small configuration files would be nice.

- Monitor targets
Maybe out of scope for Apache ACE, but also something I noticed would
be very welcome when using Apache ACE, is a more elaborate monitoring
of the targets. Maybe even something like a heartbeat to ensure the
target is alive.

- No gosh
I understand that gosh is very powerful, but I see it as yet another
scripting language I prefer not to learn. I would prefer a more
feature rich / responsive HTML UI and better supported REST api.

Well these are just my 2 cents.


On Mon, Jan 25, 2016 at 4:04 PM, Daan Veldhof <> wrote:
> Hi Jan,
> I haven't worked with Ace for that long, but I hope I can add some
> feedback, especially from the Celix side.
> - The first challenge i've encountered was that I couldn't upload .zip
> files. I know there is a way to create your own resource processor, but it
> was easier for me to convert the .zip to .jar.
> - The second challenge was to create targets for celix. We've got celix
> working for Android devices, but they need different bundles because most
> Android devices contain an ARM processor. The solution for us was to create
> multiple targets with their cpu architecture in their id (i.e.
> celix_armeabi-v7a or celix_armeabi). I would like to see something were you
> could specify the id and in the tags you would specify the cpu
> architecture. So if you have a normal linux machine it would register
> itself to ace with {id:celix, cpu_arch: linux-x86} and a android device
> would register with {id:celix, cpu_arch:armeabi-v7a}
> - The third challenge was to use the REST api. There was some documentation
> but it wasn't enough. I looked like someone started with it, but didn't
> finish it. Eventually through the mailing-list I got it up and running.
> - The last thing i've encountered was that the automation bundle wasn't
> working properly. If a new target was added it wouldn't be registered and
> approved. You had to log in and retrieve and store a workspace before it
> would be registered and approved.
> Regards,
> Daan Veldhof
> 2016-01-22 15:48 GMT+01:00 Jan Willem Janssen <>
> :
>> Hi community,
>> It has been very quiet the past couple of months on the development of
>> ACE. I
>> am currently busy with picking up the last issues we need to resolve in
>> order
>> to prepare a new release of ACE (which is long overdue already).
>> After the release, we’d like to start working on improving ACE again. We
>> know
>> that ACE has several white spots that might impact its use for your use
>> cases.
>> Therefore, I’d love to hear your feedback on ACE: issues, abeyance's and
>> hurdles you’ve come across and you like to see improved. Other ideas on
>> what
>> can be improved are welcome as well :)
>> Thanks in advance,
>> (cross posting to the dev@ list as well).
>> --
>> Met vriendelijke groeten | Kind regards
>> Jan Willem Janssen | Software Architect
>> +31 631 765 814
>> My world is something with Amdatu and Apache
>> Luminis Technologies
>> Churchillplein 1
>> 7314 BZ  Apeldoorn
>> +31 88 586 46 00
>> KvK (CoC) 09 16 28 93
>> BTW (VAT) NL8170.94.441.B.01

View raw message