On Mon, Nov 18, 2013 at 1:12 PM, Achim Nierbeck <[email protected]> wrote: > It's very funny to see this advertisements for Fuse Fabric and Hawt.IO > again. >
It was not intended as an advertisement. Its referring to a project that already does what the user mentions he wants to build on his own. The user mentioned developing a Karaf based provision agent. Which Fuse Fabric is. And he mentions Fuse ESB which comes out of the box included with Fuse Fabric; and hawtio in the upcoming JBoss Fuse 6.1 release. > As this is the Apache Karaf mailing-list I would expect solutions for > working with Apache Karaf. Fuse Fabric *works with Karaf*. In fact it currently only runs on top of Karaf. Though there is work in process to make Fuse Fabric run on other containers such as Apache Tomcat, JBoss WildFly, and any other widespread in use containers (OSGi and non-OSGi); giving end users more choices; as not everyone can use Karaf based containers. > If those things are so great, why don't you donate it back to Apache Karaf? Well in fact Fuse Fabric is in the process of being donated to ASF. Layers is involved and they are taking their time - in fact they are taking very long time. Until they give the go ahead, all we can do is wait. > This way we're back to one community. > Apache is not about everything must be a ASF project. For example Apache Karaf is using a number of projects outside ASF in its distribution. - osgi - eclipse equionox (if you switch from felix) - eclipse jetty - ops4j - asm - jline - service wrappers - spring ??? So should all these projects be donated to ASF? Fabric is in fact optional you can run on top of Karaf. But most of these projects mentioned above, is mandatory to run Karaf. And they are not ASF projects. > just my 0.02€ > > regards, Achim > > > 2013/11/18 Claus Ibsen <[email protected]> >> >> Hi >> >> You may want to take a look at Fuse Fabric >> https://github.com/jboss-fuse/fuse >> http://fuse.fusesource.org/fabric/ >> >> Fuse Fabric : a provisioning, configuration and management solution >> for Apache Karaf, Apache ServiceMix and Fuse >> >> Fabric has the concept of profiles that allows you to describe/define >> what container(s) should be running. Then you can do rolling >> upgrades/downgrades of profiles on the containers. >> >> And you can have a git store so all the profiles is stored persistent >> and you have all the power of git, so you can look in the git commit >> logs for when/who did what, and versioning etc. >> >> On the containers a Fabric Agent is running to handle the provisioning >> and whatnot. >> >> Fuse Fabric comes out of the box in JBoss Fuse - >> http://www.jboss.org/products/fuse. >> And you have Fabric commands in the Karaf shell, and for web UI you >> have hawtio - http://hawt.io/ >> >> >> >> On Fri, Nov 15, 2013 at 5:36 PM, Steve <[email protected]> wrote: >> > Hello Karaf users, >> > >> > I’m in the process of developing a provisioning agent for a >> > Karaf-based ESB (Fuse ESB/ServiceMix). Currently I’m using Features >> > exclusively as my unit of deployment as opposed to working directly >> > with individual bundles when provisioning. The Features mechanism is >> > quite nice and has been pleasant to work with programmatically via the >> > FeaturesService interface. In the course of developing this agent >> > though I’ve come up with a few questions, mostly related to >> > best-practices. I haven’t found answers in existing documentation; if >> > such information does exist, you have my apologies in advance for >> > troubling the mailing-list with something already answered elsewhere. >> > With that being said, here are my questions: >> > >> > >> > >> > 1.) A container has a Feature installed, “example-app”, at version >> > 1.0. Now let’s say I decide I want to run version 1.1 at some point >> > down the road. Would the best practice be to first uninstall the >> > Feature at version 1.0 and then install version 1.1, or to just >> > install version 1.1 directly (skipping the explicit uninstall step)? >> > Currently I use the FeaturesService programmatically to uninstall the >> > old version prior to install the new. While this seems to work fine, >> > I thought it wise to inquire if there was an existing best practice >> > around this or, perhaps, potential pitfalls to be avoided. >> > >> > >> > >> > 2.) The provisioning agent itself is installed as part of a Feature. >> > I currently let the agent install a new version of its encapsulating >> > Feature. With other Features not associated with the agent, as I >> > mentioned in question #1, I explicitly uninstall the old version prior >> > to installing the new. For the agent I don’t do this to prevent a >> > “bundle-suicide” type of situation. When the agent installs a new >> > version of its encapsulating Feature this triggers an implicit >> > framework restart after which the new version is installed and the >> > older version uninstalled. Interestingly enough, if I try to go the >> > other direction, say from 1.1 back to 1.0, I get unfulfilled >> > dependencies that prevent the older version of the Feature from >> > installing (and both features end up uninstalled). The dependency in >> > question (commons-lang 3.x) is actually embedded in both version 1.0 >> > and 1.1 of the bundle containing the application (both bundles are >> > identical except in version number for testing). I suspect the old >> > version is attempting to import packages from the new version’s >> > bundle, but fails to do so because the latter is then invalid. Should >> > I allow my agent to install a new version of its encapsulating Feature >> > or is this going down the wrong road? Is there a best practice (or >> > any advice) around a Feature self-update scenario? >> > >> > >> > I will greatly appreciate any information/advice that can be given >> > (even “RTFM” if you can point me to the right manual). >> > >> > >> > Thanks! >> > >> > -Steve >> >> >> >> -- >> Claus Ibsen >> ----------------- >> Red Hat, Inc. >> Email: [email protected] >> Twitter: davsclaus >> Blog: http://davsclaus.com >> Author of Camel in Action: http://www.manning.com/ibsen > > > > > -- > > Apache Karaf <http://karaf.apache.org/> Committer & PMC > OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & > Project Lead > OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> > Commiter & Project Lead > blog <http://notizblog.nierbeck.de/> -- Claus Ibsen ----------------- Red Hat, Inc. Email: [email protected] Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen
