2009/10/19 Peter Gardfjäll <[email protected]>: > Thanks for the quick reply Guillaume! > > Regarding (1) I noticed that that kind of functionality is being > planned in the Apache Aries incubator project. > More specifically, it states that: > "...the Aries project will develop a model for assembling an > application/subsystem into a deployable unit, consisting of multiple > bundles, as an archive which may include metadata that describes the > version and external location of the application's constituent bundles > or which may contain the bundles directly." > Any idea of what the status is on that front?
Aries has just started and there has been no discussion so far around that. I exepect Karaf features and aries application support to somewhat merge at some point. Not sure how or when yet, but that would be my goal to make sure they align somehow. > Regarding (2): it sounds good with an extensible deployer architecture. > However, I guess care needs to be taken to prevent deployers from > stepping on each others toes. > For instance, ensuring that a deployer does not uninstall artifacts > owned/referenced by other deployers. > I guess I would need to look a bit closer on the design before > attempting a custom deployer. Custom deployers are all managed by fileinstall. The only real problem you could have is if you end up with having two custom deployers deployed in the framework, both being able to handle the same artifact. The behavior would be quite unpredictable. But each deployer defines a method to tell fileinstall if it's able to handle a given artifact, so you just need to make sure your logic is good enough. All interactions with the framework are done from fileinstall itself, so I don't really expect much problems here. > Regarding (4) and (5): would you recommend combining those approaches > or is it an "either or" decision what approach to use? I'm not really up to date with the eclipse plugin, so I can't really offer any advise here. > In any case, I sure will take a closer look at Karaf. > Once again, thanks for your prompt reply! > > best regards, Peter > > Guillaume Nodet > Mon, 19 Oct 2009 00:15:45 -0700 > > 2009/10/18 Peter Gardfjäll <[email protected]>: >> Hi, >> >> at the company I work, I am currently involved in a project where we are >> using a home-grown OSGi-based server on which we deploy our applications. >> In fact, it has quite a lot in common with Apache Karaf, which on a quick >> inspection, looks like a good deployment alternative considering what we >> already have. >> (Being able to use a stable, community-driven alternative seems more >> appealing than having to maintain our own framework). >> However, before starting to migrate our applications I would like to ask a >> few general questions about the framework. >> Any input would be greatly appreciated. >> >> (1) From what I understand, "features" are the main deployment unit for >> installing multi-bundle applications onto the Karaf runtime. >> Although it appears to be a highly flexible format, it introduces a >> level of indirection with the descriptor only containing references to the >> actual deployment artifacts. >> Do you have any plans of introducing other deployment formats, for >> instance a more "direct" format that contains the actual artifacts to be >> deployed? >> (I am thinking of something along the lines of the PAR format in the >> spring dm server.) >> For instance, in our home-grown server we have a zip deployer that >> expects a zip file containing the application bundles to be deployed. > > Yeah, that would make sense. We haven't discussed that yet, but maybe > a zip file containing the feature descriptor in some META-INF or > OSGI-INF folder along with an inlined repository (maybe using the > maven layout) sounds like a good idea to distribute a stand alone > application. > >> (2) How extensible is the deployment architecture of Karaf? >> Does it allow custom deployers to be hooked in to support other >> deployment formats? >> Would it be a complex task to introduce additional deployers? > > We already have custom deployers. This has not been really documented > yet, but we use those for deploying blueprint applications, spring > applications and features. We plan on adding WAR deployment support > (currently provided by ServiceMix along with a JBI deployer). > You'll see a custom deployer at the following location: > https://svn.apache.org/repos/asf/felix/trunk/karaf/deployer/blueprint/ > You basically need to register a service in the OSGi registry such as > the following one: > > https://svn.apache.org/repos/asf/felix/trunk/karaf/deployer/blueprint/src/main/java/org/apache/felix/karaf/deployer/blueprint/BlueprintDeploymentListener.java > >> (3) Are there any plans on providing some sort of in-container testing >> framework (or maybe one already exists)? >> I'm imagining some kind of simple testing infrastructure, such as an >> (abstract?) base TestCase class that launches a bare-bones Karaf runtime >> with the possibility for concrete TestCases to add >> features/bundles/configurations? I believe that such an integration test >> framework could be really useful. > > We currently use pax-exam and we may want to provide a bit more around that. > >> (4) What is the preferred way of writing and launching applications for the >> Karaf platform? >> (I see that the user's guide contains a placeholder chapter for this >> type of information but I was hoping that someone could give a brief >> summary!) > > The concept of features would be the best we have for that I think. > IIRC, the user's guide page you're referring to was supposed to > explain how to create a custom feature descriptor and use it to deploy > an application. > >> (5) Are there any plans around Karaf development tools, such as Eclipse >> plug-ins similar to those of spring dm server, that would allow a Karaf >> server runtime to be defined and workspace bundles to be hot deployed? > > There's one Eclipse plugin you may want to try: > http://fusesource.com/forge/projects/EIK > >> Okay, that's all for now. >> >> best regards, Peter >> > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
