Mailing-List: contact dev-help@brooklyn.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@brooklyn.incubator.apache.org
MIME-Version: 1.0
Date: Mon, 31 Aug 2015 10:59:17 +0100
Message-ID: 
 <CANmZWAQYPTPTwDrcqUeZ8DNXBWOUqsqH_yFYtrd4g5Quf5JtyQ@mail.gmail.com>
Subject: Servicemix Brooklyn
From: Richard Davidson <richard.davidson.uk@gmail.com>
To: dev@brooklyn.incubator.apache.org
Content-Type: multipart/alternative; boundary=001a113678108ffb27051e987c36

--001a113678108ffb27051e987c36
Content-Type: text/plain; charset=UTF-8

Hi All,

I am new to Brooklyn so would appreciate you feedback on the proposal below.

Servicemix is an integration platform based on Apache Karaf. At a high
level it consists of:

- Apache CXF

- Apache Karaf,

- Apache ActiveMQ

- Apache Camel.

The value of Servicemix over standard Karaf is that it pre integrates and
tests all these components work together.


I think it would be useful to have a Servicemix entity for Brooklyn. Below
is my proposal, but I am very new to Brooklyn so please comment:


1. Servicemix is an OSGi container so I was thinking of using the package
name  org.apache.brooklyn.entity.osgi.servicemix.

2. As Servicemix is an extension of Karaf, I am thinking of extending the
Java files under *org.apache.brooklyn.entity.osgi.karaf.* This will provide
a lot of the functionality required.

3. I will provide a few new properties to the Karaf entity. Servicemix will
also inherit these properties.

 - *bootFeatures *- List if features to install on startup of the container.

 - *bootRepositories* - List of repositories to install on startup of the
container.

 -* hotDeployArtifacts* - List of URLs to deploy into the hot deploy
directory. This is very useful to deploy artefacts such as Camel routes
quickly. We could have a simple camel XML file in Github, and point Brooklyn
at it. On startup it would be downloaded and placed into the deploy
directory within Servicemix / Karaf:

4. We should also add a property for *javaOpts*. This will allow the JVM
settings such heap size and GC settings to be customised.

5. It would be useful to have a way to configure OSGi PIDs via Brooklyn.
PIDs are Java properties namespaced by a PID name. The best structure to
represent this is Map<String, Map<String,String>.  Is Brooklyn able to
handle receiving a sensor datatype like the example below?:

public static final BasicAttributeSensorAndConfigKey<Map<String,
Map<String,String>> PID_CONFIG = new
BasicAttributeSensorAndConfigKey<String>(<Map<String, Map<String,String>>,
"pidConfig");

If people are happy with the approach and it is something you would like to
have in Brooklyn, I will start to work through it and submit a pull request.

Thanks,

Richard

--001a113678108ffb27051e987c36--