Re: Karaf-4.0.7 bundle:watch issue

2016-11-22 Thread Jean-Baptiste Onofré 

Hi Erwin,

I guess your SNAPSHOT is on a remote repo. For now, watch just works 
with SNAPSHOT updated in your local .m2/repository.


Regards
JB

On 11/23/2016 12:13 AM, Erwin Hogeweg wrote:

Hi,

Is there a reason why bundle:watch won’t work in the following scenario?

- Install and start SNAPSHOT bundle from maven.
- execute bundle:'watch —start '
- rebuild bundle with ‘clean install’

Expect bundle to be updated, but nothing happens… (Executing 'update ' 
does load the new version….)

I changed the watch interval to 1 second thinking that maybe I was too 
impatient… to no avail. I vaguely remember some msgs here re. bundle:watch, but 
I couldn’t find them anymore. I also didn’t see any open issues in Jira. So I 
am a tad confused now. Can’t imagine this isn’t working, so I must be missing 
something very obvious.

Any insight is greatly appreciated.


Erwin



--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Karaf-4.0.7 bundle:watch issue

2016-11-22 Thread Erwin Hogeweg 
Hi,

Is there a reason why bundle:watch won’t work in the following scenario?

- Install and start SNAPSHOT bundle from maven.
- execute bundle:'watch —start '
- rebuild bundle with ‘clean install’

Expect bundle to be updated, but nothing happens… (Executing 'update ' 
does load the new version….)

I changed the watch interval to 1 second thinking that maybe I was too 
impatient… to no avail. I vaguely remember some msgs here re. bundle:watch, but 
I couldn’t find them anymore. I also didn’t see any open issues in Jira. So I 
am a tad confused now. Can’t imagine this isn’t working, so I must be missing 
something very obvious.

Any insight is greatly appreciated.


Erwin

Karaf 4.0.7 problem with endorsed Xalan

2016-11-22 Thread Stefan Mlynarik 
Hi all,

I create small bundle with camel(2.18.0), that apply XLST for files in
folder, with this route
from("file:/tmp/xslt-test")
.routeId("XSLT_ROUTE")
.to("xslt:test/osgi/xslt/example.xsl?output=file")
.to("file:/tmp/xslt-test/out");

when I deploy and start bundle it throws Exception when try transform file

javax.xml.transform.TransformerFactoryConfigurationError: Provider
org.apache.xalan.processor.TransformerFactoryImpl not found
at
javax.xml.transform.TransformerFactory.newInstance(TransformerFactory.java:121)[:2.7.0]
at
org.apache.camel.converter.jaxp.XmlConverter.createTransformerFactory(XmlConverter.java:1155)

I thought that endorsed libraries are added to bundle classpath if specified
in etc/config.xml org.osgi.framework.system.packages.extra

Do I need to specify something in MANIFEST.MF or modify karaf configuration?

Thanks Stefan




--
View this message in context: 
http://karaf.922171.n3.nabble.com/Karaf-4-0-7-problem-with-endorsed-Xalan-tp4048776.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: InvalidAlgorithmParameterException SSHD

2016-11-22 Thread Zoran Regvart 
Hi Vikram,
there was a discussion about this not too long ago, see if this helps:

http://karaf.922171.n3.nabble.com/ssh-ssh-fails-on-karaf-4-0-7-td4048558.html

zoran
-- 
Zoran Regvart

Re: InvalidAlgorithmParameterException SSHD

2016-11-22 Thread Jean-Baptiste Onofré 

Hi,

what's the size of your key ?

Regards
JB

On 11/22/2016 03:51 PM, Vikram Darsi wrote:

Hi Karaf Team


We are using Apache-Karaf 3.0.7 (Apache SSHD Core 0.14.0 + Apache Mina
Core 2.0.9 + JDK 1.8 update 45) and still experiencing below issue
during key exchange between SSH Client and SSH Server. the same piece of
code is working fine on Apache Karaf 3.0.3 (Apache SSHD Core 0.12.0 +
Apache Mina Core 2.0.7 + JDK 1.8 update 45 )

