Hi JB,
I've tested it once again and I still get an error when deploying a command
with version 1.1.0 in Karaf 2.3.3:
[ERROR] BlueprintContainerImpl - Unable to start blueprint container for bundle
at.ac.ait.hbs.homer.core.shell.scheduler
Hi,
you are missing the name attribute on the command tag like in this example:
|command*name=test/hello*
action class=org.apache.karaf.shell.samples.HelloShellCommand/
/command
|
regards, Marco
Am 22.01.2014 09:48, schrieb Roedl Lukas:
Hi JB,
I've tested it once again and I still
Hi,
forget about my above answer. Did not read the complete conversation
properly.
regards, Marco
Am 22.01.2014 10:15, schrieb Marco Westermann:
Hi,
you are missing the name attribute on the command tag like in this
example:
|command*name=test/hello*
action
shell namespace 1.1.0 is only available with Karaf 3.0.0.
shell namespace 1.0.0 and 1.1.0 are supported by Karaf 3.0.0.
Karaf 2.x only support shell namespace 1.0.0.
Regards
JB
On 01/22/2014 09:48 AM, Roedl Lukas wrote:
Hi JB,
I've tested it once again and I still get an error when
Hi Nicolas,
yes I think it's the same issue, that should be fixed in 3.0.1.
Sorry about that.
Regards
JB
On 01/22/2014 10:42 AM, Nicolas wrote:
Hi,
I have changed to the release 3.0.0, but i have a problem on Windows.
When i run karaf as a service (with the wrapper), or when i run karaf
Hi JB,
I have question about cellar. I used karaf 2.3.3, cellar 2.3.2
I have 2 nodes, node1 and node2.
I used the below command to install cellar for the 2 nodes
*features:addurl
mvn:org.apache.karaf.cellar/apache-karaf-cellar/2.3.2/xml/features
Thanks you JB.
It is possible to have a work arround or to patch my own karaf. I have my
own custom karaf release and it's not a problem for me if i have to fork a
project to fix it.
I work on linux, so it's difficult for me to debug and to found the problem.
But if you have an idea, i can try
Give me some time to take a look on my VM today and I keep you posted.
I think it's a mistake in the classpath definition (wrapper and/or
client). I take a look.
I keep you posted.
Regards
JB
On 01/22/2014 11:17 AM, Nicolas wrote:
Thanks you JB.
It is possible to have a work arround or to
Ok, then the error message makes sense.
Thanks for your clarification - I didn't know that 1.1.0 wasn't supported at
the 2.3.x branch ;-)
Best regards,
Lukas
-Ursprüngliche Nachricht-
Von: Jean-Baptiste Onofré [mailto:j...@nanthrax.net]
Gesendet: Mittwoch, 22. Januar 2014 10:51
An:
Hello,
I have a question about KARAF_HOME and KARAF_BASE vars. Indeed, I though
that KARAF_HOME was the main lib rep and KARAF_BASE the working dir.
But I noticed that external librairies are imported from
${KARAF_HOME}/lib/ext.
In the case there are external jars I'd like to import in the
Hi,
the main difference is about root and other instances.
KARAF_HOME is shared between the instances whereas KARAF_BASE is local
to an instance.
As the lib should be shared by the instances, the right should be
${KARAF_HOME}/lib/ext. For the root instance, it doesn't matter.
Regards
JB
On
By the way, Karaf 3.0.0 and 2.4.0 introduce KARAF_ETC (for the location
of the configuration files). I introduced it for the deb, rpm, and
Ubuntu Juju charms that I'm preparing.
Regards
JB
On 01/22/2014 12:15 PM, Jean-Baptiste Onofré wrote:
Hi,
the main difference is about root and other
Hi Jean Baptiste,
thanks for your answser. Actually i'm used to tomcat where tomcat_home is
the binaries dir and tomcat_base the local instance.
Is this different with karaf. I think I'll have only root instances on
differents users and I wanted to make them share the same binaries directory
More over I noticed in bin/karaf the following lines :
locateHome() {
if [ x$KARAF_HOME != x ]; then
warn Ignoring predefined value for KARAF_HOME
fi
# In POSIX shells, CDPATH may cause cd to write to stdout
(unset CDPATH) /dev/null 21 unset CDPATH
KARAF_HOME=`cd
KARAF_HOME doesn't mean the Karaf home to users. It's the main folder
hosting different Karaf instances.
By default KARAF_BASE == KARAF_HOME.
Regards
JB
On 01/22/2014 12:31 PM, cbiava wrote:
More over I noticed in bin/karaf the following lines :
locateHome() {
if [ x$KARAF_HOME != x ];
Hi Nico,
good catch.
Stupid question: do you have Windows default firewall enable (security)
on your Windows machine ?
Regards
JB
On 01/22/2014 02:21 PM, Nicolas wrote:
Ok, I have found a work around :)
If i call client.bat with -h 127.0.0.1, it works !!! but with 0.0.0.0
(default value)
On my VM, i have the default windows firewall enable. If i disable this, i
have the same error (but i don't know if i have to reboot my windows to
disable the firewall ??)
On our physical post, we use Kaspersky and we have the same error.
--
View this message in context:
After little debug on the Main.class from the karaf-client.jar, we have found
an exception on the Main in the line : - ConnectFuture future =
client.connect(config.getHost(), config.getPort());In the Nio2Connector, we
have a CompletionHandler with a failed callback. In this callback, we have
It sounds like a Windows JVM issue.
It doesn't look to understand 0.0.0.0. I gonna take a look but we should
at least document this. I gonna do a diff with RC1 too (AFAIR we used
localhost by default before, I have to remember why we use 0.0.0.0 now ;)).
Regards
JB
On 01/22/2014 03:14 PM,
Thanks for the update.
I gonna dig around that.
Regards
JB
On 01/22/2014 03:31 PM, Nicolas wrote:
Ok.
I hope (and i think) is not a JVM issue, i use the 0.0.0.0 often :)
But, if i may help you, when i do client.bat -h 0.0.0.0 with the karaf
3.0.0.RC1, i can connect to the console.
Thanks
No problem, thank you for your work :)
I add a comment on the JIRA
--
View this message in context:
http://karaf.922171.n3.nabble.com/Failed-to-get-the-console-with-client-bat-on-windows-with-Karaf-3-0-0-tp4031248p4031269.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Hello, I had ran into a problem before where in an integration test I would
create a child karaf instance, then after it started, I would try to
connect to it via instance:connect from the root console and the connection
fails due to certificate issues. If I delete the .karafssh directory, then
Hi Ryan,
did you remove the $HOME/.sshkaraf file ?
It's probably because you restart a Karaf from scratch (for the key
changed).
Regards
JB
On 01/22/2014 03:53 PM, Ryan Moquin wrote:
Hello, I had ran into a problem before where in an integration test I
would create a child karaf instance,
If I remove it, then the tests run fine. Is there a way to avoid it
altogether for integration tests? Otherwise I have to remove it everytime
I do a clean test (which I always do to be safe).
I don't remember this being such a problem until recently... now it
constantly happens.
Ryan
On
As a quick workaround I would propose to add a @after test to cleanly
remove the file after itests.
As the itests download and bootstrap a new Karaf runtime each time
(that's why the previous generated key is no more valid).
AFAIR, I did it as a warning (with confirmation message as we have on
You use instance:connect like I was which works..
On Jan 22, 2014 11:43 AM, Jean-Baptiste Onofré j...@nanthrax.net wrote:
Hmmm, it should work (I think we already use it in Cellar itests).
Let me try.
Regards
JB
On 01/22/2014 05:36 PM, Ryan Moquin wrote:
I switched back to using the
Hmmm, it should work (I think we already use it in Cellar itests).
Let me try.
Regards
JB
On 01/22/2014 05:36 PM, Ryan Moquin wrote:
I switched back to using the ssh:ssh shell command and appeared to get
around that issue but ran back into one that made me switch in the first
place. If I do:
I switched back to using the ssh:ssh shell command and appeared to get
around that issue but ran back into one that made me switch in the first
place. If I do:
ssh:ssh -l karaf -P 8102 localhost feature:list | grep cellar
Then I think everything after feature:list gets dropped when tbe command
I thought so too
On Jan 22, 2014 11:43 AM, Jean-Baptiste Onofré j...@nanthrax.net wrote:
Hmmm, it should work (I think we already use it in Cellar itests).
Let me try.
Regards
JB
On 01/22/2014 05:36 PM, Ryan Moquin wrote:
I switched back to using the ssh:ssh shell command and
Ok, that'll be fun merging it with the changes I've been working on :)
Ryan
On Jan 22, 2014 11:50 AM, Jean-Baptiste Onofré j...@nanthrax.net wrote:
That's it, I remember now ;)
Let me take a look.
By the way, I will push my local Cellar branch for 3.0.0 tomorrow with a
bunch of changes
Don't hesitate to share your fork, I will merge on my branch just after
the push ;)
Regards
JB
On 01/22/2014 07:41 PM, Ryan Moquin wrote:
Ok, that'll be fun merging it with the changes I've been working on :)
Ryan
On Jan 22, 2014 11:50 AM, Jean-Baptiste Onofré j...@nanthrax.net
I actually have been keeping my fork up to date on my git account
(rmoquin/karaf-cellar). I made a lot of enhancements. I'm just down to
fixing the last 6 failing tests (almost down to only 5).
It would be awesome if you can pull it in. I'd like to get anything you
like merged so I can get
32 matches
Mail list logo
