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
service, if it's already running it should shut it down first (given the
absence of a @Modified)? (So there is, I imagine, no mileage in my
adding a @Modified that does nothing?)
(3) or at least put out a FATAL error message saying "hey, I wanted to
start this thing but discovered to my astonishment that it was already
running"?
(4) so it looks to me like the lifecycle control is fundamentally
broken: I don't really know anything about this stuff but I would have
expected something as basic as component lifecycle to be at a much lower
level than any configuration layer?
At present we haven't decided how to address the apparent
incompatibilities between bndtools and Karaf, of which the configurer
only appears to be one, so for the time being I'm still trying to build
with bndtools and deploy to Karaf. I do think we're likely, in the end,
to prefer the Karaf approach to configuration, where Ops can reconfigure
a system in the field by editing an etc/*.cfg file - they obviously
won't be editing a configuration.json file that's buried inside a jar.
Last time I tried to remove the enRoute configurer bundle some other
dependency broke (or was that what caused the resolver to break with
"impossible error, can't happen"? - so many things going wrong, can't
remember all the details), but if I can summon up the courage to go
round that loop yet again I might give it another go.
Thanks.
On 23/11/2016 14:38, Christian Schneider wrote:
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 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" <t...@telensa.com
<mailto:t...@telensa.com>>:
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 which
crashes because the port is in use).
There may be a hint that this is connected to the processing of
configuration.json, even though there is nothing in
configuration.json for this particular @Component.
Any ideas?
When I shut down the system some time later there *are* two
calls to the @Deactivate method logged, which suggests that it
is being called and the logging is working. If I leave out the
"immediate=true" there are no calls to @Activate.
--
Tim Ward
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
--
Tim Ward
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