Below is the info:
Karaf
  Karaf version   3.0.7
  OSGi Framework  org.eclipse.osgi - 3.8.2.v20130124-134944
JVM
  Java Virtual MachineJava HotSpot(TM) 64-Bit Server VM version
25.45-b02
  Version 1.8.0_45
  Vendor  Oracle Corporation
Operating system
  NameLinux version 2.6.32-642.6.1.el6.x86_64
  Architectureamd64
  Processors  1

java.security.InvalidAlgorithmParameterException: Prime size must be
multiple of 64, and can only range from 512 to 2048 (inclusive)

  at
com.sun.crypto.provider.DHKeyPairGenerator.initialize(DHKeyPairGenerator.java:120)[sunjce_provider.jar:1.8.0_51]

  at
java.security.KeyPairGenerator$Delegate.initialize(KeyPairGenerator.java:674)[:1.8.0_45]

  at
java.security.KeyPairGenerator.initialize(KeyPairGenerator.java:411)[:1.8.0_45]

  at
org.apache.sshd.common.kex.DH.getE(DH.java:65)[31:org.apache.sshd.core:0.14.0]

  at
org.apache.sshd.client.kex.DHGEX.next(DHGEX.java:118)[31:org.apache.sshd.core:0.14.0]

  at
org.apache.sshd.common.session.AbstractSession.doHandleMessage(AbstractSession.java:425)[31:org.apache.sshd.core:0.14.0]

  at
org.apache.sshd.common.session.AbstractSession.handleMessage(AbstractSession.java:326)[31:org.apache.sshd.core:0.14.0]

  at
org.apache.sshd.client.session.ClientSessionImpl.handleMessage(ClientSessionImpl.java:306)[31:org.apache.sshd.core:0.14.0]

  at
org.apache.sshd.common.session.AbstractSession.decode(AbstractSession.java:780)[31:org.apache.sshd.core:0.14.0]

  at
org.apache.sshd.common.session.AbstractSession.messageReceived(AbstractSession.java:308)[31:org.apache.sshd.core:0.14.0]

  at
com.adva.ensemble.controller.callhome.impl.ReversedAsyncSshHandler$MyAsyncSshHandlerReader.operationComplete(ReversedAsyncSshHandler.java:138)[286:com.adva.ensemble.controller.callhome-config-dispatcher:17.1.1.1]

  at
com.adva.ensemble.controller.callhome.impl.ReversedAsyncSshHandler$MyAsyncSshHandlerReader.operationComplete(ReversedAsyncSshHandler.java:111)[286:com.adva.ensemble.controller.callhome-config-dispatcher:17.1.1.1]

  at
org.apache.mina.core.future.DefaultIoFuture.notifyListener(DefaultIoFuture.java:375)[30:org.apache.mina.core:2.0.9]

  at
org.apache.mina.core.future.DefaultIoFuture.notifyListeners(DefaultIoFuture.java:360)[30:org.apache.mina.core:2.0.9]

  at
org.apache.mina.core.future.DefaultIoFuture.setValue(DefaultIoFuture.java:288)[30:org.apache.mina.core:2.0.9]

  at
org.apache.mina.core.future.DefaultReadFuture.setRead(DefaultReadFuture.java:102)[30:org.apache.mina.core:2.0.9]

  at
org.apache.mina.core.session.AbstractIoSession.offerReadFuture(AbstractIoSession.java:372)[30:org.apache.mina.core:2.0.9]

  at
org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:857)[30:org.apache.mina.core:2.0.9]

  at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:542)[30:org.apache.mina.core:2.0.9]

  at
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:48)[30:org.apache.mina.core:2.0.9]

  at
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:943)[30:org.apache.mina.core:2.0.9]

  at
