(comments inline below...) Jeremias Maerki
On 07.05.2012 11:38:43 Christian Schneider wrote: > I really like your setup it looks quite lean. It is very different from > how karaf works though. > So I am not sure how easy it would be to karaf open enough to also > support that style. Having boot time plugins could be interesting. > We already have the karaf activator that could be used for this. Perhaps > that could be a basis for achieving such an open setup. > > I have some questions about your setup: > > - We use maven as a repository of binary artifacts (bundles, simple > jars). What do you use for this purpose? Basically bundles in a shallow directory structure. I used to experiment with Apache ACE. Quite nice for production environments but during development it wasn't easy enough to achieve quick turn-arounds when re-deploying bundles in my development instance (or instances when I work on cluster functionality). So I ended up implementing a rather simple system: a servlet that observes a local directory. Each subdirectory represents a "profile" with n bundles. Special zero-length "import-profile.*" files let me include other profiles. Via distributed events (event admin over Hazelcast) I can make all instances sync with that repository. So, whenever I build a bundle it gets copied to one of the profile directories and is distributed to every node in the cluster within a couple of seconds. So, more or less ACE-very-light without manual steps. Basically, the client part of this is my management agent that I deploy via initial provisioning. I can also leverage FileInstall's ArtifactListeners to deploy configs, for example. One reason for this rather simplistic approach was that I want to have close control over the set of bundles that I want to deploy on the system. Essentially, I try to avoid the topic of transitive dependencies like this which is one thing I dislike about Maven (there's good and bad in everything). Since I'm building a document production system that might one day become open source with an Apache-compatible license policy, I want full control over what goes into the system. I guess in the long-term I might also want to go towards OBR. It should be easy to enhance the servlet so it produces OBR metadata from the bundles in its repository. > - While I see that your setup should work nicely it sure was a lot of > effort to create. Why did you choose to do so instead of simply using > plain karaf? Yes, it was quite a bit. But I had invested quite a lot of time already to try to make Ace do what I was looking for, but my requirements just didn't fit. I think Ace is great from the integration step on up to production, but I wanted something that gives me full control and that would work efficiently from my development environment up to production. Well, that's the deployment part... ...and for the container part: I guess it was several little things that let me do that: - I wasn't happy with the Maven directory outline in "system" and with startup.properties. - Another thing I didn't like was the embedding of the OSGi API in karaf.jar. That disallows running on the latest Felix. - I don't need the failover setup. I rather solve that with a cluster or hot stand-by. - The distinction between karaf.base and karaf.home is not clear enough to me. - I wanted to split karaf.data into a data (/var/local) and a log (/var/log) location. That would have been relatively easy to propose to Karaf, I know. After all, I was the one to suggest the karaf.data property. But that point was mostly an after-thought after already having started with my container. That's what I remember just now. I'm pretty sure I've had another point. > - What are the main features of karaf that make you use it compared to > plain felix? The maven support can not be it :-) - standardized properties for file locations (home, data, etc.) - the approach with properties files and property substitution - the shell and many commands (although I still write my own commands with plain RFC 132) - SSH console - Blueprint deployer I guess features are nice for experiments and demos, but I remember having troubles in the past so I didn't use them. I've never revisited that decision through new tests. I've not always been able to follow every development in Karaf. I noticed Cellar quite (too) late, for example. I had already implemented similar things. Generally, I still run into strange effects every now and then. Some third-party that was not really written for OSGi not behaving ideally, producing class loader issues or whatever. Keeping tight control over deployment allows me to counteract this to a degree. I sometimes wonder if I'm the only one running into so many little problems with various bundles. I love OSGi but sometimes I find it difficult to create a complex system where all components play nice from startup to shutdown. I often find myself up- or downgrading a particular bundle (and its dependencies) to work around a problem. > Genrally I am not a big fan of completely open systems as they fragment > the user deployments. If you mainly make your platform open then every > user will use it differently. I understand that completely. It also makes it more complex for newbies. I do think it's good that Karaf recommends a widely accepted best practice with the default installation. The "newbie kickstart" (unpack, drop a bundle in "deploy" and go) is one of the great things about Karaf. It's much easier to get OSGi newbies started on Karaf than with plain framework. But maybe it can get a bit more open for the advanced user. > That is not so good in relation to forming a community. So I am more a > fan of choosing a good path and using it (a bit like gnome vs kde or mac > vs linux). Of course in some areas modularity is really good but you > have to be careful. Agreed. But one size doesn't fit all. I like Ace but it's not for me. I "spent/wasted" a lot of time building basic components of my own. I'm pathologic in that area. I even wrote my Bnd alternative for Ant. How crazy is that? ;-) But it turned out that it was really easier (and faster) sometimes to build something that was tailored to my expectations that to beat something else into submission. Surely not in every case. > Christian > > Am 07.05.2012 10:17, schrieb Jeremias Maerki: > > (hooking into a random point in this thread, mostly agreeing with > > Guillaume and David) > > > > I'd like to offer my view on the topic. I've recently started moving > > away from the Karaf bootstrapper (still using many Karaf bundles, > > though). I ended up writing my own bootstrapper because I thought the > > current one does too much and imposes certain decisions. > > > > Here's where I am now: > > - "lib" directory for the bootstrapper (18KB) + framework(s) and service > > adapters (Commons Deamon, Wrapper etc., in the future to be implemented > > as plug-ins using META-INF/services like with the framework). > > - "lib/endorsed" directory: not nice but unfortunately I can't seem to > > do without, yet. > > - "bundles" directory for startup bundles. Can optionally have > > subdirectories with the start-level as name, ex. "bundles/10" for > > start-level 10. (No startup.properties) (Even this could be a "bootstrap" > > plug-in so others can implement their own choice of initial bundle > > provisioning.) > > - "etc" directory: minimally only contains a system.properties, > > framework.properties and jre.properties. > > > > In the production deployment, the installation really just contains a > > minimal set of 3 bundles (compendium, my initial provisioning > > implementation bundle and config admin). Initial provisioning fetches > > the management agent from a central place and invokes that to actually > > deploy the application. > > > > That allows me to put minimal configuration on each server and reduce > > the frequency in which the bootstrapper has to be upgraded. All the rest > > is fetched from a central deployment server. > > > > In my development environment, fileinstall and many other bundles are > > put in the "bundles" directory so I get a "Karaf-like" setup, skipping > > the actual deployment server (actually the local instance serves as that). > > > > I don't work with Maven, so I don't personally like that dependency, > > even it's just the directory layout in the "system" directory. The > > startup.properties doesn't even need to be kept in sync with that > > directory. > > > > Since I'm seeing multiple desires in this thread, why not make the > > container/bootstrapper much more modular and give the power to the users > > to choose their favorite setup? Karaf already offers a ton of very > > useful bundles that can but don't need to be used. You could extend that > > approach to the bootstrapper. > > > > Just my 0.05 CHF. > > > > HTH > > Jeremias Maerki > > > > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > Talend Application Integration Division http://www.talend.com
