To wrap this up: I managed to resolve most issues by migrating my web service
bundles from Spring-WS to CXF. Also, I am now using only feature
dependencies instead of bundle dependencies, e.g. to my "base" bundle that
is shared across most other features. None of my bundles uses dynamic
imports any
Hi all,
I was browsing the source code here (cellar-kubernetes):
https://github.com/apache/karaf-cellar/blob/master/kubernetes/src/main/java/org/apache/karaf/cellar/kubernetes/KubernetesDiscoveryServiceFactory.java#L69
This loop looks "idempotent" to me:
Properties serviceProperti
HI JB,
This is is not exactly what I am seeing, or maybe it is a matter of semantics.
The child instance (after creation with instance:create) inherits the same
features.cfg as the parent, which in turn was modified from the official
distribution. For example, the parent instance is launched
Hi Achim,
I added bootFinished per your recommendation, but I am still getting the same
exception.
The interesting thing is that, right before invoking the feature:install
command, I call the feature:list command, which generates this output:
2015-12-07 09:18:40,382 | INFO | -192.168.200.136
I could not get the Hibernate bean validation feature to work in
4.0.x. For one thing, it's in the 'enterprise' feature set, which does
not work at all without extra elements which I can't
have. Even when I copied it out, I still couldn't get it to work.
So I made a working feature with Apache Bv
My test has:
@Inject
@Filter(value = "service=worker", timeout = 5L) // wait for the worker.
WebServiceAvailable webServiceAvailable;
(in an abstract base class)
My @Test method called, the variable is null, and there are no errors
in the log. I also have a similar injection for BootFinished
Hi,
When I deploy some "CDI" bundles in Apache Karaf 2.4, Pax CDI reports this
error many times
I don't think that the error is blocking but If somebody knows the reason,
that could be very valuable ...
ERROR: Bundle io.apiman.manager-api-core [350] EventDispatcher: Error
during dispatch. (java
Hi Benson,
I got it working making my own validation feature, you can find it here:
https://github.com/OsgiliathEnterprise/net.osgiliath.parent/blob/master/net.osgiliath.framework/net.osgiliath.features/net.osgiliath.feature.validation/src/main/resources/net.osgiliath.feature.validation.xml
Regar
Hello,
I am have installed Cellar v2.3.6 in each of my Karaf instances.
Karaf1 - IP aaa.aaa.aaa, port
Karaf2 - IP bbb.bbb.bbb, port
Why is it that when I issue the following on Karaf1, I get 'Cluster node
bbb.bbb.bbb doesn't exit':
Karaf root> cluster:group-set dev bbb.bbb.bbb:ccc
Thanks!
On Mon, Dec 7, 2015 at 10:46 AM, Charlie Mordant wrote:
> Hi Benson,
>
> I got it working making my own validation feature, you can find it here:
> https://github.com/OsgiliathEnterprise/net.osgiliath.parent/blob/master/net.osgiliath.framework/net.osgiliath.features/net.osgiliath.feature.
Hi Dario,
you are right, let me create a Jira and fix that.
Thanks,
Regards
JB
On 12/07/2015 01:29 PM, Dario Cimafonte wrote:
Hi all,
I was browsing the source code here (cellar-kubernetes):
https://github.com/apache/karaf-cellar/blob/master/kubernetes/src/main/java/org/apache/karaf/cellar/k
Hi Alex,
it should not, else it's a bug: if you use the instance:create, it
should use the "default/standard" features set. Only instance:close
should "copy" the set from the root instance.
Let me check using the commands.
Regards
JB
On 12/07/2015 03:05 PM, Alex Soto wrote:
HI JB,
This is
Hi Barry,
what do you have with cellar:node-list ?
Do you use multicast or "static" tcp-ip in etc/hazelcast.xml ?
Thanks,
Regards
JB
On 12/07/2015 04:54 PM, barry.barn...@wellsfargo.com wrote:
Hello,
I am have installed Cellar v2.3.6 in each of my Karaf instances.
Karaf1 – IP aaa.aaa.aaa, por
Hi Alex,
do you have the log ? I'm suspecting the commands are waiting for the
feature service.
Regards
JB
On 12/07/2015 03:30 PM, Alex Soto wrote:
Hi Achim,
I added bootFinished per your recommendation, but I am still getting the
same exception.
The interesting thing is that, right before
Hi Andreas,
I saw your PR and it looks good to me. However, I would like to discuss
with Freeman first.
Regards
JB
On 12/06/2015 11:10 AM, akuhtz wrote:
Hi JB,
I prepared a PR (https://github.com/apache/karaf/pull/112) some days ago and
would like to test with the latest snapshot if it work
I use whatever the default is set to... should I change something? Node list
only shows aaa.aaa.aaa on the aaa server. And bbb.bbb.bbb on the bbb server.
Can't get either to show the other node in the list.
Regards,
Barry
-Original Message-
From: Jean-Baptiste Onofré [mailto:j..
Hi Barry,
it's probably because the Cellar hazelcast instances don't show each
other (maybe firewall between the nodes, or so).
You can change the network discovery mechanism in etc/hazelcast.xml of
each instance.
Regards
JB
On 12/07/2015 05:49 PM, barry.barn...@wellsfargo.com wrote:
I us
This is especially puzzeling on mac machines, since the upgrade to Yosemite
multicast doesn't work anymore
2015-12-07 18:09 GMT+01:00 Jean-Baptiste Onofré :
> Hi Barry,
>
> it's probably because the Cellar hazelcast instances don't show each other
> (maybe firewall between the nodes, or so).
>
Hello,
Using Karaf 4.0.3, and PAX-EXAM 4.7.0, I am not able to run commands on the
child instance. In my test, I create and start a child instance.
When I try to run a command in the child instance:
executeCommand("instance:connect " + name + " bundle:list ");
I get the following exc
Change it to multicast?
Regards,
Barry
-Original Message-
From: Jean-Baptiste Onofré [mailto:j...@nanthrax.net]
Sent: Monday, December 07, 2015 12:09 PM
To: user@karaf.apache.org
Subject: Re: Cellar clustering issue
Hi Barry,
it's probably because the Cellar hazelcast instances don'
By default, Cellar uses multicast. But maybe you have firewall, or
promiscuous mode is not allowed on your interfaces.
So, instead of multicast, you can use "static" tcp-ip in
etc/hazelcast.xml where you specify the IP addresses of the nodes.
Regards
JB
On 12/07/2015 07:40 PM, barry.barn...@we
You can enable the authentication by cert (in etc/keys.properties), like
this, the password won't be prompted.
You can also provide the password as option to instance:connect.
Regards
JB
On 12/07/2015 07:34 PM, Alex Soto wrote:
Hello,
Using Karaf 4.0.3, and PAX-EXAM 4.7.0, I am not able to
Like this?
127.0.0.1
Ip of remote server
Regards,
Barry
-Original Message-
From: Jean-Baptiste Onofré [mailto:j...@nanthrax.net]
Sent: Monday, December 07, 2015 1:46 PM
To: user@karaf.apache.org
Subject: Re: Cellar clustering issue
By de
actually you need to configure every IP on macs for it to work properly.
regards, Achim
2015-12-07 19:40 GMT+01:00 :
> Change it to multicast?
>
> Regards,
>
> Barry
>
>
> -Original Message-
> From: Jean-Baptiste Onofré [mailto:j...@nanthrax.net]
> Sent: Monday, December 07, 2015 12:09
is for your "local" network interfaces on which you want to
bind Cellar.
You can use to specify the node addresses.
Regards
JB
On 12/07/2015 07:48 PM, barry.barn...@wellsfargo.com wrote:
Like this?
127.0.0.1
Ip of remote server
Regards,
Ba
Ok, but do I put:
127.0.0.1
remoteserver1 IP
remoteserver2 IP…. etc
Regards,
Barry
From: Achim Nierbeck [mailto:bcanh...@googlemail.com]
Sent: Monday, December 07, 2015 1:43 PM
To: user@karaf.apache.org
Subject: Re: Cellar clustering issue
actually
Hi Barry,
in your case, you should have:
196.168.134.2
192.168.134.10
where 192.168.134.2 is the public IP address of node1, and
192.168.134.10 is the IP address of node2 for instance.
Regards
JB
On 12/07/2015 07:54 PM, barry.barn...@wellsfargo.com wrote:
Ok, but do I put:
This is what im getting now:
karaf@root> cluster:group-list
Group Members
* [dev ] [host1.xxx.com:5701* ]
[default ] []
karaf@root> cluster:group-set dev host2IP:5701
Cluster node host2IP:5701 doesn't exist
My hazelcast shows the following on host
Can you try to put only the public interface (no member) ?
Regards
JB
On 12/07/2015 08:10 PM, barry.barn...@wellsfargo.com wrote:
This is what im getting now:
karaf@root> cluster:group-list
Group Members
* [dev ] [host1.xxx.com:5701* ]
[default
The public interface is just the hostname of that server, right?
Regards,
Barry
-Original Message-
From: Jean-Baptiste Onofré [mailto:j...@nanthrax.net]
Sent: Monday, December 07, 2015 2:13 PM
To: user@karaf.apache.org
Subject: Re: Cellar clustering issue
Can you try to put only the
Yes, correct.
Regards
JB
On 12/07/2015 08:15 PM, barry.barn...@wellsfargo.com wrote:
The public interface is just the hostname of that server, right?
Regards,
Barry
-Original Message-
From: Jean-Baptiste Onofré [mailto:j...@nanthrax.net]
Sent: Monday, December 07, 2015 2:13 PM
To: u
I tried the below, and still:
* [host2IP:5701] [host2IP] [ 5701]
karaf@root> cluster:group-list
Group Members
* [dev ] [host2IP:5701* ]
[default ] []
karaf@root> cluster:group-set dev host1IP:5701
Cluster node host1IP:5701 doesn't exist
Regards,
Hello,
there are some small mistakes in the latest manual, for dynamically wrapping
jars.
——
root@karaf> bundle:install wrap:mvn:commons-lang/commons-lang/2.4
The wrap protocol creates a bundle dynamically using the bnd. Confiugurations
can be added in the wrap URL:
from the shell
root@karaf
If cluster:node-list doesn't show the host1, it's the issue.
Did you change hazelcast.xml on both host1 and 2 ?
Regards
JB
On 12/07/2015 08:19 PM, barry.barn...@wellsfargo.com wrote:
I tried the below, and still:
* [host2IP:5701] [host2IP] [ 5701]
karaf@root> cluster:group-list
Group
Thanks for pointing it out.
I will fix that.
Regards
JB
On 12/07/2015 08:35 PM, Christian Lutz wrote:
Hello,
there are some small mistakes in the latest manual, for dynamically
wrapping jars.
——
root@karaf> bundle:install wrap:mvn:commons-lang/commons-lang/2.4
The wrap protocol creates a b
Thanks JB,
I was able to overcome this issue by passing in the user name and password,
however I found that after two runs, I get this error:
Server key for host localhost/127.0.0.1:8102 does not match the stored key !!
Terminating session.
@@@
It's probably because you recreated the instance, so the host key changed.
Removing the .sshkaraf will help, but it would make sense to add a
--force or so option to bypass the host key validation failure.
Regards
JB
On 12/07/2015 08:33 PM, Alex Soto wrote:
Thanks JB,
I was able to overcome
Yes. Node 1 and Node 2 I don’t have the /member now, but just the /interface,
listed as the hostIP of that particular server. Should I put member back in?
That didn't work last time though.
Regards,
Barry
-Original Message-
From: Jean-Baptiste Onofré [mailto:j...@nanthrax.net]
Se
To use an assembly of mine in an integration test of mine, I wrote:
com.basistech.ws
rosapi-assembly-embedded-worker
${project.version}
tar.gz
test
Now my test dependencies include the entire dependency graph of all
the features in the assembly, which is really wrong. I'm n
Can you share the section from both hosts ?
Thanks,
Regards
JB
On 12/07/2015 08:39 PM, barry.barn...@wellsfargo.com wrote:
Yes. Node 1 and Node 2 I don’t have the /member now, but just the /interface,
listed as the hostIP of that particular server. Should I put member back in?
That didn't
Yes, the integration test will run multiple times over the course of
development, either in the developers machine or the CI server(s).
To clarify, there is no “—force" flag yet at this point, correct?
Best regards,
Alex soto
> On Dec 7, 2015, at 2:42 PM, Jean-Baptiste Onofré wrote:
>
> I
Yes, --force doesn't exist yet.
Regards
JB
On 12/07/2015 08:52 PM, Alex Soto wrote:
Yes, the integration test will run multiple times over the course of
development, either in the developers machine or the CI server(s).
To clarify, there is no “—force" flag yet at this point, correct?
Best
42 matches
Mail list logo