org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:109)[30:org.apache.mina.core:2.0.9]

  at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:542)[30:org.apache.mina.core:2.0.9]

  at
org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:535)[30:org.apache.mina.core:2.0.9]

  at
org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:714)[30:org.apache.mina.core:2.0.9]

  at
org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:668)[30:org.apache.mina.core:2.0.9]

  at
org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:657)[30:org.apache.mina.core:2.0.9]

  at
org.apache.mina.core.polling.AbstractPollingIoProcessor.access$600(AbstractPollingIoProcessor.java:67)[30:org.apache.mina.core:2.0.9]

  at
org.apache.mina.core.polling.Abstr

InvalidAlgorithmParameterException SSHD

2016-11-22 Thread Vikram Darsi 
Hi Karaf Team

We are using Apache-Karaf 3.0.7 (Apache SSHD Core 0.14.0 + Apache Mina Core 
2.0.9 + JDK 1.8 update 45) and still experiencing below issue during key 
exchange between SSH Client and SSH Server. the same piece of code is working 
fine on Apache Karaf 3.0.3 (Apache SSHD Core 0.12.0 + Apache Mina Core 2.0.7 + 
JDK 1.8 update 45 )

Below is the info:
Karaf
  Karaf version   3.0.7
  OSGi Framework  org.eclipse.osgi - 3.8.2.v20130124-134944
JVM
  Java Virtual MachineJava HotSpot(TM) 64-Bit Server VM version 
25.45-b02
  Version 1.8.0_45
  Vendor  Oracle Corporation
Operating system
  NameLinux version 2.6.32-642.6.1.el6.x86_64
  Architectureamd64
  Processors  1

java.security.InvalidAlgorithmParameterException: Prime size must be multiple 
of 64, and can only range from 512 to 2048 (inclusive)
  at 
com.sun.crypto.provider.DHKeyPairGenerator.initialize(DHKeyPairGenerator.java:120)[sunjce_provider.jar:1.8.0_51]
  at 
java.security.KeyPairGenerator$Delegate.initialize(KeyPairGenerator.java:674)[:1.8.0_45]
  at 
java.security.KeyPairGenerator.initialize(KeyPairGenerator.java:411)[:1.8.0_45]
  at 
org.apache.sshd.common.kex.DH.getE(DH.java:65)[31:org.apache.sshd.core:0.14.0]
  at 
org.apache.sshd.client.kex.DHGEX.next(DHGEX.java:118)[31:org.apache.sshd.core:0.14.0]
  at 
org.apache.sshd.common.session.AbstractSession.doHandleMessage(AbstractSession.java:425)[31:org.apache.sshd.core:0.14.0]
  at 
org.apache.sshd.common.session.AbstractSession.handleMessage(AbstractSession.java:326)[31:org.apache.sshd.core:0.14.0]
  at 
org.apache.sshd.client.session.ClientSessionImpl.handleMessage(ClientSessionImpl.java:306)[31:org.apache.sshd.core:0.14.0]
  at 
org.apache.sshd.common.session.AbstractSession.decode(AbstractSession.java:780)[31:org.apache.sshd.core:0.14.0]
  at 
org.apache.sshd.common.session.AbstractSession.messageReceived(AbstractSession.java:308)[31:org.apache.sshd.core:0.14.0]
  at 
com.adva.ensemble.controller.callhome.impl.ReversedAsyncSshHandler$MyAsyncSshHandlerReader.operationComplete(ReversedAsyncSshHandler.java:138)[286:com.adva.ensemble.controller.callhome-config-dispatcher:17.1.1.1]
  at 
com.adva.ensemble.controller.callhome.impl.ReversedAsyncSshHandler$MyAsyncSshHandlerReader.operationComplete(ReversedAsyncSshHandler.java:111)[286:com.adva.ensemble.controller.callhome-config-dispatcher:17.1.1.1]
  at 
