Re: [osgi-dev] DS & Concurrency

Excellent article Peter! Very helpful. Thanks for sharing. Erwin > On Nov 23, 2016, at 10:06, Peter Kriens wrote: > > I’ve just created an app note about DS and concurrent patterns: > > http://enroute.osgi.org/appnotes/concurrency.html >

Re: [osgi-dev] Universal purpose of Configuration Admin new functions

On 22.11.2016 21:19, Balázs Zsoldos wrote: The focus is not on webconsole here or on any tools. Webconsole uses the current API and this is true for everything else that creates configuration at the moment. The other thing I wanted to highlight here: It is much more comfortable to create

Re: [osgi-dev] Component being activated twice?

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

Re: [osgi-dev] Component being activated twice?

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

[osgi-dev] Component being activated twice?

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 to be seeing is that the @Activate is called twice with no call to @Deactivate (so I get two threads, one of

Re: [osgi-dev] Component being activated twice?

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

Re: [osgi-dev] Component being activated twice?

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

Re: [osgi-dev] Component being activated twice?

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

Re: [osgi-dev] Component being activated twice?

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

Re: [osgi-dev] Component being activated twice?

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 >

Re: [osgi-dev] Component being activated twice?

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

Re: [osgi-dev] Component being activated twice?

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

Re: [osgi-dev] Component being activated twice?

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

Re: [osgi-dev] Component being activated twice?

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

Re: [osgi-dev] DS & Concurrency

Hi Peter, I've read about 1/4 of the document so far (if only I had more time) and so far I like it. As you've already found this is a much needed piece of work. We (Liferay) struggle with this in our company to a high degree to the point that we have many source formatting checks/rules in place

Re: [osgi-dev] Component being activated twice?

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 |

[osgi-dev] DS & Concurrency

I’ve just created an app note about DS and concurrent patterns: http://enroute.osgi.org/appnotes/concurrency.html Feedback appreciated, kind regards, Peter Kriens smime.p7s Description: S/MIME cryptographic signature

Re: [osgi-dev] Component being activated twice?

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

Re: [osgi-dev] Component being activated twice?

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

Re: [osgi-dev] Component being activated twice?

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

Re: [osgi-dev] Component being activated twice?

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();

Re: [osgi-dev] Component being activated twice?

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

Re: [osgi-dev] Component being activated twice?

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

Re: [osgi-dev] Component being activated twice?

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

Re: [osgi-dev] Component being activated twice?

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

Re: [osgi-dev] Component being activated twice?

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

Re: [osgi-dev] Component being activated twice?

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

Re: [osgi-dev] DS & Concurrency

Feel free to add a section with such rules … Though I am not a fan of them because they tend to be in the way when I am thinking and are too often not that useful for experienced people; I prefer good code reviews. Kind regards, Peter Kriens > On 23 Nov 2016, at 16:47, Raymond Auge

Re: [osgi-dev] Component being activated twice?

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?

Re: [osgi-dev] Component being activated twice?

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

Re: [osgi-dev] Component being activated twice?

-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

Re: [osgi-dev] Component being activated twice?

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

Re: [osgi-dev] Component being activated twice?

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

Re: [osgi-dev] Component being activated twice?

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

Re: [osgi-dev] Component being activated twice?

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

Re: [osgi-dev] Component being activated twice?

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

Re: [osgi-dev] Component being activated twice?

@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 > >

Re: [osgi-dev] Component being activated twice?

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 =

Re: [osgi-dev] Component being activated twice?

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

Re: [osgi-dev] Component being activated twice?

> 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. >>

Re: [osgi-dev] DS & Concurrency

On Wed, Nov 23, 2016 at 11:00 AM, Peter Kriens wrote: > Feel free to add a section with such rules … Though I am not a fan of them > because they tend to be in the way when I am thinking and are too often not > that useful for experienced people; I prefer good code

Re: [osgi-dev] DS & Concurrency

Hi Peter I saw it on twitter it is very welcomed article. An initial scan is very promising. I will read in full and possibly add some things about locks and latches. I did much of it with bluetooth protocol and they are hopefully correct :) Cheers Daghan Sent by

Re: [osgi-dev] notion of "provided" scope for build time resolver

And it was not documented because I never had the time to test it (and document it.) I only wrote it :-( Kind regards, Peter Kriens > On 23 Nov 2016, at 22:48, Raymond Auge wrote: > > I never said it was documented! ;) > >

[osgi-dev] notion of "provided" scope for build time resolver

I didn't want to highjack the "Component being activated twice?" thread so decided to start a new one. Regarding the "*-distro*" instruction - I don't seam to find any info about it. I assume this was simply an idea Ray proposed and not something that exist and need to be improved? Please correct

Re: [osgi-dev] notion of "provided" scope for build time resolver

-distro: is an existing bnd instruction implemented by Peter. - Ray On Wed, Nov 23, 2016 at 4:22 PM, Milen Dyankov wrote: > I didn't want to highjack the "Component being activated twice?" thread so > decided to start a new one. > > Regarding the "*-distro*" instruction

Re: [osgi-dev] notion of "provided" scope for build time resolver

not according to http://bnd.bndtools.org/chapters/825-instructions-ref.html :) On Wed, Nov 23, 2016 at 10:42 PM, Raymond Auge wrote: > -distro: is an existing bnd instruction implemented by Peter. > > - Ray > > On Wed, Nov 23, 2016 at 4:22 PM, Milen Dyankov

Re: [osgi-dev] notion of "provided" scope for build time resolver

I never said it was documented! ;) https://github.com/bndtools/bnd/blob/master/biz.aQute.resolve/src/biz/aQute/resolve/BndrunResolveContext.java#L167 On Wed, Nov 23, 2016 at 4:45 PM, Milen Dyankov wrote: > not according to