;
> Regards
> Daghan
>
> Sent by MailWise <http://www.mail-wise.com/installation/2> – See your
> emails as clean, short chats.
>
>
> ---- Original Message ----
> From: Raymond Auge <raymond.a...@liferay.com>
> Sent: Thursday, November 24, 2016 03:49 AM
&g
In this particular case removing scr from Karaf is OK because there is
nothing in it that needs it. That would not be a universal solution though.
Same thing with deploying through agent - works perfect in such experiment
green field cases but that's likely not how one would deploy in big
On Wed, Nov 23, 2016 at 11:35 AM, Christian Schneider
wrote:
> Good question. I think one issue with not installing the scr feature is that
> you do not have the scr karaf commands.
> Apart from that not installing the scr feature would make it easier for
> bndtools
Good question. I think one issue with not installing the scr feature is
that you do not have the scr karaf commands.
Apart from that not installing the scr feature would make it easier for
bndtools users.
Maybe you can create a pull request on the documentation and discuss
with the
On 23/11/2016 16:26, Peter Kriens wrote:
I have no idea how you deploy? Do you use the bnd agent?
Right click on debug.bndrun and choose Debug As / Bnd Native Launcher
where the relevant bit of debug.bndrun (I think) is
-runpath: biz.aQute.remote.launcher
-runremote: test;\
shell =
OK, so if I feature:uninstall scr from Karaf I can let Resolve do its
thing and everything works.
Is that an error in
http://enroute.osgi.org/appnotes/bndtools-and-karaf.html
then?
On 23/11/2016 16:23, Christian Schneider wrote:
-runfw just sets the OSGi framework. Karaf basically also does
I have no idea how you deploy? Do you use the bnd agent?
It might work if you add scr (and other bundles provided by Karaf) to the
-runpath. The bnd resolver context analyzes the -runpath for capabilities and
exported packages and adds these to the system environment. The resolver will
then
-runfw just sets the OSGi framework. Karaf basically also does this
inside when you can choose between felix and equinox but karaf is a lot
more than that.
So correctly setting up bndtools for karaf as a runtime will involve a
lot more than -rnfw.
I think there currently is not complete
I was sort-of guessing that that's what -runfw was about, but didn't
find enough documentation to be able to understand it. Via monkey-see
monkey-do cut-and-paste I've ended up with
-runfw: org.apache.felix.framework;version='[5.6.1,5.6.1]'
which clearly does NOT tell it "you are running on
On Wed, Nov 23, 2016 at 11:06 AM, Timothy Ward wrote:
> Isn’t this exactly what enRoute was trying to do with the distros?
>
Correct, but somehow we need to make it simpler to accomplish in reality.
- Ray
>
> Regards,
>
> Tim
>
> On 23 Nov 2016, at 16:05, Raymond Auge
Isn’t this exactly what enRoute was trying to do with the distros?
Regards,
Tim
> On 23 Nov 2016, at 16:05, Raymond Auge wrote:
>
> @Peter this is exactly a scenario I'd love to be able to eliminate by
> exposing the target runtime as a repo which we can specify as
@Peter this is exactly a scenario I'd love to be able to eliminate by
exposing the target runtime as a repo which we can specify as the the BASE
for the resolver.
- Ray
On Wed, Nov 23, 2016 at 11:04 AM, Tim Ward wrote:
> So, if I manually delete
>
> org.apache.felix.scr
>
>
So, if I manually delete
org.apache.felix.scr
from -runbundles then both symptoms go away.
All I've got to do now is try to find out how to stop the Resolve button
putting it back in every time?
On 23/11/2016 15:58, Peter Kriens wrote:
That sounds a bit like scr is started twice.
Sounds?
On 23/11/2016 15:47, Timothy Ward wrote:
My next recommendation would be to bracket your activate and
deactivate methods with print statements, including the
toString/identity hash code of your component, so that you can see that:
a) The methods get called,
I believe I can tell that from the
> That sounds a bit like scr is started twice.
Sounds? Are their other possible explanations?
Kind regards,
Peter Kriens
> On 23 Nov 2016, at 16:49, Christian Schneider wrote:
>
> On 23.11.2016 16:47, Tim Ward wrote:
>> OK, doesn't look like configuration.
>>
On 23.11.2016 16:47, Tim Ward wrote:
OK, doesn't look like configuration.
- Comment out @RequireConfigureExtender
- Resolve
- Confirm that osgi.enroute.configurer.simple.provider no longer
appears in -runbundles
- Confirm that osgi.enroute.configurer.simple.provider no longer
appears in
My next recommendation would be to bracket your activate and deactivate methods
with print statements, including the toString/identity hash code of your
component, so that you can see that:
a) The methods get called,
b) The methods exit successfully
c) Which objects the methods are called on
>
OK, doesn't look like configuration.
- Comment out @RequireConfigureExtender
- Resolve
- Confirm that osgi.enroute.configurer.simple.provider no longer appears
in -runbundles
- Confirm that osgi.enroute.configurer.simple.provider no longer appears
in Karaf's "list" command
- Restart Karaf and
For your activate method, could you surround it with a try/catch on Throwable
and print a stack trace? And log in the finally log that you exit.
Can your also look in the generated bundle in OSGI-INF/ and look at the
component XML files? Look at their implementation classes. You might want to
I have seen the same thing as Peter when there is an issue in activate and
that was why I moved my thread creation out of there and asked if you were
sure it was leaving activate. Can you trying creating the thread in the
constructor without passing this and then passing the objects you need from
On 23/11/2016 15:19, Peter Kriens wrote:
DS should never call your activate twice. That said, I’ve seen the
Felix impl do this if you throw an exception from activate. It might
maybe do this when your activate does not return? However, then you
should some information from SCR in your log
On 23/11/2016 15:19, David Daniel wrote:
I am guessing you are trying to do other things and that's why your
passing this to your new thread and you are taking a config object
even if it is not being used.
I am "taking a config object even if it is not being used" simply
because I just
That was my executor code and not Tims but I did leave out a lot of code
not say that I didn't make poor choices.
On Wed, Nov 23, 2016 at 10:19 AM, Peter Kriens
wrote:
> DS should never call your activate twice. That said, I’ve seen the Felix
> impl do this if you throw
What you’re doing is fine, as long as the deactivate method stops the thread,
and blocks until it has stopped.
The activate method will only be called once by DS for a given component, two
obvious things to ask:
Are there any places in your code where calls are made to activate?
Are you sure
I am guessing you are trying to do other things and that's why your passing
this to your new thread and you are taking a config object even if it is
not being used. If you remove the config so you just have void activate(
ComponentContext cc, BundleContext bc) and use an executor or don't pass
DS should never call your activate twice. That said, I’ve seen the Felix impl
do this if you throw an exception from activate. It might maybe do this when
your activate does not return? However, then you should some information from
SCR in your log file.
If you properly end your thread in
Well, we were wondering about that, but:
(1) there is no configuration defined for this @Component either in
configuration.json or in karaf\etc, so there's no reason for either of
them to do anything with my component?
(2) surely whatever configuration service decides to (re)configure a
Three of us have now looked at this code and we can't see any issues
like that with it:
@Activate
void activate( ComponentContext cc, BundleContext bc,
Map config )
{
logger.info( "activate" );
thread = new Thread( this );
thread.start();
An issue I had with threading was that the activate function was never
completing because I had a loop waiting for the thread. I ended up moving
the thread creation out of activate and using an executor to run the thread
instead of a while loop which took the whole cpu. I also check to make
sure
If you get this: "osgi.enroute.configurer.simple.provider"
Then the configurer is still active.
Christian
On 23.11.2016 15:37, Tim Ward wrote:
No difference. It still activates my @Component twice, with no
deactivation in between, so I start two threads and one of them crashes.
2016-11-23
If you use karaf then I think the problem is that enroute configurer as
well as the karaf set of fileinstall and config admin might produce two
configs for you component.
Can you try to remove the configurer bundle?
Christian
On 23.11.2016 15:08, Tim Ward wrote:
Do you mean delete karaf\data
No difference. It still activates my @Component twice, with no
deactivation in between, so I start two threads and one of them crashes.
2016-11-23 14:35:42,487 | INFO | pool-37-thread-3 |
provider | 73 -
osgi.enroute.configurer.simple.provider - 2.0.0.201610141744 |
I don't know how it looks like in karaf, but probably yes
Am 23.11.2016 15:09 schrieb "Tim Ward" :
> Do you mean delete karaf\data and start all over again? - no, I haven't
> tried that.
>
> On 23/11/2016 13:38, Dirk Fauth wrote:
>
> Have you cleared the bundle cache in
Do you mean delete karaf\data and start all over again? - no, I haven't
tried that.
On 23/11/2016 13:38, Dirk Fauth wrote:
Have you cleared the bundle cache in between?
Am 23.11.2016 13:42 schrieb "Tim Ward" >:
I have a @Component with
Have you cleared the bundle cache in between?
Am 23.11.2016 13:42 schrieb "Tim Ward" :
> I have a @Component with immediate=true which fires up a thread in its
> @Activate to listen on a socket. The @Deactivate, if it were ever called,
> would kill the thread.
>
> What I appear
35 matches
Mail list logo