org.apache.mina.core.future.DefaultIoFuture.notifyListener(DefaultIoFuture.java:375)[30:org.apache.mina.core:2.0.9]
  at 
org.apache.mina.core.future.DefaultIoFuture.notifyListeners(DefaultIoFuture.java:360)[30:org.apache.mina.core:2.0.9]
  at 
org.apache.mina.core.future.DefaultIoFuture.setValue(DefaultIoFuture.java:288)[30:org.apache.mina.core:2.0.9]
  at 
org.apache.mina.core.future.DefaultReadFuture.setRead(DefaultReadFuture.java:102)[30:org.apache.mina.core:2.0.9]
  at 
org.apache.mina.core.session.AbstractIoSession.offerReadFuture(AbstractIoSession.java:372)[30:org.apache.mina.core:2.0.9]
  at 
org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:857)[30:org.apache.mina.core:2.0.9]
  at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:542)[30:org.apache.mina.core:2.0.9]
  at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:48)[30:org.apache.mina.core:2.0.9]
  at 
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:943)[30:org.apache.mina.core:2.0.9]
  at 
org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:109)[30:org.apache.mina.core:2.0.9]
  at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:542)[30:org.apache.mina.core:2.0.9]
  at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:535)[30:org.apache.mina.core:2.0.9]
  at 
org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:714)[30:org.apache.mina.core:2.0.9]
  at 
org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:668)[30:org.apache.mina.core:2.0.9]
  at 
org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:657)[30:org.apache.mina.core:2.0.9]
  at 
org.apache.mina.core.polling.AbstractPollingIoProcessor.access$600(AbstractPollingIoProcessor.java:67)[30:org.apache.mina.core:2.0.9]
  at 
