I see, thanks a lot;
-orgin
Sender: Achim Nierbeck [mailto:achim.nierb...@ptv.de]
Time: 2010/11/5 23:31
Receiver: user@karaf.apache.org
Subject: AW: How about to to facilitate to use JNDI(boot delegation) in
karaf?
Hi,
the thing is you do a very tight coupling. Especially when doing "c
You're right. The correct value for karaf 2.1.0 would be:
PROMPT= '\u001b\\[1m${user}\u001b\\...@${application}> ';
Though the value I provided will work on 2.2.0 (trunk for now).
On Fri, Nov 5, 2010 at 21:15, Mike Van wrote:
>
>
>
> Guillaume,
>
>
>
> Are you sure that's correct? I added:
>
>
Guillaume,
Are you sure that's correct? I added:
PROMPT="\u001b[1m${user}\u001b...@${application}> ";
to my shell.init.script file, and I received the following error in the
console:
Error in initialization script: Eof found in the middle of a compound for '][',
begins at b...@${appl
If the broker is colocated, then I would do the following:
* have the broker bundle expose a ConnectionFactory from the same bundle
* have you client bundles import the ConnectionFactory
This should ensure that the ConnectionFactory will be exported once
the broker is correctly up and running,
The default PROMPT is defined as:
public static final String DEFAULT_PROMPT =
"\u001b[1m${user}\u001b...@${application}> ";
To change this, you can set the PROMPT variable in
etc/shell.init.script to something that suit your needs better.
Either as a plain variable:
PROMPT="\u001b[1m${user
I'm currently using Karaf Features (very cool feature) to deploy a suite of
bundles. My feature depends on activemq-blueprint - and subsequently there are
services that require the broker to be running to get through their startup
methods.
When I start Karaf (everytime) I get a nasty JMSExcept
Is it possible to change the "karaf" part of the console prompt in
configuration?
Kit
--
View this message in context:
http://karaf.922171.n3.nabble.com/Change-karaf-root-prompt-tp184p184.html
Sent from the Karaf - User mailing list archive at Nabble.com.
There's no schema defined yet (as you know the features don't use xml
schema nor namespaces).
I think the problem is located in pax-runner, which does not support
dependant features.
On Fri, Nov 5, 2010 at 16:05, Andreas Gies wrote:
>
> Hi Guillaume,
>
> thanks for this. Are you saying that I fai
Hi,
the thing is you do a very tight coupling. Especially when doing "core" bundles
I
would advice not to do it. Just think of this.
One of you core bundles evolves over time and you want to change just parts of
it
by splitting the bundle in two.
Now you end up in changing all bundles that r
Thanks Achim Nierbeck .
I am not very clear why the Require-Bundle is not perfered.
Do you mean Require-Bundle will cause the bundle who import package
will tightly coupling with the bundle who contribute package? Or some other
critical reasons which forbidden us to do so?
Hi Guillaume,
thanks for this. Are you saying that I failed to provide version number and
schema version from my
eMail ? - I am using Karaf 2.1.0 and am relying on
org.apache.karaf.tooling:org.apache.karaf.tooling.testing:jar:2.1.0:test,
which seems to include pax exam 1.2.2.
Or are you saying
Also, Aries provides a JNDI / OSGi integration which you may want to
look at depending on your needs.
On Fri, Nov 5, 2010 at 14:24, Achim Nierbeck wrote:
> Sorry, to interrupt, but Require-Bundle is really bad practice :(
>
>
> Just one side node from me, I once had also an issue with JNDI, becau
Sorry, to interrupt, but Require-Bundle is really bad practice :(
Just one side node from me, I once had also an issue with JNDI, because of
which is the
First Implementing class. I fixed this issue by setting the following parameter
in the karaf.sh/bat.
-Djava.naming.factory.initial=com.sun.j
Thanks Guillaume Nodet , Thanks very much.
You suggestion is a better choice.
While in my situation, not only the javax.naming package, but a lot of other
packages such as "com.sun.jndi.*" ...etc; it's difficult to list them all
out in the bnd's configurations all out.
So how about to using Requi
On Fri, Nov 5, 2010 at 12:02, ext2 wrote:
>
>>: Re: How about to to facilitate to use JNDI(boot delegation) in karaf?
>
>>The boot delegation property can be modified in etc/config.properties
>>or overriden in etc/custom.properties.
> I have checked it, but it seems they can only allow I to define
>: Re: How about to to facilitate to use JNDI(boot delegation) in karaf?
>The boot delegation property can be modified in etc/config.properties
>or overriden in etc/custom.properties.
I have checked it, but it seems they can only allow I to define additional
exportable package of boot class loade
I think pax-exam has its own features parser, so it may have been kept
behing what karaf provides.
We really need to use a schema and version that to be able to detect
such problems more easily.
On Fri, Nov 5, 2010 at 10:17, Andreas Gies wrote:
> Hello,
>
> I am sorry if am hitting the wrong list
The boot delegation property can be modified in etc/config.properties
or overriden in etc/custom.properties.
Can you give a bit more detail on how to use JNDI ? I'm not sure to
understand why the package is used but not directly referenced.
On Fri, Nov 5, 2010 at 10:35, ext2 wrote:
> Hi:
>
Hi:
When I using jndi in osgi, the "javax.naming" package is required.
But because "javax.naming" package is not direct refereced in the java's
source code(; So the generated bundle's Import-Package header doesn't
contains "javax.naming" package;
Although the karaf's etc/jre.proper
Hello,
I am sorry if am hitting the wrong list with my question, but it seemed
a good starting point for me ...
We have started the development of a karaf based application and wnat to
exploit the features support
for packaging. In my features I have the following:
mvn:org.apache.de
20 matches
Mail list logo
