Hi Richard- ServiceMix would be a great addition. Some of the people in the community might be more familiar with it than I am (Hadrian?) but I can answer the Brooklyn questions.
1- yes 2- yes, assuming it is a customized karaf process which is started; the other option to consider would be to make the karaf node a child of the servicemix entity, which I'd do if there are multiple software processes started to run service mix (so they can be controlled and monitored independently). 3- yes; btw if any of these belong in karaf feel free to add them in that superclass instead 4- this is already present by virtue of KarafContainer implemented UsesJava and using the JavaSoftwareProcessSshDriver 5- maps of maps are fine; note you can use guava's TypeToken to get the generics just right Also you might be interested in some work done on Mule [1]; it might give you some ideas, or vice versa. Any other questions let us know. Best Alex [1] http://www.ricston.com/blog/mule-brooklyn/ On 31 August 2015 at 10:59, Richard Davidson <[email protected]> wrote: > 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 > -- Cloudsoft Corporation Limited, Registered in Scotland No: SC349230. Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. Cloudsoft Corporation Limited does not accept responsibility for changes made to this message after it was sent. Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by Cloudsoft Corporation Limited in this regard and the recipient should carry out such virus and other checks as it considers appropriate.