org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:1121)[30:org.apache.m

Re: Auto-upgrade with Karaf features

2016-11-22 Thread Guillaume Nodet 
2016-11-22 12:32 GMT+01:00 Hari Madhavan :

> Hi All,
>
> We use OSGi with Karaf for a secure and reliable message delivery product
> that is deployed on end-user desktops ( as opposed to servers ) . One of
> the things that is important is to have seamless auto-upgrades of the
> product as new versions are published. There are 2 requirements that we had
> for which I wanted to understand the best solution.
>
>
>- We had decided to stop all activity in the product before starting
>the upgrade. This would cause a small delay for the end-user but as
>upgrades do not happen often it is acceptable as long as we do it only
>during upgrades. The process that we would follow is as follows
>- Check if there is an update available for a feature
>   - If updates are available
>  - complete currently running transactions
>  - shutdown all services
>  - pull down the updates from the server ( Nexus )
>  - install the updates
>
> How can we find whether there is an feature upgrade to be installed ? Is
> there an event on feature:repo-refresh that we can bind to which will tell
> us that the feature has an upgrade ? Alternatively can we invoke
> feature:install when it runs with -t -v parameters through an API interface
> as that would also enable us to confirm whether an attempt to upgrade would
> bring new versions or not.
>
>
Note that your feature repositories should be versioned correctly.  So you
could use the mvn url handler to check if there's a new version of the
repository to use.  Then use the published FeaturesService to simulate the
changes.  It's not really easy to detect if there are any changes, as none
of the methods of the FeaturesService return a useful result.
One way without changing the code would be to use the setOutputFile method
which has the effect of writing the output of the resolver to a file in
json format.  You can then read the file, extract the list of bundles and
compare them to the list of current bundles to see if there are any
changes.


>
>- We wanted to have an option of running an upgrade installer at the
>time of upgrade where the structure of some of the persistent data stores (
>databases , preference files ) related to the product are updated to be
>consistent with the new version of the bundle that manages this data store.
>To do this we defined an upgrade interface that is implemented in bundles
>that need some client side changes to be done at the time of upgrade. We
>plan to invoke this service interface after the upgraded bundle has been
>installed by providing the earlier version of the bundle as a parameter,
> so that the upgrade service implementation within the bundle can serially
>do all upgrade changes from that version to the current version.  To do
>this before installing a feature , I'd like to know the original version of
>each bundle which has changed. This information is available when
>feature:install is run with a -v parameter. How can we programatically
>access that information ?
>
> If you use the method I indicated above to see if there are any changes,
you should have the list of old and new bundles.

Btw, if you prefer, you can use the verbose flag instead of the json
written file.  In order to grab the output which is written to System.out,
you'd have to use the org.apache.felix.service.threadio.ThreadIO service in
order to set the thread based system streams with your own stream to grab
the output.  But you'd have to parse the output which is more error prone I
think.


> Apologies for the long mail and thanks in advance for your suggestions.
>
> Regards
> Hari
>
>
> Regards
> Hari
>
> Hari Madhavan,
> Director - ERP Practice,
> Promantia Global Consulting LLP 
> Ph: +91 9845147731
> *Openbravo Gold Partner*
>



-- 

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

Re: Auto-upgrade with Karaf features

2016-11-22 Thread Hari Madhavan 
Thanks JB.

The programming interface to feature:install is what we require , so that
we can get the output of the simulation in a stream or a  data structure
and parse it to check whether the feature:install  would have any upgrades.

I suppose I can go to the git repository and get the commands and tests
around the service to get some samples to work with... Will check that out.
Is there any other sample that you would suggest ?

Regards
Hari

On Tue, Nov 22, 2016 at 5:21 PM, Jean-Baptiste Onofré 
wrote:

> Hi Hari,
>
> feature:repo-refresh will reload the features XML if it has changed.
> However, the feature might be updated even if the features XML didn't
> change (for instance if you use SNAPSHOT in the feature).
>
> So, basically, we don't have an event today providing the "diff" between
> an installed feature and the resolved feature.
>
> feature:install -u with -t -v is possible and should provide the details
> that you can parse.
>
> Do you want to do it programmatically or by "scripting" ?
>
> For the second point, you can call the feature service to get details,
> providing the same as in the feature:install command (which actually use
> the feature service).
>
> Regards
> JB
>
> On 11/22/2016 12:32 PM, Hari Madhavan wrote:
>
>> Hi All,
>>
>> We use OSGi with Karaf for a secure and reliable message delivery
>> product that is deployed on end-user desktops ( as opposed to servers )
>> . One of the things that is important is to have seamless auto-upgrades
>> of the product as new versions are published. There are 2 requirements
>> that we had for which I wanted to understand the best solution.
>>
>>   * We had decided to stop all activity in the product before starting
>> the upgrade. This would cause a small delay for the end-user but as
>> upgrades do not happen often it is acceptable as long as we do it
>> only during upgrades. The process that we would follow is as follows
>>   o Check if there is an update available for a feature
>>   o If updates are available
>>   + complete currently running transactions
>>   + shutdown all services
>>   + pull down the updates from the server ( Nexus )
>>   + install the updates
>>
>> How can we find whether there is an feature upgrade to be installed
>> ? Is there an event on feature:repo-refresh that we can bind to
>> which will tell us that the feature has an upgrade ? Alternatively
>> can we invoke feature:install when it runs with -t -v parameters
>> through an API interface as that would also enable us to confirm
>> whether an attempt to upgrade would bring new versions or not.
>>
>>   * We wanted to have an option of running an upgrade installer at the
>> time of upgrade where the structure of some of the persistent data
>> stores ( databases , preference files ) related to the product are
>> updated to be consistent with the new version of the bundle that
>> manages this data store. To do this we defined an upgrade interface
>> that is implemented in bundles that need some client side changes to
>> be done at the time of upgrade. We plan to invoke this service
>> interface after the upgraded bundle has been installed by providing
>> the earlier version of the bundle as a parameter,  so that the
>> upgrade service implementation within the bundle can serially do all
>> upgrade changes from that version to the current version.  To do
>> this before installing a feature , I'd like to know the original
>> version of each bundle which has changed. This information is
>> available when feature:install is run with a -v parameter. How can
>> we programatically access that information ?
>>
>> Apologies for the long mail and thanks in advance for your suggestions.
>>
>> Regards
>> Hari
>>
>>
>> Regards
>> Hari
>>
>> Hari Madhavan,
>> Director - ERP Practice,
>> Promantia Global Consulting LLP 
>> Ph: +91 9845147731
>> *Openbravo Gold Partner*
>>
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>



-- 
Hari Madhavan,
Director - ERP Practice,
Promantia Global Consulting LLP 
Ph: +91 9845147731
*Openbravo Gold Partner*

Re: Karaf Cellar question: how to get cluster node information programmatically ?

2016-11-22 Thread Jean-Baptiste Onofré 

Hi Serge,

If you want the node details, you have to use "regular" Karaf JMX, 
Cellar doesn't provide "bridges" to JMX (for now, I created a Jira about 
that while ago).


