karaf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: Best practise for deploying my app with Karaf
Date Tue, 23 Oct 2012 11:39:25 GMT
Just an update, about "dependencies": if the bundle is flagged with 
dependency=true in the features XML, the kar deployer can use an already 
installed bundle.

A Maven repository manager (like Archiva) is a good approach, but a 
simple Maven structure in a directory (that you populated with mvn 
deploy:deploy-file for instance) works as well.


On 10/23/2012 01:09 PM, Christian Schneider wrote:
> When you install a kar file it is added as an additional repository for
> karaf and the features are started.
> So there is not much difference between a kar file and a company maven
> repo when looking at how the application starts up.
> The only downside to a kar file is if you have several applications with
> shared dependencies. As you typically pack all dependencies into the kar
> file you would
> have a lot of duplication. As long as you only deploy one application it
> should be no issue.
> A feature is the right way to define an application in karaf. It is not
> only for karaf extensions.
> If you have the option you should still consider to setup a maven
> repository manager and deploy from there. I think it is a great way to
> connect your development process which ends in the maven repo to the
> deployment which starts there.
> About having a second container where you do the upgrades and then
> switch. I think this is exactly the way to go for mission critical
> applications.
> Christian
> On 10/23/2012 12:46 PM, PJR69 wrote:
>> I'm working on an application that has roughly 6-8 OSGi-bundles
>> written by
>> us. Then we have around 40-50 OSGi-bundles as dependencies from our
>> bundles.
>> Our application environment will be internal network with no internet
>> access. The Karaf-instances hosting the application will be running in
>> quite
>> restricted virtual machines that access database(s) and offer
>> JMS/RMI/SOAP-endpoints for the clients. I don't think we will be able to
>> setup any maven repositories.
>> We do need to update the application from time to time and the
>> application
>> is pretty mission critical, needs to be running with 99.999+
>> availability.
>> Currently I'm thinking that to update the application we would use
>> parallel
>> Karaf-instances. Something like "APPv1" as the initial child instance;
>> and
>> if we need to make some update/fix, we would create a new instance, like
>> "APPv2" and then deploy all the new stuff there, bring it into production
>> (with different endpoint addresses so it can co-exist for a short
>> while with
>> the APPv1) and then change all clients to use the new version and then
>> shutdown and destroy the old version.
>> So, what would be the best practise to deploy this application?
>> My thoughts:
>> - The quick'n'dirty way would be to just copy all jar-files to the
>> Deploy-folder of Karaf. This doesn't feel very manageable wrt
>> versioning and
>> packaging. We need to be very exact wrt versions. Prolly works ok for
>> development.
>> - Create a KAR-file and make one "feature" of the application and include
>> all dependencies inside the KAR-file.
>> - Create a single jar-file and embed all dependencies into it.
>> Currently the KAR-file feels like a way to go. But how about the
>> concept of
>> "feature", it feels like some "extension" into Karaf and not really an
>> "application". But is it just semantics; would a feature from a
>> KAR-file be
>> as "real" of an application as any other application deployed as plain
>> jar-files? Would our app lose any services/functionality of Karaf/OSGi
>> if it
>> would be deployed as a "feature" from KAR-file?
>> All comments/ideas are highly appreciated.
>> --
>> View this message in context:
>> http://karaf.922171.n3.nabble.com/Best-practise-for-deploying-my-app-with-Karaf-tp4026544.html
>> Sent from the Karaf - User mailing list archive at Nabble.com.

Jean-Baptiste Onofré
Talend - http://www.talend.com

View raw message