Regards
JB

On 11/22/2016 10:11 AM, Serge Huber wrote:

Hi JB,

Thanks for your quick answer.

It’s the next step that I’m having trouble with. Once I have the Node, what’s 
the best way of accessing it’s JMX data ? Is there something provided by Cellar 
or should I just use regular JMX RMI connectors ?

cheers,
  Serge…


On 21 nov. 2016, at 18:45, Jean-Baptiste Onofré  wrote:

Hi Serge,

the ClusterManager service provides the Node via different method (for instance 
getNode() & listNodes()).

Then, you have Node where you can get status.

Regards
JB

On 11/21/2016 05:57 PM, Serge Huber wrote:

Hi all,

I’ve seen that it’s possible to list the cluster nodes from the ClusterManager 
information, but I was wondering if there was a way to retrieve system 
information from the nodes, such as stuff that is accessible through JMX 
(uptime, load, etc..)

I’d like to do this programmatically but I need some help :)

cheers,
 Serge…



--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com




--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Auto-upgrade with Karaf features

2016-11-22 Thread Jean-Baptiste Onofré 

Hi Hari,

feature:repo-refresh will reload the features XML if it has changed.
However, the feature might be updated even if the features XML didn't 
change (for instance if you use SNAPSHOT in the feature).


So, basically, we don't have an event today providing the "diff" between 
an installed feature and the resolved feature.


feature:install -u with -t -v is possible and should provide the details 
that you can parse.


Do you want to do it programmatically or by "scripting" ?

For the second point, you can call the feature service to get details, 
providing the same as in the feature:install command (which actually use 
the feature service).


Regards
JB

On 11/22/2016 12:32 PM, Hari Madhavan wrote:

Hi All,

We use OSGi with Karaf for a secure and reliable message delivery
product that is deployed on end-user desktops ( as opposed to servers )
. One of the things that is important is to have seamless auto-upgrades
of the product as new versions are published. There are 2 requirements
that we had for which I wanted to understand the best solution.

  * We had decided to stop all activity in the product before starting
the upgrade. This would cause a small delay for the end-user but as
upgrades do not happen often it is acceptable as long as we do it
only during upgrades. The process that we would follow is as follows
  o Check if there is an update available for a feature
  o If updates are available
  + complete currently running transactions
  + shutdown all services
  + pull down the updates from the server ( Nexus )
  + install the updates

How can we find whether there is an feature upgrade to be installed
? Is there an event on feature:repo-refresh that we can bind to
which will tell us that the feature has an upgrade ? Alternatively
can we invoke feature:install when it runs with -t -v parameters
through an API interface as that would also enable us to confirm
whether an attempt to upgrade would bring new versions or not.

  * We wanted to have an option of running an upgrade installer at the
time of upgrade where the structure of some of the persistent data
stores ( databases , preference files ) related to the product are
updated to be consistent with the new version of the bundle that
manages this data store. To do this we defined an upgrade interface
that is implemented in bundles that need some client side changes to
be done at the time of upgrade. We plan to invoke this service
interface after the upgraded bundle has been installed by providing
the earlier version of the bundle as a parameter,  so that the
upgrade service implementation within the bundle can serially do all
upgrade changes from that version to the current version.  To do
this before installing a feature , I'd like to know the original
version of each bundle which has changed. This information is
available when feature:install is run with a -v parameter. How can
we programatically access that information ?

Apologies for the long mail and thanks in advance for your suggestions.

Regards
Hari


Regards
Hari

Hari Madhavan,
Director - ERP Practice,
Promantia Global Consulting LLP 
Ph: +91 9845147731
*Openbravo Gold Partner*


--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Auto-upgrade with Karaf features

2016-11-22 Thread Hari Madhavan 
Hi All,

We use OSGi with Karaf for a secure and reliable message delivery product
that is deployed on end-user desktops ( as opposed to servers ) . One of
the things that is important is to have seamless auto-upgrades of the
product as new versions are published. There are 2 requirements that we had
for which I wanted to understand the best solution.


   - We had decided to stop all activity in the product before starting the
   upgrade. This would cause a small delay for the end-user but as upgrades do
   not happen often it is acceptable as long as we do it only during upgrades.
   The process that we would follow is as follows
   - Check if there is an update available for a feature
  - If updates are available
 - complete currently running transactions
 - shutdown all services
 - pull down the updates from the server ( Nexus )
 - install the updates

How can we find whether there is an feature upgrade to be installed ? Is
there an event on feature:repo-refresh that we can bind to which will tell
us that the feature has an upgrade ? Alternatively can we invoke
feature:install when it runs with -t -v parameters through an API interface
as that would also enable us to confirm whether an attempt to upgrade would
bring new versions or not.


   - We wanted to have an option of running an upgrade installer at the
   time of upgrade where the structure of some of the persistent data stores (
   databases , preference files ) related to the product are updated to be
   consistent with the new version of the bundle that manages this data store.
   To do this we defined an upgrade interface that is implemented in bundles
   that need some client side changes to be done at the time of upgrade. We
   plan to invoke this service interface after the upgraded bundle has been
   installed by providing the earlier version of the bundle as a parameter,
so that the upgrade service implementation within the bundle can serially
   do all upgrade changes from that version to the current version.  To do
   this before installing a feature , I'd like to know the original version of
   each bundle which has changed. This information is available when
   feature:install is run with a -v parameter. How can we programatically
   access that information ?

Apologies for the long mail and thanks in advance for your suggestions.

Regards
Hari


Regards
Hari

Hari Madhavan,
Director - ERP Practice,
Promantia Global Consulting LLP 
Ph: +91 9845147731
*Openbravo Gold Partner*

Re: Karaf Cellar question: how to get cluster node information programmatically ?

2016-11-22 Thread Serge Huber 
Hi JB,

Thanks for your quick answer. 

It’s the next step that I’m having trouble with. Once I have the Node, what’s 
the best way of accessing it’s JMX data ? Is there something provided by Cellar 
or should I just use regular JMX RMI connectors ?

cheers,
  Serge… 

> On 21 nov. 2016, at 18:45, Jean-Baptiste Onofré  wrote:
> 
> Hi Serge,
> 
> the ClusterManager service provides the Node via different method (for 
> instance getNode() & listNodes()).
> 
> Then, you have Node where you can get status.
> 
> Regards
> JB
> 
> On 11/21/2016 05:57 PM, Serge Huber wrote:
>> Hi all,
>> 
>> I’ve seen that it’s possible to list the cluster nodes from the 
>> ClusterManager information, but I was wondering if there was a way to 
>> retrieve system information from the nodes, such as stuff that is accessible 
>> through JMX (uptime, load, etc..)
>> 
>> I’d like to do this programmatically but I need some help :)
>> 
>> cheers,
>>  Serge…
>> 
> 
> -- 
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com