Webconsole vs. httplite, take 2

[Benson Margulies]

So, I fixed a little issue in httplite with dates, and now I'm seeing
that the script console is all messed up because of a mismatch in
urlencoding. I don't suppose that anyone has a clue as to why with
httplite there is this urlencoding that presumably doesn't happen with
the larger http variations?

javax.script.ScriptException: org.jruby.embed.ParseFailedException:
(SyntaxError) 

Is this a problem in webconsole or httplite?

[Benson Margulies]

I succeeded in combining webconsole with jetty by using 'httplite'.
The only issue is that the script console fails as follows. Anyone
have a sense of whether this is httplite failing to parse the date, or
webconsole sending a bogus date?

[ERROR] 2016-11-17 11:48:42.322 [5]
org.apache.felix.httplite.complete.0.1.4 - [Unknown]Connection close
due to unknown reason.
java.lang.IllegalArgumentException: Unable to convert to date: Thu, 17
Nov 2016 19:32:46 GMT
at 
org.apache.felix.httplite.servlet.HttpServletRequestImpl.getDateHeader(HttpServletRequestImpl.java:829)
~[org.apache.felix-org.apache.felix.httplite.complete-0.1.4.jar:?]
at 
javax.servlet.http.HttpServletRequestWrapper.getDateHeader(HttpServletRequestWrapper.java:71)
~[org.apache.felix-org.apache.felix.httplite.complete-0.1.4.jar:?]
at 
org.apache.felix.webconsole.AbstractWebConsolePlugin.spoolResource0(AbstractWebConsolePlugin.java:579)
~[?:?]
at 
org.apache.felix.webconsole.AbstractWebConsolePlugin$1.run(AbstractWebConsolePlugin.java:526)
~[?:?]
at java.security.AccessController.doPrivileged(Native Method) ~[?:1.8.0_60]
at 
org.apache.felix.webconsole.AbstractWebConsolePlugin.spoolResource(AbstractWebConsolePlugin.java:521)
~[?:?]
at 
org.apache.felix.webconsole.AbstractWebConsolePlugin.doGet(AbstractWebConsolePlugin.java:181)
~[?:?]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
~[org.apache.felix-org.apache.felix.httplite.complete-0.1.4.jar:?]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
~[org.apache.felix-org.apache.felix.httplite.complete-0.1.4.jar:?]
at 
org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:567)
~[?:?]
at 
org.apache.felix.webconsole.internal.servlet.OsgiManager$3.run(OsgiManager.java:465)
~[?:?]
at java.security.AccessController.doPrivileged(Native Method) ~[?:1.8.0_60]
at 
org.apache.felix.webconsole.internal.servlet.OsgiManager.service(OsgiManager.java:461)
~[?:?]
at 
org.apache.felix.httplite.server.ServletHandler.handle(ServletHandler.java:80)
~[org.apache.felix-org.apache.felix.httplite.complete-0.1.4.jar:?]
at org.apache.felix.httplite.server.Connection.process(Connection.java:246)
~[org.apache.felix-org.apache.felix.httplite.complete-0.1.4.jar:?]

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Why does Felix HTTP export jetty?

[Benson Margulies]

It seems to me that Felix HTTP should either depend on the usual Jetty
osgi bundles, or leave Jetty private (or do the usual 'import your
exports to allow overriding?). Instead, it exports jetty packages. I'm
failing to combine plain jetty and felix http in the same deployment,
due to an exception I'll paste below.

This results from using the 'combined' bundle. If I use the
individuals, I don't get this error, but I don't get a working
environment.

[ERROR] 2016-11-17 07:01:14.689 [FelixDispatchQueue]
com.basistech.ws.osgilauncher.RosapiOsgiLauncher - Framework ERROR
event org.osgi.framework.FrameworkEvent[source=org.apache.felix.http.bundle
[62]]
org.osgi.framework.BundleException: Activator start error in bundle
org.apache.felix.http.bundle [62].
at org.apache.felix.framework.Felix.activateBundle(Felix.java:2276)
~[org.apache.felix.framework-5.6.1.jar:?]
at org.apache.felix.framework.Felix.startBundle(Felix.java:2144)
~[org.apache.felix.framework-5.6.1.jar:?]
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1371)
~[org.apache.felix.framework-5.6.1.jar:?]
at 
org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
~[org.apache.felix.framework-5.6.1.jar:?]
at java.lang.Thread.run(Thread.java:745) [?:1.8.0_60]
Caused by: java.lang.LinkageError: loader constraint violation: when
resolving method
"org.eclipse.jetty.server.Server.addLifeCycleListener(Lorg/eclipse/jetty/util/component/LifeCycle$Listener;)V"
the class loader (instance of
org/apache/felix/framework/BundleWiringImpl$BundleClassLoaderJava5) of
the current class, org/apache/felix/http/jetty/internal/JettyService,
and the class loader (instance of
org/apache/felix/framework/BundleWiringImpl$BundleClassLoaderJava5)
for the method's defining class,
org/eclipse/jetty/util/component/AbstractLifeCycle, have different
Class objects for the type
org/eclipse/jetty/util/component/LifeCycle$Listener used in the
signature
at 
org.apache.felix.http.jetty.internal.JettyService.initializeJetty(JettyService.java:240)
~[?:?]
at 
org.apache.felix.http.jetty.internal.JettyService.startJetty(JettyService.java:199)
~[?:?]
at 
org.apache.felix.http.jetty.internal.JettyService.start(JettyService.java:132)
~[?:?]
at 
org.apache.felix.http.jetty.internal.JettyActivator.doStart(JettyActivator.java:29)
~[?:?]
at 
org.apache.felix.http.base.internal.AbstractActivator.start(AbstractActivator.java:41)
~[?:?]
at 
org.apache.felix.http.bundle.internal.CombinedActivator.start(CombinedActivator.java:56)
~[?:?]
at 
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697)
~[org.apache.felix.framework-5.6.1.jar:?]
at org.apache.felix.framework.Felix.activateBundle(Felix.java:2226)
~[org.apache.felix.framework-5.6.1.jar:?]
... 4 more

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Remote shell?

[Benson Margulies]

That got me to:

java.lang.NullPointerException
at java.util.Objects.requireNonNull(Objects.java:203)
at org.jline.reader.impl.LineReaderImpl.(LineReaderImpl.java:262)
at org.jline.reader.LineReaderBuilder.build(LineReaderBuilder.java:90)
at org.apache.felix.gogo.jline.Shell.gosh(Shell.java:297)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.apache.felix.gogo.runtime.Reflective.invoke(Reflective.java:136)
at org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:82)
at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:548)
at org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:474)
at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:363)
at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:417)
at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:227)
at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

Let me try adding the non-jline bundle, but I really want jline for local usage.


On Thu, Nov 17, 2016 at 1:19 AM, Benson Margulies <bimargul...@gmail.com> wrote:
> Caused by: java.lang.ClassNotFoundException: *** Class
> 'org.apache.felix.service.command.CommandProcessor' was not found
> because bundle org.apache.felix.shell.remote [210] does not import
> 'org.apache.felix.service.command' even though bundle
> [org.apache.felix.gogo.runtime [6](R 6.0)] osgi.wiring.package;
> {bundle-symbolic-name=org.apache.felix.gogo.runtime,
> bundle-version=1.0.0, version=1.0.0,
> osgi.wiring.package=org.apache.felix.service.command} does export it.
> To resolve this issue, add an import for
> 'org.apache.felix.service.command' to bundle
> org.apache.felix.shell.remote [210]. ***
>
> So, there's a dynamic import there. Maybe I just need to remove
> 'provisional' from it?
>
>
> On Thu, Nov 17, 2016 at 1:09 AM, Benson Margulies <bimargul...@gmail.com> 
> wrote:
>> Any chance of a remote shell release that supports 1.0.0 of the rest of gogo?
>>
>> I could make some commits, but it's not neighborhood I've been seen in.

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Remote shell?

[Benson Margulies]

Caused by: java.lang.ClassNotFoundException: *** Class
'org.apache.felix.service.command.CommandProcessor' was not found
because bundle org.apache.felix.shell.remote [210] does not import
'org.apache.felix.service.command' even though bundle
[org.apache.felix.gogo.runtime [6](R 6.0)] osgi.wiring.package;
{bundle-symbolic-name=org.apache.felix.gogo.runtime,
bundle-version=1.0.0, version=1.0.0,
osgi.wiring.package=org.apache.felix.service.command} does export it.
To resolve this issue, add an import for
'org.apache.felix.service.command' to bundle
org.apache.felix.shell.remote [210]. ***

So, there's a dynamic import there. Maybe I just need to remove
'provisional' from it?


On Thu, Nov 17, 2016 at 1:09 AM, Benson Margulies <bimargul...@gmail.com> wrote:
> Any chance of a remote shell release that supports 1.0.0 of the rest of gogo?
>
> I could make some commits, but it's not neighborhood I've been seen in.

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Remote shell?

[Benson Margulies]

Any chance of a remote shell release that supports 1.0.0 of the rest of gogo?

I could make some commits, but it's not neighborhood I've been seen in.

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: webconsole and felix http not getting along.

[Benson Margulies]

Thanks to inspect, I ee that that the http service offers itself
twice, once on each port. In fact, it is not listening on 8080.

org.apache.felix.http.jetty [66] provides:
--
service; org.osgi.service.metatype.MetaTypeProvider with properties:
   metatype.pid = org.apache.felix.http
   service.bundleid = 66
   service.description = Metatype provider for Jetty Http Service
   service.id = 70
   service.scope = bundle
   service.vendor = The Apache Software Foundation
   Used by:
  org.apache.felix.metatype [7]
service; org.osgi.service.http.HttpService,
org.apache.felix.http.api.ExtHttpService with properties:
   org.apache.felix.http.enable = true
   org.apache.felix.https.enable = false
   org.osgi.service.http.port = 8080
   org.osgi.service.http.port.secure = 8443
   osgi.http.endpoint = http://10.1.224.6:8080/, http://172.16.2.223:8080/
   osgi.http.service.endpoints = http://10.1.224.6:8080/,
http://172.16.2.223:8080/
   service.bundleid = 66
   service.id = 71
   service.scope = bundle
service; org.osgi.service.http.runtime.HttpServiceRuntime with properties:
   org.apache.felix.http.enable = true
   org.apache.felix.https.enable = false
   org.osgi.service.http.port = 8080
   org.osgi.service.http.port.secure = 8443
   osgi.http.endpoint = http://10.1.224.6:8080/, http://172.16.2.223:8080/
   osgi.http.service.id = [71]
   service.bundleid = 66
   service.id = 72
   service.scope = singleton
service; org.osgi.service.http.context.ServletContextHelper with properties:
   osgi.http.whiteboard.context.name = default
   osgi.http.whiteboard.context.path = /
   service.bundleid = 66
   service.id = 73
   service.ranking = -2147483648
   service.scope = bundle
   Used by:
  org.apache.felix.http.jetty [66]
service; javax.servlet.Servlet with properties:
   felix.webconsole.configprinter.modes = always
   felix.webconsole.label = httpservice
   felix.webconsole.title = HTTP Service
   service.bundleid = 66
   service.description = HTTP Service Web Console Plugin
   service.id = 74
   service.scope = singleton
   service.vendor = Apache Software Foundation
service; org.osgi.service.cm.ManagedService with properties:
   service.bundleid = 66
   service.id = 75
   service.pid = org.apache.felix.http
   service.scope = bundle
   Used by:
  org.apache.felix.metatype [7]
  org.apache.felix.configadmin [4]
service; org.apache.felix.http.jetty.LoadBalancerCustomizerFactory
with properties:
   service.bundleid = 66
   service.description = Load Balancer Customizer Factory for Jetty Http Service
   service.id = 76
   service.scope = bundle
   service.vendor = The Apache Software Foundation
service; org.osgi.service.cm.ManagedServiceFactory with properties:
   service.bundleid = 66
   service.id = 77
   service.pid = org.apache.felix.http
   service.scope = singleton
   Used by:
  org.apache.felix.metatype [7]
service; org.osgi.service.http.HttpService,
org.apache.felix.http.api.ExtHttpService with properties:
   org.apache.felix.http.enable = true
   org.apache.felix.https.enable = false
   org.osgi.service.http.port = 8183
   org.osgi.service.http.port.secure = 8443
   osgi.http.endpoint = http://10.1.224.6:8182/, http://172.16.2.223:8182/
   osgi.http.service.endpoints = http://10.1.224.6:8182/,
http://172.16.2.223:8182/
   service.bundleid = 66
   service.id = 78
   service.scope = bundle
service; org.osgi.service.http.runtime.HttpServiceRuntime with properties:
   org.apache.felix.http.enable = true
   org.apache.felix.https.enable = false
   org.osgi.service.http.port = 8183
   org.osgi.service.http.port.secure = 8443
   osgi.http.endpoint = http://10.1.224.6:8182/, http://172.16.2.223:8182/
   osgi.http.service.id = [78]
   service.bundleid = 66
   service.id = 79
   service.scope = singleton
service; org.osgi.service.http.context.ServletContextHelper with properties:
   osgi.http.whiteboard.context.name = default
   osgi.http.whiteboard.context.path = /
   service.bundleid = 66
   service.id = 80
   service.ranking = -2147483648
   service.scope = bundle
service; javax.servlet.Servlet with properties:
   felix.webconsole.configprinter.modes = always
   felix.webconsole.label = httpservice
   felix.webconsole.title = HTTP Service
   service.bundleid = 66
   service.description = HTTP Service Web Console Plugin
   service.id = 81
   service.scope = singleton
   service.vendor = Apache Software Foundation

On Wed, Nov 16, 2016 at 8:10 AM, Benson Margulies <bimargul...@gmail.com> wrote:
> I've got the latest version of Felix HTTP and the web console loaded
> in 5.6.1 of the framework.
>
> The web console's tracker is never notified of the HTTP service.
>
> I note that the HTTP service first starts on 8080, then notices the
> config admin config, shuts down 8080, and starts where desired. This
> is, however, probably not what's causing the problem.
>
> I wonder if I've managed to get two different bundles to export 

webconsole and felix http not getting along.

[Benson Margulies]

I've got the latest version of Felix HTTP and the web console loaded
in 5.6.1 of the framework.

The web console's tracker is never notified of the HTTP service.

I note that the HTTP service first starts on 8080, then notices the
config admin config, shuts down 8080, and starts where desired. This
is, however, probably not what's causing the problem.

I wonder if I've managed to get two different bundles to export the
http service interface somehow; using the stock gogo commands, is
there any way to explore that?

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

servlet API and Felix HTTP

[Benson Margulies]

rg.osgi.framework.BundleException: Unable to resolve
org.apache.felix.http.jetty [65](R 65.0): missing requirement
[org.apache.felix.http.jetty [65](R 65.0)] osgi.contract;
(&(osgi.contract=JavaServlet)(version=3.1)) Unresolved requirements:
[[org.apache.felix.http.jetty [65](R 65.0)] osgi.contract;
(&(osgi.contract=JavaServlet)(version=3.1))]

But I have this bundle:

javax.servlet/javax.servlet-api/3.1.0

Do I also need the felix http servlet API bundle?

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Shutdown oddities with Gogo 1.0.0

[Benson Margulies]

Here is felix 5.6.1 with gogo.


Welcome to Apache Felix Gogo

g! lb
   11:12:55
START LEVEL 1
   ID|State  |Level|Name
0|Active |0|System Bundle (5.6.1)|5.6.1
1|Active |1|JLine (3.0.0)|3.0.0
2|Active |1|Apache Felix Bundle Repository (2.0.8)|2.0.8
3|Active |1|Apache Felix Gogo Command (1.0.0)|1.0.0
4|Active |1|Apache Felix Gogo JLine Shell (1.0.0)|1.0.0
5|Active |1|Apache Felix Gogo Runtime (1.0.0)|1.0.0


g! exit 0
   11:12:45
g!
g!
g!
g!
g! !!! FAILED TO STOP EXECUTOR !!!

If I "control-D", I get an unhappy backtrace on the way out, but not always:

gosh: stopping framework
gogo: unable to create consoleInterruptedIOException: Command interrupted
java.io.InterruptedIOException: Command interrupted
at org.jline.utils.ExecHelper.exec(ExecHelper.java:43)
at org.jline.terminal.impl.ExecPty.doGetConfig(ExecPty.java:158)
at org.jline.terminal.impl.ExecPty.getAttr(ExecPty.java:86)
at org.jline.terminal.impl.ExecPty.setAttr(ExecPty.java:92)
at 
org.jline.terminal.impl.AbstractPosixTerminal.close(AbstractPosixTerminal.java:63)
at org.jline.terminal.impl.PosixSysTerminal.close(PosixSysTerminal.java:85)
at org.apache.felix.gogo.jline.Activator.doStartShell(Activator.java:159)
at org.apache.felix.gogo.jline.Activator.lambda$startShell$0(Activator.java:106)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.InterruptedException
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:502)
at java.lang.UNIXProcess.waitFor(UNIXProcess.java:396)
at org.jline.utils.ExecHelper.waitAndCapture(ExecHelper.java:63)
at org.jline.utils.ExecHelper.exec(ExecHelper.java:36)
... 8 more

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

webconsole and log service

[Benson Margulies]

I have the osgi-over-slf4j log service in place, but the web console
tells me I have no log service. What is the web console looking for?

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

How does Gogo decide whether to grab the terminal and get to work?

[Benson Margulies]

I've got an application in which I want to start the shell (or not)
depending on the value of a property. What's the intended mechanism
for this? Should I explicitly start and stop the gogo shell bundle?

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Setting a felix logger

[Benson Margulies]

To use my own org.apache.felix.framework.Logger, do I really need to
abuse the Framework startup properties to put an instance of this
class into the value of a Map?

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Whatever you do, don't put configadmin in the classpath of Felix itself!

[Benson Margulies]

I just made an interesting discovery.

If you have the Felix config admin jar in your classpath along with
the 5.4.0 framework, SCR won't notice config admin events.

To be more careful and precise:

If you have a pax-exam test, and you provision CA and SCR into the
container, but also have CA in the 'outer' classpath, the above bad
thing happened.

How does one come to do this? By using the alta-maven-plugin to
arrange provisioning from dependencies.

How does one avoid this (other than finding a solution other than
alta)? The configuration below.

Aside from posting this as a caution to others, I wonder if the
maintainers of any of this find this surprising. I am surprised that
putting this stuff in the classpath next to the container has any
effect at all.



org.apache.felix:org.apache.felix.configadmin

org.apache.felix:org.apache.felix.scr


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Felix/CM/DS mystery

[Benson Margulies]

I said I'd be quiet unless I found an explanation -- and I did.
Removing this, which was a leftover from a bigger bad idea, did the
job.


   org.osgi
   osgi.cmpn
   test


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Looking for SCR debugging assistance, as usual

[Benson Margulies]

Here is another comparison that might be less work to look at. In the
working version, configuration admin gets busy, in the non-working,
not.

A working log:

13:00:13.587 [FelixStartLevel] DEBUG org.apache.felix.scr.2.0.6 -
Registering component with pid [com.basistech.ws.bus] for bundle 103
13:00:13.588 [FelixStartLevel] DEBUG r.1.4.101.201610171848 -
BundleComponentActivator : Bundle [103] ComponentHolder created for
com.basistech.ws.worker.bus.impl.BusService
13:00:13.589 [FelixStartLevel] DEBUG
org.apache.felix.configadmin.1.8.10 -
[[org.osgi.service.cm.ConfigurationAdmin]]listConfigurations(filter=(|(service.factoryPid=com.basistech.ws.bus)(service.factoryPid=com.basistech.ws.bus|rosapi-worker-bus)(service.factoryPid=com.basistech.ws.bus|rosapi-worker-bus|1.4.101.201610171848)(service.factoryPid=com.basistech.ws.bus|rosapi-worker-bus|1.4.101.201610171848|/Users/benson/x/rosapi1.5/headless/framework/../collect-bundles/target/bundles/main/rosapi-worker-bus-1.4.101-SNAPSHOT.jar)))
13:00:13.589 [FelixStartLevel] DEBUG
org.apache.felix.configadmin.1.8.10 -
[[org.osgi.service.cm.ConfigurationAdmin]]Listing configurations
matching 
(|(service.factoryPid=com.basistech.ws.bus)(service.factoryPid=com.basistech.ws.bus|rosapi-worker-bus)(service.factoryPid=com.basistech.ws.bus|rosapi-worker-bus|1.4.101.201610171848)(service.factoryPid=com.basistech.ws.bus|rosapi-worker-bus|1.4.101.201610171848|/Users/benson/x/rosapi1.5/headless/framework/../collect-bundles/target/bundles/main/rosapi-worker-bus-1.4.101-SNAPSHOT.jar))
13:00:13.589 [FelixStartLevel] DEBUG
org.apache.felix.configadmin.1.8.10 -
[[org.osgi.service.cm.ConfigurationAdmin]]listConfigurations(filter=(|(service.pid=com.basistech.ws.bus)(service.pid=com.basistech.ws.bus|rosapi-worker-bus)(service.pid=com.basistech.ws.bus|rosapi-worker-bus|1.4.101.201610171848)(service.pid=com.basistech.ws.bus|rosapi-worker-bus|1.4.101.201610171848|/Users/benson/x/rosapi1.5/headless/framework/../collect-bundles/target/bundles/main/rosapi-worker-bus-1.4.101-SNAPSHOT.jar)))
13:00:13.589 [FelixStartLevel] DEBUG
org.apache.felix.configadmin.1.8.10 -
[[org.osgi.service.cm.ConfigurationAdmin]]Listing configurations
matching 
(|(service.pid=com.basistech.ws.bus)(service.pid=com.basistech.ws.bus|rosapi-worker-bus)(service.pid=com.basistech.ws.bus|rosapi-worker-bus|1.4.101.201610171848)(service.pid=com.basistech.ws.bus|rosapi-worker-bus|1.4.101.201610171848|/Users/benson/x/rosapi1.5/headless/framework/../collect-bundles/target/bundles/main/rosapi-worker-bus-1.4.101-SNAPSHOT.jar))
13:00:13.589 [FelixStartLevel] DEBUG
org.apache.felix.configadmin.1.8.10 -
[[org.osgi.service.cm.ConfigurationAdmin]]No SecurityManager
installed; grant CONFIGURE permission on configuration bound to null
to bundle 
/Users/benson/x/rosapi1.5/headless/framework/../collect-bundles/target/bundles/main/rosapi-worker-bus-1.4.101-SNAPSHOT.jar
13:00:13.590 [FelixStartLevel] DEBUG
org.apache.felix.configadmin.1.8.10 -
[[org.osgi.service.cm.ConfigurationAdmin]]Adding configuration
com.basistech.ws.bus
13:00:13.590 [FelixStartLevel] DEBUG
org.apache.felix.configadmin.1.8.10 -
[[org.osgi.service.cm.ConfigurationAdmin]]getBundleLocation() ==> null
13:00:13.590 [FelixStartLevel] DEBUG
org.apache.felix.configadmin.1.8.10 -
[[org.osgi.service.cm.ConfigurationAdmin]]No SecurityManager
installed; grant CONFIGURE permission on configuration bound to * to
bundle 
/Users/benson/x/rosapi1.5/headless/framework/../collect-bundles/target/bundles/main/rosapi-worker-bus-1.4.101-SNAPSHOT.jar
--- and a lot of messages about supplying this to other components.

A non-working log:

08:37:01.332 [FelixStartLevel] DEBUG org.apache.felix.scr.2.0.6 -
Registering component with pid [com.basistech.ws.bus] for bundle 103
08:37:01.332 [FelixStartLevel] DEBUG org.apache.felix.scr.2.0.6 -
BundleComponentActivator : Bundle [103] ComponentHolder created for
com.basistech.ws.worker.bus.impl.BusService
08:37:01.332 [FelixStartLevel] DEBUG org.apache.felix.scr.2.0.6 -
BundleComponentActivator : Bundle [103] May enable component holder
com.basistech.ws.worker.bus.impl.BusService
08:37:01.332 [FelixStartLevel] DEBUG org.apache.felix.scr.2.0.6 -
BundleComponentActivator : Bundle [103] Enabling component holder
com.basistech.ws.worker.bus.impl.BusService
-- sorry silence --
08:37:01.334 [FelixStartLevel] DEBUG org.apache.felix.scr.2.0.6 -
Starting destruction process bundle: rosapi-worker-core/104

On Tue, Oct 18, 2016 at 12:58 PM, Benson Margulies <ben...@basistech.com> wrote:
> I have a pile of components that aren't starting because they can't
> satisfy a reference to WorkerBusService, implemented by a class named
> BusService.
>
>  At the bottom of this messages are all the SCR log messages that
> mention BusService -- not much talking about it, and then many things
> that desire it. How do I tell what is preventing BusService from
> activating? It does require a configuration PID, but:
>
> //configurat

Looking for SCR debugging assistance, as usual

[Benson Margulies]

I have a pile of components that aren't starting because they can't
satisfy a reference to WorkerBusService, implemented by a class named
BusService.

 At the bottom of this messages are all the SCR log messages that
mention BusService -- not much talking about it, and then many things
that desire it. How do I tell what is preventing BusService from
activating? It does require a configuration PID, but:

//configurationPolicy = ConfigurationPolicy.REQUIRE, configurationPid
= "com.basistech.ws.bus"

and here are the CM log events.


08:37:00.164 [CM Event Dispatcher (Fire ConfigurationEvent:
pid=com.basistech.ws.headless.config)] DEBUG
org.apache.felix.configadmin.1.8.10 -
[[org.osgi.service.cm.ConfigurationAdmin]]getConfiguration(pid=com.basistech.ws.bus,
location=null)
08:37:00.164 [CM Event Dispatcher (Fire ConfigurationEvent:
pid=com.basistech.ws.headless.config)] DEBUG
org.apache.felix.configadmin.1.8.10 -
[[org.osgi.service.cm.ConfigurationAdmin]]No SecurityManager
installed; grant CONFIGURE permission on configuration bound to * to
bundle 
/Users/benson/x/rosapi-on-premise/embedded/test/../pre-package/target/bundles/base/rosapi-headless-config-reader-1.4.101-SNAPSHOT.jar
08:37:00.164 [CM Event Dispatcher (Fire ConfigurationEvent:
pid=com.basistech.ws.headless.config)] DEBUG
org.apache.felix.configadmin.1.8.10 -
[[org.osgi.service.cm.ConfigurationAdmin]]createConfiguration(com.basistech.ws.bus,
null, null)
08:37:00.165 [CM Event Dispatcher (Fire ConfigurationEvent:
pid=com.basistech.ws.headless.config)] DEBUG
org.apache.felix.configadmin.1.8.10 -
[[org.osgi.service.cm.ConfigurationAdmin]]update(properties={licensePathname=/Users/benson/x/rosapi-on-premise/embedded/test/target/test-config/rosapi/rlp-license.xml})
08:37:00.165 [CM Event Dispatcher (Fire ConfigurationEvent:
pid=com.basistech.ws.headless.config)] DEBUG
org.apache.felix.configadmin.1.8.10 -
[[org.osgi.service.cm.ConfigurationAdmin]]Updating config
com.basistech.ws.bus with
{licensePathname=/Users/benson/x/rosapi-on-premise/embedded/test/target/test-config/rosapi/rlp-license.xml}
08:37:00.166 [CM Event Dispatcher (Fire ConfigurationEvent:
pid=com.basistech.ws.headless.config)] DEBUG
org.apache.felix.configadmin.1.8.10 -
[[org.osgi.service.cm.ConfigurationAdmin]]No
SynchronousConfigurationListeners to send CM_UPDATED event to.
08:37:00.166 [CM Event Dispatcher (Fire ConfigurationEvent:
pid=com.basistech.ws.headless.config)] DEBUG
org.apache.felix.configadmin.1.8.10 -
[[org.osgi.service.cm.ConfigurationAdmin]]Scheduling task Fire
ConfigurationEvent: pid=com.basistech.ws.bus
08:37:00.166 [CM Event Dispatcher (Fire ConfigurationEvent:
pid=com.basistech.ws.headless.config)] DEBUG
org.apache.felix.configadmin.1.8.10 -
[[org.osgi.service.cm.ConfigurationAdmin]]Scheduling task Update:
pid=com.basistech.ws.bus
08:37:00.166 [CM Event Dispatcher (Fire ConfigurationEvent:
pid=com.basistech.ws.headless.config)] DEBUG
org.apache.felix.configadmin.1.8.10 -
[[org.osgi.service.cm.ConfigurationAdmin]]UpdateConfiguration(com.basistech.ws.bus)
scheduled





  1119:08:37:01.331 [FelixStartLevel] DEBUG org.apache.felix.scr.2.0.6
- BundleComponentActivator : Bundle [103] descriptor locations
OSGI-INF/com.basistech.ws.worker.bus.impl.BusService.xml
   1121:08:37:01.332 [FelixStartLevel] DEBUG
org.apache.felix.scr.2.0.6 - BundleComponentActivator : Bundle [103]
ComponentHolder created for
com.basistech.ws.worker.bus.impl.BusService
   1122:08:37:01.332 [FelixStartLevel] DEBUG
org.apache.felix.scr.2.0.6 - BundleComponentActivator : Bundle [103]
May enable component holder
com.basistech.ws.worker.bus.impl.BusService
   1123:08:37:01.332 [FelixStartLevel] DEBUG
org.apache.felix.scr.2.0.6 - BundleComponentActivator : Bundle [103]
Enabling component holder com.basistech.ws.worker.bus.impl.BusService


   1246:08:37:01.349 [FelixStartLevel] DEBUG
org.apache.felix.scr.2.0.6 -
[com.basistech.ws.worker.flinx.FlinxComponentService(-1)] Dependency
Manager created
BusConfiguredinterface=com.basistech.ws.worker.api.WorkerBusService,
filter=null, policy=static, cardinality=1..1, bind=setBusConfigured,
unbind=null, updated=null, field=null, field-option=null,
field-collection-type=null
   1260:08:37:01.349 [FelixStartLevel] DEBUG
org.apache.felix.scr.2.0.6 -
[com.basistech.ws.worker.flinx.FlinxComponentService(11)] New service
tracker for BusConfigured, initial active: false, previous references:
{}, classFilter:
(objectClass=com.basistech.ws.worker.api.WorkerBusService),
eventFilter null, initialReferenceFilter
(objectClass=com.basistech.ws.worker.api.WorkerBusService)
   1262:08:37:01.349 [FelixStartLevel] DEBUG
org.apache.felix.scr.2.0.6 - classNameFilter:
(objectClass=com.basistech.ws.worker.api.WorkerBusService) event
filter: null
   1304:08:37:01.354 [FelixStartLevel] DEBUG
org.apache.felix.scr.2.0.6 -
[com.basistech.ws.worker.rbl.BaseLinguisticsComponentServiceImpl(-1)]
Dependency Manager created
BusConfiguredinterface=com.basistech.ws.worker.api.WorkerBusService,

Re: Unhappy log message from felix DS/CM, what is is trying to tell me?

[Benson Margulies]

I got rid of it by adding in the metatype bundle. I'll go have a look
and see if the level could be turned down to 'info'.


On Sat, Oct 8, 2016 at 11:58 PM, David Jencks
<david_jen...@yahoo.com.invalid> wrote:
> It shouldn’t be error for sure.  It just says the metatype spec classes 
> aren’t available so it can’t register the ManagedService that also implements 
> MetatypeProvider, so it’s just registering a ManagedService that doesn’t 
> implement MetatypeProvider.  Does info level seem appropriate?
>
> thanks
> david jencks
>
>> On Oct 7, 2016, at 7:30 AM, Benson Margulies <ben...@basistech.com> wrote:
>>
>> What is this about? I have DS and CM in my container.
>>
>> [java] ERROR: Cannot create MetaType providing ManagedService;
>> not providing Metatype information but just accepting configuration
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Does SCR have to start before the bundles with services?

[Benson Margulies]

On Thu, Sep 29, 2016 at 2:34 AM, David Jencks
<david_jen...@yahoo.com.invalid> wrote:
> Neither this nor restarting the framework should cause problems.
>
> Can you come up with a self contained demonstration of this (no components) 
> behavior?  I vaguely recall someone having a similar problem that I couldn’t 
> reproduce.

David,

First, a Maven bug caused me to use version 6.0.0 instead of version
6.0.1-SNAPSHOT, which led to wiring errors, which led to services not
starting.

Then, I discovered that if you really use the osgi-over-slf4j
connector properly, SCR produces messages at more than one logging
level, and I didn't have my logging back end configured correctly.

Working backwards, fixing the logging revealed the rest, and now all is well.
thanks,
benson



>
> thanks
> david jencks
>
>> On Sep 28, 2016, at 8:50 AM, Benson Margulies <ben...@basistech.com> wrote:
>>
>> On Wed, Sep 28, 2016 at 11:43 AM, David Jencks
>> <david_jen...@yahoo.com.invalid <mailto:david_jen...@yahoo.com.invalid>> 
>> wrote:
>>> It should work in any order.
>>
>> OK, then I've got some other problem on my hands. Does the last of
>> these three messages indicate a problem?
>>
>> 177  [FelixStartLevel] INFO  org.apache.felix.scr.2.0.6  - Starting
>> with globalExtender setting: false
>> 181  [FelixStartLevel] INFO  org.apache.felix.scr.2.0.6  -  Version = 2.0.6
>> 242  [CM Configuration Updater (ManagedService Update:
>> pid=[org.apache.felix.scr.ScrService])] ERROR
>> org.apache.felix.scr.2.0.6  - Cannot create MetaType providing
>> ManagedService; not providing Metatype information but just accepting
>> configuration
>>
>>
>>
>>
>>>
>>> david jencks
>>>
>>>> On Sep 28, 2016, at 8:28 AM, Benson Margulies <ben...@basistech.com> wrote:
>>>>
>>>> I'm trying to retrofit SCR/DS into a very dumb application that loads
>>>> some bundles and starts the framework. Everything is at the same start
>>>> level, and no @Components are ever activated.
>>>>
>>>> I have logging working; I see
>>>>
>>>> 191  [FelixStartLevel] INFO  org.apache.felix.scr.2.0.6  - Starting
>>>> with globalExtender setting: false
>>>> 195  [FelixStartLevel] INFO  org.apache.felix.scr.2.0.6  -  Version = 2.0.6
>>>>
>>>> In a more sophisticated cousin of this, I carefully start SCR and DS
>>>> at one start level, and only after they are started do I get involved
>>>> in starting the rest. I wonder: is this in fact a requirement, or
>>>> should I look for some other explanation of why the dumber app is not
>>>> activating anything.
>>>>
>>>> If I start up a container to a shell command line everything works
>>>> fine, so I can't get any diagnostic traction that way.
>>>>
>>>> -
>>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>>>> For additional commands, e-mail: users-h...@felix.apache.org
>>>>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>>> For additional commands, e-mail: users-h...@felix.apache.org
>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org 
>> <mailto:users-unsubscr...@felix.apache.org>
>> For additional commands, e-mail: users-h...@felix.apache.org 
>> <mailto:users-h...@felix.apache.org>

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Does SCR have to start before the bundles with services?

[Benson Margulies]

On Wed, Sep 28, 2016 at 11:50 AM, Benson Margulies <ben...@basistech.com> wrote:
> On Wed, Sep 28, 2016 at 11:43 AM, David Jencks
> <david_jen...@yahoo.com.invalid> wrote:
>> It should work in any order.

The only other thing I can think of is this: in the application I'm
working with, the code starts the framework, loads bundles, stops the
framework, then starts it again.

>
> OK, then I've got some other problem on my hands. Does the last of
> these three messages indicate a problem?
>
> 177  [FelixStartLevel] INFO  org.apache.felix.scr.2.0.6  - Starting
> with globalExtender setting: false
> 181  [FelixStartLevel] INFO  org.apache.felix.scr.2.0.6  -  Version = 2.0.6
> 242  [CM Configuration Updater (ManagedService Update:
> pid=[org.apache.felix.scr.ScrService])] ERROR
> org.apache.felix.scr.2.0.6  - Cannot create MetaType providing
> ManagedService; not providing Metatype information but just accepting
> configuration
>
>
>
>
>>
>> david jencks
>>
>>> On Sep 28, 2016, at 8:28 AM, Benson Margulies <ben...@basistech.com> wrote:
>>>
>>> I'm trying to retrofit SCR/DS into a very dumb application that loads
>>> some bundles and starts the framework. Everything is at the same start
>>> level, and no @Components are ever activated.
>>>
>>> I have logging working; I see
>>>
>>> 191  [FelixStartLevel] INFO  org.apache.felix.scr.2.0.6  - Starting
>>> with globalExtender setting: false
>>> 195  [FelixStartLevel] INFO  org.apache.felix.scr.2.0.6  -  Version = 2.0.6
>>>
>>> In a more sophisticated cousin of this, I carefully start SCR and DS
>>> at one start level, and only after they are started do I get involved
>>> in starting the rest. I wonder: is this in fact a requirement, or
>>> should I look for some other explanation of why the dumber app is not
>>> activating anything.
>>>
>>> If I start up a container to a shell command line everything works
>>> fine, so I can't get any diagnostic traction that way.
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>>> For additional commands, e-mail: users-h...@felix.apache.org
>>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>>

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Does SCR have to start before the bundles with services?

[Benson Margulies]

On Wed, Sep 28, 2016 at 11:43 AM, David Jencks
<david_jen...@yahoo.com.invalid> wrote:
> It should work in any order.

OK, then I've got some other problem on my hands. Does the last of
these three messages indicate a problem?

177  [FelixStartLevel] INFO  org.apache.felix.scr.2.0.6  - Starting
with globalExtender setting: false
181  [FelixStartLevel] INFO  org.apache.felix.scr.2.0.6  -  Version = 2.0.6
242  [CM Configuration Updater (ManagedService Update:
pid=[org.apache.felix.scr.ScrService])] ERROR
org.apache.felix.scr.2.0.6  - Cannot create MetaType providing
ManagedService; not providing Metatype information but just accepting
configuration




>
> david jencks
>
>> On Sep 28, 2016, at 8:28 AM, Benson Margulies <ben...@basistech.com> wrote:
>>
>> I'm trying to retrofit SCR/DS into a very dumb application that loads
>> some bundles and starts the framework. Everything is at the same start
>> level, and no @Components are ever activated.
>>
>> I have logging working; I see
>>
>> 191  [FelixStartLevel] INFO  org.apache.felix.scr.2.0.6  - Starting
>> with globalExtender setting: false
>> 195  [FelixStartLevel] INFO  org.apache.felix.scr.2.0.6  -  Version = 2.0.6
>>
>> In a more sophisticated cousin of this, I carefully start SCR and DS
>> at one start level, and only after they are started do I get involved
>> in starting the rest. I wonder: is this in fact a requirement, or
>> should I look for some other explanation of why the dumber app is not
>> activating anything.
>>
>> If I start up a container to a shell command line everything works
>> fine, so I can't get any diagnostic traction that way.
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Does SCR have to start before the bundles with services?

[Benson Margulies]

I'm trying to retrofit SCR/DS into a very dumb application that loads
some bundles and starts the framework. Everything is at the same start
level, and no @Components are ever activated.

I have logging working; I see

191  [FelixStartLevel] INFO  org.apache.felix.scr.2.0.6  - Starting
with globalExtender setting: false
195  [FelixStartLevel] INFO  org.apache.felix.scr.2.0.6  -  Version = 2.0.6

In a more sophisticated cousin of this, I carefully start SCR and DS
at one start level, and only after they are started do I get involved
in starting the rest. I wonder: is this in fact a requirement, or
should I look for some other explanation of why the dumber app is not
activating anything.

If I start up a container to a shell command line everything works
fine, so I can't get any diagnostic traction that way.

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Felix container and Java SecurityManager -- does the container always implement security

[Benson Margulies]

Thanks, that does answer my question.


On Wed, Sep 21, 2016 at 5:17 PM, Karl Pauls <karlpa...@gmail.com> wrote:
> I guess I'm not 100% sure I understand what you are asking exactly. Let me
> first try to explain what the different options are and then try to answer
> what I think you are asking.
>
> If there is a security manager installed the framework will do permission
> checks where the spec mandates it. However, assuming you didn't install the
> framework.security provider, all bundles will have AllPermission by default
> -- except, if you have set  felix.security.defaultpolicy=true. In that
> case, your security policy will be consulted for bundles as well.
>
> Hence, if you want behavior just as some ordinary library in an application
> with a security manager you probably want to _not_ install the
> framework.security provider and set felix.security.defaultpolicy=true
> (either as a -D property or as one passed to the felix constructor). That
> in turn will make it so that you _do_ get permission checks triggered from
> Felix as well as potentially from bundles which you can grant (or deny by
> omission, respectively) via your security policy.
>
> Otherwise, if you just don't want failing permission checks then, don't
> install the framework.security provider and _don't_ set
> felix.security.defaultpolicy.
> That will make it so that you _do_ get permission checks triggered from
> Felix as well as potentially from bundles but at least bundles will have
> AllPermission by default (hence, all you need to do in your policy is to
> give felix.jar and your external code that calls into Felix permissions).
>
> If, on the other hand, you don't want _any_ permission checks triggered by
> felix despite a security manage being around the answer is: no - thats not
> possible.
>
> regards,
>
> Karl
>
> On Wed, Sep 21, 2016 at 10:48 PM, Benson Margulies <ben...@basistech.com>
> wrote:
>
>> I'd like to run a Felix container as if it was just some ordinary
>> piece of an application inside of a security manager; I don't want any
>> security manager checks or behaviors from the container. Can I do
>> this, or does the container always interact with the SecurityManager
>> if there is one?
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>>
>>
>
>
> --
> Karl Pauls
> karlpa...@gmail.com

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Felix container and Java SecurityManager -- does the container always implement security

[Benson Margulies]

I'd like to run a Felix container as if it was just some ordinary
piece of an application inside of a security manager; I don't want any
security manager checks or behaviors from the container. Can I do
this, or does the container always interact with the SecurityManager
if there is one?

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Using a service tracker on ConfigurationAdmin from outside the framework

[Benson Margulies]

On Sun, Sep 18, 2016 at 3:53 PM, Neil Bartlett <njbartl...@gmail.com> wrote:
> Hmm. This indicates that previously the cm export was satisfied by another 
> bundle. Which of course it was because the Felix Config Admin implementation 
> exports that package (in addition to importing it).

Yes, felix exports 1.5 and imports [1.5,1.6). I feel as if this is
about to be one of those discussions about spec bundles that come
through here from time to time.

>
> I am a little uncomfortable relying on this. I believe it would be legal for 
> the framework to choose the export from the Config Admin bundle rather than 
> from the system bundle. Ordinarily this would be fine because the consumer 
> bundle would just wire to that export instead, but in your scenario the 
> consumer bundle IS the system bundle, which cannot import.
>
> Then again maybe the system bundle export will reliably take precedence. I’m 
> not 100% clear on this.

It was my vague impression that we all use the 'Import your Exports'
cliché just for cases like this, which would imply that the resolution
process should always prefer the non-local version. However, I have
another reason to switch at some point from accessing config admin
from my 'outside' code to pushing the bootstrap information through an
interface of my own -- I will need to pass an NIO Path in there some
day, and config admin won't allow Path objects as values, and there
are issues with serializing them as URIs. So, eventually, I'll move
this code away from whatever risk it now has.

>
> Neil
>
>
>> On 18 Sep 2016, at 20:44, Benson Margulies <ben...@basistech.com> wrote:
>>
>> As usual, the answer occurred to me moments after I pressed 'send'. I
>> neglected to specify a version for org.osgi.service.cm when adding it
>> to the system bundle export list.
>>
>> On Sun, Sep 18, 2016 at 3:18 PM, Neil Bartlett <njbartl...@gmail.com> wrote:
>>> This should work, but without a code sample it’s impossible to say what 
>>> might be going wrong.
>>>
>>> The usual pattern would be:
>>>
>>> 1. Init and start the framework
>>> 2. Install the bundles, including configadmin
>>> 3. Create and open your tracker
>>> 4. Start the bundles
>>> 5. Enter framework.waitForStop(), where you will remain.
>>>
>>> Config Admin will likely publish itself synchronously in step 4, and you 
>>> will get a callback on the tracker. Or it might publish the service 
>>> asynchronously later, which is also okay.
>>>
>>> Neil
>>>
>>>> On 18 Sep 2016, at 19:53, Benson Margulies <ben...@basistech.com> wrote:
>>>>
>>>> My current task is to set up a Felix framework behind an API. To get
>>>> actual work done, there are some interfaces in packages on the system
>>>> bundle that are published by bundles of mine, and then the code
>>>> 'outside' the framework obtains them.
>>>>
>>>> For the main service I created, this all works find with a
>>>> ServiceTracker as the tool for waiting for the code inside the
>>>> container to get around (via SCR) to publishing the service I need.
>>>>
>>>> Next, I decided that, as part of my bootstrap process, it would make
>>>> sense for me to push some configuration into ConfigurationAdmin. So, I
>>>> added the 'cmpn' jar to the outer classpath, and org.osgi.service.cm
>>>> to the system bundle, and tried to use a service tracker to obtain a
>>>> ConfigurationAdmin reference.
>>>>
>>>> 'waitForService' on the tracker waits forever.
>>>>
>>>> In the debugger, I can (eventually) obtain the ConfigurationAdmin
>>>> reference against the system bundle context. So this leads me to
>>>> believe that there's something I don't understand about threads and
>>>> Felix; I was expecting that once I started the framework, things like
>>>> activation of the ConfigurationAdmin service would happen on some
>>>> other thread, so I could have my main thread wait for it with a
>>>> ServiceTracker.
>>>>
>>>> I can give up on this ConfigurationAdmin-from-outside bootstrap in
>>>> favor of passing some properties into an interface of a service of
>>>> mine, and let _it_ negotiate with ConfigurationAdmin for me, so if
>>>> this whole approach is poor it's easy to abandon.
>>>>
>>>> -
>>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>>>&g

Re: Using a service tracker on ConfigurationAdmin from outside the framework

[Benson Margulies]

As usual, the answer occurred to me moments after I pressed 'send'. I
neglected to specify a version for org.osgi.service.cm when adding it
to the system bundle export list.

On Sun, Sep 18, 2016 at 3:18 PM, Neil Bartlett <njbartl...@gmail.com> wrote:
> This should work, but without a code sample it’s impossible to say what might 
> be going wrong.
>
> The usual pattern would be:
>
> 1. Init and start the framework
> 2. Install the bundles, including configadmin
> 3. Create and open your tracker
> 4. Start the bundles
> 5. Enter framework.waitForStop(), where you will remain.
>
> Config Admin will likely publish itself synchronously in step 4, and you will 
> get a callback on the tracker. Or it might publish the service asynchronously 
> later, which is also okay.
>
> Neil
>
>> On 18 Sep 2016, at 19:53, Benson Margulies <ben...@basistech.com> wrote:
>>
>> My current task is to set up a Felix framework behind an API. To get
>> actual work done, there are some interfaces in packages on the system
>> bundle that are published by bundles of mine, and then the code
>> 'outside' the framework obtains them.
>>
>> For the main service I created, this all works find with a
>> ServiceTracker as the tool for waiting for the code inside the
>> container to get around (via SCR) to publishing the service I need.
>>
>> Next, I decided that, as part of my bootstrap process, it would make
>> sense for me to push some configuration into ConfigurationAdmin. So, I
>> added the 'cmpn' jar to the outer classpath, and org.osgi.service.cm
>> to the system bundle, and tried to use a service tracker to obtain a
>> ConfigurationAdmin reference.
>>
>> 'waitForService' on the tracker waits forever.
>>
>> In the debugger, I can (eventually) obtain the ConfigurationAdmin
>> reference against the system bundle context. So this leads me to
>> believe that there's something I don't understand about threads and
>> Felix; I was expecting that once I started the framework, things like
>> activation of the ConfigurationAdmin service would happen on some
>> other thread, so I could have my main thread wait for it with a
>> ServiceTracker.
>>
>> I can give up on this ConfigurationAdmin-from-outside bootstrap in
>> favor of passing some properties into an interface of a service of
>> mine, and let _it_ negotiate with ConfigurationAdmin for me, so if
>> this whole approach is poor it's easy to abandon.
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Using a service tracker on ConfigurationAdmin from outside the framework

[Benson Margulies]

My current task is to set up a Felix framework behind an API. To get
actual work done, there are some interfaces in packages on the system
bundle that are published by bundles of mine, and then the code
'outside' the framework obtains them.

For the main service I created, this all works find with a
ServiceTracker as the tool for waiting for the code inside the
container to get around (via SCR) to publishing the service I need.

Next, I decided that, as part of my bootstrap process, it would make
sense for me to push some configuration into ConfigurationAdmin. So, I
added the 'cmpn' jar to the outer classpath, and org.osgi.service.cm
to the system bundle, and tried to use a service tracker to obtain a
ConfigurationAdmin reference.

'waitForService' on the tracker waits forever.

In the debugger, I can (eventually) obtain the ConfigurationAdmin
reference against the system bundle context. So this leads me to
believe that there's something I don't understand about threads and
Felix; I was expecting that once I started the framework, things like
activation of the ConfigurationAdmin service would happen on some
other thread, so I could have my main thread wait for it with a
ServiceTracker.

I can give up on this ConfigurationAdmin-from-outside bootstrap in
favor of passing some properties into an interface of a service of
mine, and let _it_ negotiate with ConfigurationAdmin for me, so if
this whole approach is poor it's easy to abandon.

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: JNI, classloaders, framework shutdown

[Benson Margulies]

On Sat, Sep 17, 2016 at 7:39 PM, David Jencks
<david_jen...@yahoo.com.invalid> wrote:
> Ah, I didn’t read your first post closely enough….. IIUC your code is loading 
> the native library, you are not using OSGI native code support?
>
> Can you modify things to use OSGI native code support?

To do that, I'd need to make about the same set of arrangements. The
code has to remain deliverable as a non-OSGi SDK. One way or the
other, I'd have to change the plumbing that calls System.load.

>
> david jencks
>
>> On Sep 17, 2016, at 4:16 PM, Benson Margulies <ben...@basistech.com> wrote:
>>
>> On Sat, Sep 17, 2016 at 7:05 PM, David Jencks
>> <david_jen...@yahoo.com.invalid <mailto:david_jen...@yahoo.com.invalid>> 
>> wrote:
>>> I have no idea what I’m talking about, but I had the vague idea that osgi 
>>> frameworks get around this by copying the native library to a new, unique, 
>>> location each time the bundle[revision] starts. The link into your local 
>>> maven repo doesn’t seem like it’s native code that’s actually in a bundle.  
>>> Do you have any idea how this path relates to your bundle containing the 
>>> native code?
>>
>> That makes a great deal of sense. In our case, the native code is not
>> in Maven at all; it's sitting in an outboard product installation
>> directory along with 100 tons of NLP models and dictionaries.
>>
>> However, I'm trying to build something that someone else embeds into
>> an arbitrary Java application (and I launch the OSGi framework for
>> them). So, getting the temporary directory into java.library.path is
>> not going to be straightforward. Options I see include simply changing
>> the filename but using the same directory, or changing the Java code
>> to know how to call System.load (which takes a pathname) instead of
>> System.loadLibrary (which looks in java.library.path).
>>
>>>
>>> david jencks
>>>
>>>> On Sep 17, 2016, at 3:57 PM, Benson Margulies <ben...@basistech.com> wrote:
>>>>
>>>> Has anyone out there succeeded shutting down the Felix container and
>>>> having the classloaders GC to the point where native classes are no
>>>> longer loaded, so that the same JVM can then start a new framework and
>>>> again load the same native classes?
>>>>
>>>> To be a bit more precise, I have a bundle that includes some native
>>>> classes. I start the framework, load and start this bundle, and it
>>>> does the System.loadLibrary to load up these classes.
>>>>
>>>> I shut down the framework, and try again, and get:
>>>>
>>>> 18:51:39.140 [Thread-4] ERROR r.1.4.0.201609171300 -
>>>> [com.basistech.ws.worker.core.Worker(8)] The activate method has
>>>> thrown an exception
>>>> java.lang.UnsatisfiedLinkError: Native Library
>>>> /Users/benson/.m2/repository/bt/rosapi/roots/native/7.14.100.0/rlp/lib/amd64-darwin11-xcode4/libbtnamesutiljni.dylib
>>>> already loaded in another classloader
>>>>
>>>> My vague sense is that it's somewhere between difficult and impossible
>>>> to get native code cleaned up enough to make this work, but I wondered
>>>> if anyone else had succeeded using Felix.
>>>>
>>>> -
>>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>>>> For additional commands, e-mail: users-h...@felix.apache.org
>>>>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>>> For additional commands, e-mail: users-h...@felix.apache.org
>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org 
>> <mailto:users-unsubscr...@felix.apache.org>
>> For additional commands, e-mail: users-h...@felix.apache.org 
>> <mailto:users-h...@felix.apache.org>

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Prop expansion via fileinstall but not configuration admin

[Benson Margulies]

On Sat, Sep 17, 2016 at 1:27 PM, David Jencks
<david_jen...@yahoo.com.invalid> wrote:
>
>> On Sep 17, 2016, at 10:16 AM, Benson Margulies <ben...@basistech.com> wrote:
>>
>> David, the only case I was concerned with is when there is a
>> pre-existing file with the syntax of my test case, which is the syntax
>> supported by fileinstall. I think that the confusion results because
>> there is some escaping convention that permits persisting a value like
>> ${foo} and reading it back, but I was not using that syntax, because I
>> was trying to move some files that were used with fileinstall in karaf
>> and use them with straight CA with plain Felix.
>
> I can’t imagine why you think that ought to work.  The persistence format for 
> a ca implementation is an entirely internal detail.  If you want a ca 
> implementation to be able to read a persisted configuration from a file, that 
> file has to have been created by that same ca implementation.

Well, for what it's worth, I can explain how my imagination got
started here. I didn't know, at first, that Karaf was using
fileinstall to read these files. I thought that CA itself was reading
them from the sort of obvious 'name=value' format. When I did enough
debugging to find the role of fileinstall in Karaf, I didn't rethink
CA.

>
>> In practical terms,
>> I've dropped in fileinstall to make progress.
>>
>> I think that my JIRA amounts to, "If you start with a file with
>> invalid syntax, CA throws the entire file away and does not log an
>> error”.
>
> Unless the file was created by the ca implementation itself, throwing it away 
> seems reasonable to me.  It does seem like an error would be appropriate 
> though.
>
> So, there might be a bug (beyond possible desirable logging), but I don’t 
> think you’ve demonstrated that yet.

I don't make any claim for any bug except a possible 'feature request'
for logging at this point.


>
> thanks
> david jencks
>
>>
>> The test class I sent along is pretty much useless except as the
>> nucleus of a test that would demand error logging from the overall CA;
>> the low level file persistence manager is working correctly, I realize
>> now, in rejecting that syntax.
>>
>> I will try to make the time to add the relevant test case (and
>> probably the fix to log the error) later in the weekend.
>>
>>
>>
>> On Sat, Sep 17, 2016 at 1:05 PM, David Jencks
>> <david_jen...@yahoo.com.invalid> wrote:
>>> Along with Carsten, I’m confused by your jira report.  What happens when 
>>> you create a configuration in code and try to update it with your property? 
>>>  Can you get it back?  There might be a problem with persisting such a 
>>> property, but your test doesn’t demonstrate it because perhaps the 
>>> persistence is encoding the value somehow.
>>>
>>> thanks
>>> david jencks
>>>
>>>> On Sep 17, 2016, at 9:59 AM, Benson Margulies <ben...@basistech.com> wrote:
>>>>
>>>> I could commit this test, which fails, if you like, with an @Ignore.
>>>>
>>>>
>>>> public class InvalidFileSyntaxTest {
>>>>   private static final String CONFIG = "rootPath=${bt.root}\n";
>>>>
>>>>   @Test
>>>>   public void testPropSyntax() throws IOException
>>>>   {
>>>>   final Dictionary dict = ConfigurationHandler.read(new
>>>> ByteArrayInputStream(CONFIG.getBytes("UTF-8")));
>>>>   assertEquals(1, dict.size());
>>>>   assertEquals("${bt.root}", dict.get("rootPath"));
>>>>   }
>>>> }
>>>>
>>>> On Sat, Sep 17, 2016 at 12:49 PM, Benson Margulies <ben...@basistech.com> 
>>>> wrote:
>>>>> On Sat, Sep 17, 2016 at 12:45 PM, David Jencks
>>>>> <david_jen...@yahoo.com.invalid> wrote:
>>>>>>
>>>>>>> On Sep 17, 2016, at 9:40 AM, Benson Margulies <ben...@basistech.com> 
>>>>>>> wrote:
>>>>>>>
>>>>>>> On Sat, Sep 17, 2016 at 3:21 AM, Carsten Ziegeler <cziege...@apache.org 
>>>>>>> <mailto:cziege...@apache.org>> wrote:
>>>>>>>>> I don’t think this belongs in ca.  You could use a 
>>>>>>>>> ConfigurationPlugin.  Unfortunately you’ll have to wait till R7 until 
>>>>>>>>> this works with DS.  Maybe Carsten already implemented the CA part, 
>>>>>>>>> but I didn’t do the DS p

Re: Prop expansion via fileinstall but not configuration admin

[Benson Margulies]

p.s. It's always possible that I'm _wrong_, and CA is logging, but I
didn't have the log service set up soon enough. That's another reason
for me to be the one to spend time trying to make a test case.


On Sat, Sep 17, 2016 at 1:16 PM, Benson Margulies <ben...@basistech.com> wrote:
> David, the only case I was concerned with is when there is a
> pre-existing file with the syntax of my test case, which is the syntax
> supported by fileinstall. I think that the confusion results because
> there is some escaping convention that permits persisting a value like
> ${foo} and reading it back, but I was not using that syntax, because I
> was trying to move some files that were used with fileinstall in karaf
> and use them with straight CA with plain Felix. In practical terms,
> I've dropped in fileinstall to make progress.
>
> I think that my JIRA amounts to, "If you start with a file with
> invalid syntax, CA throws the entire file away and does not log an
> error".
>
> The test class I sent along is pretty much useless except as the
> nucleus of a test that would demand error logging from the overall CA;
> the low level file persistence manager is working correctly, I realize
> now, in rejecting that syntax.
>
> I will try to make the time to add the relevant test case (and
> probably the fix to log the error) later in the weekend.
>
>
>
> On Sat, Sep 17, 2016 at 1:05 PM, David Jencks
> <david_jen...@yahoo.com.invalid> wrote:
>> Along with Carsten, I’m confused by your jira report.  What happens when you 
>> create a configuration in code and try to update it with your property?  Can 
>> you get it back?  There might be a problem with persisting such a property, 
>> but your test doesn’t demonstrate it because perhaps the persistence is 
>> encoding the value somehow.
>>
>> thanks
>> david jencks
>>
>>> On Sep 17, 2016, at 9:59 AM, Benson Margulies <ben...@basistech.com> wrote:
>>>
>>> I could commit this test, which fails, if you like, with an @Ignore.
>>>
>>>
>>> public class InvalidFileSyntaxTest {
>>>private static final String CONFIG = "rootPath=${bt.root}\n";
>>>
>>>@Test
>>>public void testPropSyntax() throws IOException
>>>{
>>>    final Dictionary dict = ConfigurationHandler.read(new
>>> ByteArrayInputStream(CONFIG.getBytes("UTF-8")));
>>>assertEquals(1, dict.size());
>>>    assertEquals("${bt.root}", dict.get("rootPath"));
>>>}
>>> }
>>>
>>> On Sat, Sep 17, 2016 at 12:49 PM, Benson Margulies <ben...@basistech.com> 
>>> wrote:
>>>> On Sat, Sep 17, 2016 at 12:45 PM, David Jencks
>>>> <david_jen...@yahoo.com.invalid> wrote:
>>>>>
>>>>>> On Sep 17, 2016, at 9:40 AM, Benson Margulies <ben...@basistech.com> 
>>>>>> wrote:
>>>>>>
>>>>>> On Sat, Sep 17, 2016 at 3:21 AM, Carsten Ziegeler <cziege...@apache.org 
>>>>>> <mailto:cziege...@apache.org>> wrote:
>>>>>>>> I don’t think this belongs in ca.  You could use a 
>>>>>>>> ConfigurationPlugin.  Unfortunately you’ll have to wait till R7 until 
>>>>>>>> this works with DS.  Maybe Carsten already implemented the CA part, 
>>>>>>>> but I didn’t do the DS part yet.
>>>>>>
>>>>>> Interesting. When I tried to use such a file with CA, the low-level
>>>>>> parser rejected the ${x} syntax long before a plugin would get a
>>>>>> chance to modify the dictionary contents, or so I thought.
>>>>>
>>>>> I’ve been assuming you only want to put the ${xxx} in values, where I’d 
>>>>> expect it to be a fine persistable value…. you weren’t using it as a key 
>>>>> were you (where it won’t work AFAIK)?
>>>>
>>>> Nope, just as a value (${bt.foo.bar}). I opened a JIRA about the fact
>>>> that CA discarded the entire file without even a log message. I
>>>> assumed that it had to do with the syntax for arrays and such that the
>>>> parser supports.
>>>>
>>>>
>>>>>
>>>>> david jencks
>>>>>
>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> I've implemented both parts, the CA part is in trunk,

Re: Prop expansion via fileinstall but not configuration admin

[Benson Margulies]

I could commit this test, which fails, if you like, with an @Ignore.


public class InvalidFileSyntaxTest {
private static final String CONFIG = "rootPath=${bt.root}\n";

@Test
public void testPropSyntax() throws IOException
{
final Dictionary dict = ConfigurationHandler.read(new
ByteArrayInputStream(CONFIG.getBytes("UTF-8")));
assertEquals(1, dict.size());
assertEquals("${bt.root}", dict.get("rootPath"));
    }
}

On Sat, Sep 17, 2016 at 12:49 PM, Benson Margulies <ben...@basistech.com> wrote:
> On Sat, Sep 17, 2016 at 12:45 PM, David Jencks
> <david_jen...@yahoo.com.invalid> wrote:
>>
>>> On Sep 17, 2016, at 9:40 AM, Benson Margulies <ben...@basistech.com> wrote:
>>>
>>> On Sat, Sep 17, 2016 at 3:21 AM, Carsten Ziegeler <cziege...@apache.org 
>>> <mailto:cziege...@apache.org>> wrote:
>>>>> I don’t think this belongs in ca.  You could use a ConfigurationPlugin.  
>>>>> Unfortunately you’ll have to wait till R7 until this works with DS.  
>>>>> Maybe Carsten already implemented the CA part, but I didn’t do the DS 
>>>>> part yet.
>>>
>>> Interesting. When I tried to use such a file with CA, the low-level
>>> parser rejected the ${x} syntax long before a plugin would get a
>>> chance to modify the dictionary contents, or so I thought.
>>
>> I’ve been assuming you only want to put the ${xxx} in values, where I’d 
>> expect it to be a fine persistable value…. you weren’t using it as a key 
>> were you (where it won’t work AFAIK)?
>
> Nope, just as a value (${bt.foo.bar}). I opened a JIRA about the fact
> that CA discarded the entire file without even a log message. I
> assumed that it had to do with the syntax for arrays and such that the
> parser supports.
>
>
>>
>> david jencks
>>
>>>
>>>>>
>>>>
>>>> I've implemented both parts, the CA part is in trunk, the DS part is in
>>>> the sandbox branch, but I plan to move it to trunk soon.
>>>>
>>>> Carsten
>>>>
>>>>> Alternatively you can code it into whatever management agent you are 
>>>>> using instead of fileinstall.
>>>>>
>>>>> Maybe others have other opinions….
>>>>>
>>>>> david jencks
>>>>>
>>>>>
>>>>>
>>>>>> On Sep 16, 2016, at 5:47 PM, Benson Margulies <ben...@basistech.com> 
>>>>>> wrote:
>>>>>>
>>>>>> The system property expansion feature of the configuration-admin
>>>>>> behavior of fileinstall is quite convenient. I could code it,
>>>>>> optionally, into confadmin. I wish I could have it without all the
>>>>>> other mechanism of fileinstall that I don't need. Acceptable?
>>>>>>
>>>>>> -
>>>>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>>>>>> For additional commands, e-mail: users-h...@felix.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> -
>>>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>>>>> For additional commands, e-mail: users-h...@felix.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Carsten Ziegeler
>>>> Adobe Research Switzerland
>>>> cziege...@apache.org
>>>>
>>>>
>>>> -
>>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>>>> For additional commands, e-mail: users-h...@felix.apache.org
>>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org 
>>> <mailto:users-unsubscr...@felix.apache.org>
>>> For additional commands, e-mail: users-h...@felix.apache.org 
>>> <mailto:users-h...@felix.apache.org>

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Prop expansion via fileinstall but not configuration admin

[Benson Margulies]

On Sat, Sep 17, 2016 at 12:45 PM, David Jencks
<david_jen...@yahoo.com.invalid> wrote:
>
>> On Sep 17, 2016, at 9:40 AM, Benson Margulies <ben...@basistech.com> wrote:
>>
>> On Sat, Sep 17, 2016 at 3:21 AM, Carsten Ziegeler <cziege...@apache.org 
>> <mailto:cziege...@apache.org>> wrote:
>>>> I don’t think this belongs in ca.  You could use a ConfigurationPlugin.  
>>>> Unfortunately you’ll have to wait till R7 until this works with DS.  Maybe 
>>>> Carsten already implemented the CA part, but I didn’t do the DS part yet.
>>
>> Interesting. When I tried to use such a file with CA, the low-level
>> parser rejected the ${x} syntax long before a plugin would get a
>> chance to modify the dictionary contents, or so I thought.
>
> I’ve been assuming you only want to put the ${xxx} in values, where I’d 
> expect it to be a fine persistable value…. you weren’t using it as a key were 
> you (where it won’t work AFAIK)?

Nope, just as a value (${bt.foo.bar}). I opened a JIRA about the fact
that CA discarded the entire file without even a log message. I
assumed that it had to do with the syntax for arrays and such that the
parser supports.


>
> david jencks
>
>>
>>>>
>>>
>>> I've implemented both parts, the CA part is in trunk, the DS part is in
>>> the sandbox branch, but I plan to move it to trunk soon.
>>>
>>> Carsten
>>>
>>>> Alternatively you can code it into whatever management agent you are using 
>>>> instead of fileinstall.
>>>>
>>>> Maybe others have other opinions….
>>>>
>>>> david jencks
>>>>
>>>>
>>>>
>>>>> On Sep 16, 2016, at 5:47 PM, Benson Margulies <ben...@basistech.com> 
>>>>> wrote:
>>>>>
>>>>> The system property expansion feature of the configuration-admin
>>>>> behavior of fileinstall is quite convenient. I could code it,
>>>>> optionally, into confadmin. I wish I could have it without all the
>>>>> other mechanism of fileinstall that I don't need. Acceptable?
>>>>>
>>>>> -
>>>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>>>>> For additional commands, e-mail: users-h...@felix.apache.org
>>>>>
>>>>
>>>>
>>>> -
>>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>>>> For additional commands, e-mail: users-h...@felix.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>>
>>> --
>>> Carsten Ziegeler
>>> Adobe Research Switzerland
>>> cziege...@apache.org
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>>> For additional commands, e-mail: users-h...@felix.apache.org
>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org 
>> <mailto:users-unsubscr...@felix.apache.org>
>> For additional commands, e-mail: users-h...@felix.apache.org 
>> <mailto:users-h...@felix.apache.org>

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Prop expansion via fileinstall but not configuration admin

[Benson Margulies]

On Sat, Sep 17, 2016 at 3:21 AM, Carsten Ziegeler <cziege...@apache.org> wrote:
>> I don’t think this belongs in ca.  You could use a ConfigurationPlugin.  
>> Unfortunately you’ll have to wait till R7 until this works with DS.  Maybe 
>> Carsten already implemented the CA part, but I didn’t do the DS part yet.

Interesting. When I tried to use such a file with CA, the low-level
parser rejected the ${x} syntax long before a plugin would get a
chance to modify the dictionary contents, or so I thought.

>>
>
> I've implemented both parts, the CA part is in trunk, the DS part is in
> the sandbox branch, but I plan to move it to trunk soon.
>
> Carsten
>
>> Alternatively you can code it into whatever management agent you are using 
>> instead of fileinstall.
>>
>> Maybe others have other opinions….
>>
>> david jencks
>>
>>
>>
>>> On Sep 16, 2016, at 5:47 PM, Benson Margulies <ben...@basistech.com> wrote:
>>>
>>> The system property expansion feature of the configuration-admin
>>> behavior of fileinstall is quite convenient. I could code it,
>>> optionally, into confadmin. I wish I could have it without all the
>>> other mechanism of fileinstall that I don't need. Acceptable?
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>>> For additional commands, e-mail: users-h...@felix.apache.org
>>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>>
>>
>
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Prop expansion via fileinstall but not configuration admin

[Benson Margulies]

The system property expansion feature of the configuration-admin
behavior of fileinstall is quite convenient. I could code it,
optionally, into confadmin. I wish I could have it without all the
other mechanism of fileinstall that I don't need. Acceptable?

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

CM and DS logging interpretation

[Benson Margulies]

I need some help interpreting the logging from DS and CM, if someone
could be kind enough to have a look at the material below.

I have an @Component named WorkerBusService which is never activated.
I see no SCR messages related to it in the log except for other
components trying to depend on it.

It need a configuration (configured policy = REQUIRED).

I believe that the necessary file is sitting in the directory
configured with felix.cm.dir. I suspect that the log messages below
are trying to tell me something about this, one way or the other. It
says 'listing configurations for', but then doesn't list any. Does
this mean that it didn't find it? I set the CM log level all the way
up (to 4).

10:25:34.474 [main] DEBUG rosapi-worker-bus.1.4.0.201609161353 -
BundleComponentActivator : Bundle [86] ComponentHolder created for
com.basistech.ws.worker.bus.impl.BusService
10:25:34.475 [main] DEBUG org.apache.felix.configadmin.1.8.10 -
[[org.osgi.service.cm.ConfigurationAdmin]]listConfigurations(filter=(|(service.factoryPid=com.basistech.ws.bus)(service.factoryPid=com.basistech.ws.bus|rosapi-worker-bus)(service.factoryPid=com.basistech.ws.bus|rosapi-worker-bus|1.4.0.201609161353)(service.factoryPid=com.basistech.ws.bus|rosapi-worker-bus|1.4.0.201609161353|/Users/benson/x/rosapi1.5/headless/framework/../collect-bundles/target/bundles/rosapi-worker-bus-1.4.0-SNAPSHOT.jar)))
10:25:34.475 [main] DEBUG org.apache.felix.configadmin.1.8.10 -
[[org.osgi.service.cm.ConfigurationAdmin]]Listing configurations
matching 
(|(service.factoryPid=com.basistech.ws.bus)(service.factoryPid=com.basistech.ws.bus|rosapi-worker-bus)(service.factoryPid=com.basistech.ws.bus|rosapi-worker-bus|1.4.0.201609161353)(service.factoryPid=com.basistech.ws.bus|rosapi-worker-bus|1.4.0.201609161353|/Users/benson/x/rosapi1.5/headless/framework/../collect-bundles/target/bundles/rosapi-worker-bus-1.4.0-SNAPSHOT.jar))
10:25:34.476 [main] DEBUG org.apache.felix.configadmin.1.8.10 -
[[org.osgi.service.cm.ConfigurationAdmin]]listConfigurations(filter=(|(service.pid=com.basistech.ws.bus)(service.pid=com.basistech.ws.bus|rosapi-worker-bus)(service.pid=com.basistech.ws.bus|rosapi-worker-bus|1.4.0.201609161353)(service.pid=com.basistech.ws.bus|rosapi-worker-bus|1.4.0.201609161353|/Users/benson/x/rosapi1.5/headless/framework/../collect-bundles/target/bundles/rosapi-worker-bus-1.4.0-SNAPSHOT.jar)))
10:25:34.476 [main] DEBUG org.apache.felix.configadmin.1.8.10 -
[[org.osgi.service.cm.ConfigurationAdmin]]Listing configurations
matching 
(|(service.pid=com.basistech.ws.bus)(service.pid=com.basistech.ws.bus|rosapi-worker-bus)(service.pid=com.basistech.ws.bus|rosapi-worker-bus|1.4.0.201609161353)(service.pid=com.basistech.ws.bus|rosapi-worker-bus|1.4.0.201609161353|/Users/benson/x/rosapi1.5/headless/framework/../collect-bundles/target/bundles/rosapi-worker-bus-1.4.0-SNAPSHOT.jar))
10:25:34.476 [main] DEBUG rosapi-worker-bus.1.4.0.201609161353 -
BundleComponentActivator : Bundle [86] May enable component holder
com.basistech.ws.worker.bus.impl.BusService
10:25:34.476 [main] DEBUG rosapi-worker-bus.1.4.0.201609161353 -
BundleComponentActivator : Bundle [86] Enabling component holder
com.basistech.ws.worker.bus.impl.BusService

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

config admin and non-default file systems

[Benson Margulies]

I've got a use case in which I'd like to run the framework in a Hadoop
cluster, and the users would want to store their cfg files on hdfs.

Making config admin support this would not be terribly complex -- if
the minimum java version were 7.

What is the current version base?

Another possible issue is the general problem of using registered
non-default FileSystemProviders in OSGi. To use the straightforward
uri-to-Path code path, the provider has to be in the system
classloader. So, if someone wants to set the config admin dir property
to 'hdfs://something', then either they need to arrange that file
system provider into the outer class loader, or code in config admin
has to use some servicemix-ish scheme to provide alternative
registration of providers. Selfishly, I can imagine a config admin
property that can be used to declare one or more providers.

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Failing to get felix scr logging

[Benson Margulies]

No, I don't have an OSGi config for SCR. I'm continuing to investigate.

On Thu, Sep 15, 2016 at 9:53 PM, Carsten Ziegeler  wrote:
>> In a pax-exam test, I've got:
>>
>> CoreOptions.frameworkProperty("ds.loglevel").value("debug"),
>>
>>
>> I get no messages. Other log messages generated from other things make
>> an appearance.
>>
>> I chased myself in circles on this once before, and ended up resorting
>> to the gogo shell remote and using scr commands to get some insight.
>>
> I did a quick check of the code. Do you also have an OSGi configuration
> for SCR?
>
> Regards
>
> Carsten
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Semantics of Require-Capability of a service derived from DS @Reference

[Benson Margulies]

On Wed, Aug 31, 2016 at 7:44 AM, Neil Bartlett <njbartl...@gmail.com> wrote:
> It looks like you have solved this problem over in the bndtools-users list, 
> but I want to point out one small misapprehension:

Yes, thanks, and thanks for the clarification.

>
>> On 31 Aug 2016, at 13:39, Benson Margulies <ben...@basistech.com> wrote:
>>
>> The maven-bundle-plugin, in some cases, with _dsannotations enabled,
>> produces Require-Capability instructions like the following:
>>
>> Require-Capability: osgi.service;filter:="(objectClass=com.basistech.ros
>> ette.osgi.Bus)";effective:=active,osgi.ee;filter:="(&(osgi.ee=JavaSE)(v
>> ersion=1.8))"
>>
>> I only noticed them when Karaf 4.0.6 stopped being able to resolve
>> these. I assume that these derive somehow from DS @References, but the
>> filters in the DS references are not fully copied into here.
>>
>> The service in question is activated by a bundle that is present in
>> the overall provisioning, but apparently is not starting before the
>> Karaf resolver gets going.
>
> The started state of the bundle providing these services is irrelevant. A 
> Require-Capability header is always matched by a Provide-Capability header. 
> The bundle that Provides the capability does not need to be started, it only 
> needs to be resolved or resolvable.
>
> By the way, the correct way to read such a Provide-Capability header is not 
> that the bundle always provides the service but that it has the *potential* 
> to provide a service, some of the time… if it feels like it. That’s why these 
> requirements and capabilities are effective:=active, they should only be 
> treated as hints to a provisioning agent and not as instructions to the OSGi 
> Framework.
>
>
>
>> Are these instructions required for DS? I'm
>> about to try switching to the bnd-maven-plugin and see if I see
>> anything different.
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Semantics of Require-Capability of a service derived from DS @Reference

[Benson Margulies]

The maven-bundle-plugin, in some cases, with _dsannotations enabled,
produces Require-Capability instructions like the following:

Require-Capability: osgi.service;filter:="(objectClass=com.basistech.ros
 ette.osgi.Bus)";effective:=active,osgi.ee;filter:="(&(osgi.ee=JavaSE)(v
 ersion=1.8))"

I only noticed them when Karaf 4.0.6 stopped being able to resolve
these. I assume that these derive somehow from DS @References, but the
filters in the DS references are not fully copied into here.

The service in question is activated by a bundle that is present in
the overall provisioning, but apparently is not starting before the
Karaf resolver gets going. Are these instructions required for DS? I'm
about to try switching to the bnd-maven-plugin and see if I see
anything different.

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: scr claims to be unsatisfied for service that seems to be there

[Benson Margulies]

On Fri, Aug 12, 2016 at 7:54 AM, Karel Haeck <karel.ha...@telenet.be> wrote:
>
> You typically use a serviceTracker in the test bundle to obtain a reference
> to the component 's service.
> See http://enroute.osgi.org/tutorial_base/600-testing.html for how to do
> this in bndtools.
> The service tracker open method will trigger the component's delayed
> activation

I didn't realize that the service tracker could interact with DS. Thanks.


>
> Karel
>
>
> On 12/08/2016 13:30, Benson Margulies wrote:
>>
>> Thank you all. Indeed, the component was not 'immediate', and that's
>> why it wasn't set up.
>>
>> My task of the moment it to add pax-exam tests for some individual
>> components; in the past, I only tested this stuff with broad
>> functional tests. This has led me, on this particular occasion,  end
>> up trying to test this not-immediate component.
>>
>> How do other people create pax-exam tests for @Components that are not
>> immediate? By adding DS metadata to pax-exam bundles?
>>
>>
>>
>>
>>
>>
>> g! scr:info com.basistech.ws.worker.core.Worker
>> *** Bundle: rosapi-worker-core (59)
>> Component Description:
>>Name: com.basistech.ws.worker.core.Worker
>>Implementation Class: com.basistech.ws.worker.core.Worker
>>Default State: enabled
>>Activation: immediate
>>Configuration Policy: ignore
>>Activate Method: activate
>>Deactivate Method: deactivate
>>Modified Method: -
>>Configuration Pid: [com.basistech.ws.worker.core.Worker]
>>Services:
>>  com.basistech.ws.worker.api.WorkerInterface
>>Service Scope: singleton
>>Reference: BusService
>>  Interface Name: com.basistech.ws.worker.api.WorkerBusService
>>  Cardinality: 1..1
>>  Policy: static
>>  Policy option: reluctant
>>  Reference Scope: bundle
>>Reference: WorkerComponentServices
>>  Interface Name: com.basistech.ws.worker.core.WorkerComponentServices
>>  Cardinality: 1..1
>>  Policy: static
>>  Policy option: reluctant
>>  Reference Scope: bundle
>>Reference: WorkerConfiguration
>>  Interface Name:
>> com.basistech.ws.worker.core.config.WorkerConfiguration
>>  Cardinality: 1..1
>>  Policy: static
>>  Policy option: reluctant
>>  Reference Scope: bundle
>>Component Description Properties:
>>Component Configuration:
>>  ComponentId: 5
>>  State: active
>>  SatisfiedReference: BusService
>>Target: null
>>Bound to:39
>>Reference Properties:
>>component.id = 3
>>component.name = com.basistech.ws.worker.bus.impl.BusService
>>licensePathname =
>>
>> /Users/benson/x/rosapi1.5/worker/core/../../assemblies/common-configuration/src/main/resources/etc/rosapi/rlp-license.xml
>>objectClass = [com.basistech.ws.worker.api.WorkerBusService]
>>service.bundleid = 24
>>service.id = 39
>>service.pid = com.basistech.ws.bus
>>service.scope = bundle
>>  SatisfiedReference: WorkerComponentServices
>>Target: null
>>Bound to:56
>>Reference Properties:
>>objectClass =
>> [com.basistech.ws.worker.core.WorkerComponentServices]
>>service.bundleid = 59
>>service.id = 56
>>service.scope = singleton
>>  SatisfiedReference: WorkerConfiguration
>>Target: null
>>Bound to:40
>>Reference Properties:
>>component.id = 6
>>component.name =
>> com.basistech.ws.worker.core.config.WorkerConfigurationImpl
>>configurationFilePathname =
>>
>> /Users/benson/x/rosapi1.5/worker/core/src/test/config/path-subst-worker-config.yaml
>>endpointsPathname =
>>
>> /Users/benson/x/rosapi1.5/worker/core/src/test/config/all-endpoints-no-dte.yaml
>>native-root =
>>
>> /var/folders/80/5l86669j3278_x4hlpntlz38gp/T/nativeroot6966159272930866297
>>objectClass =
>> [com.basistech.ws.worker.core.config.WorkerConfiguration]
>>service.bundleid = 59
>>service.id = 40
>>service.pid = com.basistech.ws.worker
>>service.scope = bundle
>>subst = tsbus
>>  Component Configuration Properties:
>>  component.id = 5
>>  component.name = 

Re: scr claims to be unsatisfied for service that seems to be there

[Benson Margulies]

Thank you all. Indeed, the component was not 'immediate', and that's
why it wasn't set up.

My task of the moment it to add pax-exam tests for some individual
components; in the past, I only tested this stuff with broad
functional tests. This has led me, on this particular occasion,  end
up trying to test this not-immediate component.

How do other people create pax-exam tests for @Components that are not
immediate? By adding DS metadata to pax-exam bundles?






g! scr:info com.basistech.ws.worker.core.Worker
*** Bundle: rosapi-worker-core (59)
Component Description:
  Name: com.basistech.ws.worker.core.Worker
  Implementation Class: com.basistech.ws.worker.core.Worker
  Default State: enabled
  Activation: immediate
  Configuration Policy: ignore
  Activate Method: activate
  Deactivate Method: deactivate
  Modified Method: -
  Configuration Pid: [com.basistech.ws.worker.core.Worker]
  Services:
com.basistech.ws.worker.api.WorkerInterface
  Service Scope: singleton
  Reference: BusService
Interface Name: com.basistech.ws.worker.api.WorkerBusService
Cardinality: 1..1
Policy: static
Policy option: reluctant
Reference Scope: bundle
  Reference: WorkerComponentServices
Interface Name: com.basistech.ws.worker.core.WorkerComponentServices
Cardinality: 1..1
Policy: static
Policy option: reluctant
Reference Scope: bundle
  Reference: WorkerConfiguration
Interface Name: com.basistech.ws.worker.core.config.WorkerConfiguration
Cardinality: 1..1
Policy: static
Policy option: reluctant
Reference Scope: bundle
  Component Description Properties:
  Component Configuration:
ComponentId: 5
State: active
SatisfiedReference: BusService
  Target: null
  Bound to:39
  Reference Properties:
  component.id = 3
  component.name = com.basistech.ws.worker.bus.impl.BusService
  licensePathname =
/Users/benson/x/rosapi1.5/worker/core/../../assemblies/common-configuration/src/main/resources/etc/rosapi/rlp-license.xml
  objectClass = [com.basistech.ws.worker.api.WorkerBusService]
  service.bundleid = 24
  service.id = 39
  service.pid = com.basistech.ws.bus
  service.scope = bundle
SatisfiedReference: WorkerComponentServices
  Target: null
  Bound to:56
  Reference Properties:
  objectClass = [com.basistech.ws.worker.core.WorkerComponentServices]
  service.bundleid = 59
  service.id = 56
  service.scope = singleton
SatisfiedReference: WorkerConfiguration
  Target: null
  Bound to:40
  Reference Properties:
  component.id = 6
  component.name =
com.basistech.ws.worker.core.config.WorkerConfigurationImpl
  configurationFilePathname =
/Users/benson/x/rosapi1.5/worker/core/src/test/config/path-subst-worker-config.yaml
  endpointsPathname =
/Users/benson/x/rosapi1.5/worker/core/src/test/config/all-endpoints-no-dte.yaml
  native-root =
/var/folders/80/5l86669j3278_x4hlpntlz38gp/T/nativeroot6966159272930866297
  objectClass =
[com.basistech.ws.worker.core.config.WorkerConfiguration]
  service.bundleid = 59
  service.id = 40
  service.pid = com.basistech.ws.worker
  service.scope = bundle
  subst = tsbus
Component Configuration Properties:
component.id = 5
component.name = com.basistech.ws.worker.core.Worker

On Fri, Aug 12, 2016 at 6:05 AM, Ferry Huberts  wrote:
>
>
> On 12/08/16 12:02, Carsten Ziegeler wrote:
>>>
>>> Thanks Carsten, that was my expectation but I was waiting for the
>>> “inspect cap service” output to confirm.
>>>
>>> One thing that can be quite confusing is that the service
>>> references, with cardinality of 1..1, are described as both
>>> satisfied and unbound. This sounds like a contradiction until you
>>> realise the component has not yet been instantiated. I assume that
>>> SCR at this point does know which services it *will* bind when the
>>> component is activated… maybe these could be shown here?
>
>
> I think that would be misleading because when the bundle composition changes
> before activation is needed then a different resolution can/will be
> activated.
>
>>>
>> Hmm, yeah we could do that - on the other hand "unbound" means it's
>> satisfied, otherwise it would state the reference as "unsatisfied"
>> :) Maybe, it's more a wording problem?
>>
>> Carsten
>>
>
> --
> Ferry Huberts
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

scr claims to be unsatisfied for service that seems to be there

[Benson Margulies]

I have a component, which scr:info reports that is has three unbound references.

scr:info on the components that provide those services seem to show
that they are there. And if I set breakpoints on their activate
methods (they are @Components), they've been called, and did not
throw. I've put an scr:info for one of them at the end. What would
cause SCR to not pass these services into the component and activate
it?

g! scr:info com.basistech.ws.worker.core.Worker
*** Bundle: rosapi-worker-core (59)
Component Description:
  Name: com.basistech.ws.worker.core.Worker
  Implementation Class: com.basistech.ws.worker.core.Worker
  Default State: enabled
  Activation: delayed
  Configuration Policy: ignore
  Activate Method: activate
  Deactivate Method: deactivate
  Modified Method: -
  Configuration Pid: [com.basistech.ws.worker.core.Worker]
  Services:
com.basistech.ws.worker.api.WorkerInterface
  Service Scope: singleton
  Reference: BusService
Interface Name: com.basistech.ws.worker.api.WorkerBusService
Cardinality: 1..1
Policy: static
Policy option: reluctant
Reference Scope: bundle
  Reference: WorkerComponentServices
Interface Name: com.basistech.ws.worker.core.WorkerComponentServices
Cardinality: 1..1
Policy: static
Policy option: reluctant
Reference Scope: bundle
  Reference: WorkerConfiguration
Interface Name: com.basistech.ws.worker.core.config.WorkerConfiguration
Cardinality: 1..1
Policy: static
Policy option: reluctant
Reference Scope: bundle
  Component Description Properties:
  Component Configuration:
ComponentId: 5
State: satisfied
SatisfiedReference: BusService
  Target: null
  (unbound)
SatisfiedReference: WorkerComponentServices
  Target: null
  (unbound)
SatisfiedReference: WorkerConfiguration
  Target: null
  (unbound)
Component Configuration Properties:
component.id = 5
component.name = com.basistech.ws.worker.core.Worker



g! scr:info com.basistech.ws.worker.core.config.WorkerConfigurationImpl
*** Bundle: rosapi-worker-core (59)
Component Description:
  Name: com.basistech.ws.worker.core.config.WorkerConfigurationImpl
  Implementation Class:
com.basistech.ws.worker.core.config.WorkerConfigurationImpl
  Default State: enabled
  Activation: immediate
  Configuration Policy: require
  Activate Method: activate
  Deactivate Method: deactivate
  Modified Method: -
  Configuration Pid: [com.basistech.ws.worker]
  Services:
com.basistech.ws.worker.core.config.WorkerConfiguration
  Service Scope: singleton
  Component Description Properties:
  Component Configuration:
ComponentId: 6
State: active
Component Configuration Properties:
component.id = 6
component.name =
com.basistech.ws.worker.core.config.WorkerConfigurationImpl
configurationFilePathname =
/Users/benson/x/rosapi1.5/worker/core/src/test/config/path-subst-worker-config.yaml
endpointsPathname =
/Users/benson/x/rosapi1.5/worker/core/src/test/config/all-endpoints-no-dte.yaml
native-root =
/var/folders/80/5l86669j3278_x4hlpntlz38gp/T/nativeroot7939628695379969633
service.pid = com.basistech.ws.worker
subst = tsbus

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Solved felix SCR Logging, but replaced that with a problem with optional dependency resolution in the framework

[Benson Margulies]

I have now explained it. The exception is noisy and harmless. In
Equinox, it's logged to the Equinox log service, which was, until
moments ago, invisible to me.

However, it's still true that my test fails in Felix. I am not going
to bother this list or myself with that phenomenon until I have some
other things, including that exception, sorted.


On Thu, Aug 11, 2016 at 6:31 PM, Benson Margulies <ben...@basistech.com> wrote:
> On Thu, Aug 11, 2016 at 5:07 PM, David Jencks
> <david_jen...@yahoo.com.invalid> wrote:
>> I don’t understand your explanation.  What is causing the class load?  So 
>> far it looks like resolution:=optional worked fine, but your code doesn’t 
>> implement what it needs to make it actually optional.  Maybe the details you 
>> left out explain better :-)
>
> The 'details I left out' are much too voluminous until and unless I
> boil this down to a test case. In brief, I agree, it makes no sense. I
> run the program in equinox, it works. I run it in felix, it fails.
> Maybe my code is wrong and equinox excuses it for some reason. Maybe
> something else. I apologize for using bandwidth on such a muddle.
>
>
>>
>> If you go back to equinox, you might try registering your log service with 
>> service ranking > 0; that might make it preferred vs the built in equinox 
>> one.
>
> Unfortunately, I'd have to fork:
>
> https://github.com/qos-ch/slf4j/blob/master/osgi-over-slf4j/src/main/java/org/slf4j/osgi/logservice/impl/Activator.java
>
> But I just figured out how to get the equinox log where I can see it, maybe.
>
>>
>> david jencks
>>
>>> On Aug 11, 2016, at 1:36 PM, Benson Margulies <ben...@basistech.com> wrote:
>>>
>>> Quite some time ago, we had a requirement to have read-only
>>> provisioned OSGi caches. So I had set up our standard configuration to
>>> use Equinox rather than Felix.
>>>
>>> Equinox sets up a LogService of its own, which in turn requires a
>>> 'LogReader' to get the log messages to show up anywhere. Adding
>>> another LogService doesn't work. I have yet to figure out how to
>>> politely instruct Equinox to stay out of the way in this respect.
>>>
>>> As it turns out, the read-only requirement is gone. So I decided that
>>> since I am in the occasional habit of asking for help on the Felix
>>> list, it would be good if I was, well, using more of Felix.
>>>
>>> So I switched to the Felix framework (5.4.0). Sure enough, there are
>>> my log messages.
>>>
>>> But some optional packages are now a problem that worked fine in Equinox.
>>>
>>> I suspect that this will be impossible for anyone to comment on unless
>>> I can build a minimized test case.
>>>
>>> I get a class not found for a class in a package that I have
>>> intentionally left out of this deployment. Leaving it out is
>>> facilitated by the use of resolution:=optional. In Equinox, this works
>>> fine. In Felix, somehow, something decides that it needs to wire up
>>> this and fails.
>>>
>>> If by some really unlikely accident this has the earmarks of a
>>> well-known phenomenon, I'm sure someone will let me know. Otherwise,
>>> I'll either bail back to Equinox or do the more complex refactoring
>>> that I'm deferring and be able to remove the optional resolution.
>>>
>>>
>>>
>>> Caused by: java.lang.ClassNotFoundException:
>>> org.apache.cxf.common.i18n.Exception not found by
>>> com.basistech.ws.rosapi-common [21]
>>> at 
>>> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1574)
>>> at 
>>> org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)
>>> at 
>>> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2018)
>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>>> For additional commands, e-mail: users-h...@felix.apache.org
>>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>>

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Solved felix SCR Logging, but replaced that with a problem with optional dependency resolution in the framework

[Benson Margulies]

On Thu, Aug 11, 2016 at 5:07 PM, David Jencks
<david_jen...@yahoo.com.invalid> wrote:
> I don’t understand your explanation.  What is causing the class load?  So far 
> it looks like resolution:=optional worked fine, but your code doesn’t 
> implement what it needs to make it actually optional.  Maybe the details you 
> left out explain better :-)

The 'details I left out' are much too voluminous until and unless I
boil this down to a test case. In brief, I agree, it makes no sense. I
run the program in equinox, it works. I run it in felix, it fails.
Maybe my code is wrong and equinox excuses it for some reason. Maybe
something else. I apologize for using bandwidth on such a muddle.


>
> If you go back to equinox, you might try registering your log service with 
> service ranking > 0; that might make it preferred vs the built in equinox one.

Unfortunately, I'd have to fork:

https://github.com/qos-ch/slf4j/blob/master/osgi-over-slf4j/src/main/java/org/slf4j/osgi/logservice/impl/Activator.java

But I just figured out how to get the equinox log where I can see it, maybe.

>
> david jencks
>
>> On Aug 11, 2016, at 1:36 PM, Benson Margulies <ben...@basistech.com> wrote:
>>
>> Quite some time ago, we had a requirement to have read-only
>> provisioned OSGi caches. So I had set up our standard configuration to
>> use Equinox rather than Felix.
>>
>> Equinox sets up a LogService of its own, which in turn requires a
>> 'LogReader' to get the log messages to show up anywhere. Adding
>> another LogService doesn't work. I have yet to figure out how to
>> politely instruct Equinox to stay out of the way in this respect.
>>
>> As it turns out, the read-only requirement is gone. So I decided that
>> since I am in the occasional habit of asking for help on the Felix
>> list, it would be good if I was, well, using more of Felix.
>>
>> So I switched to the Felix framework (5.4.0). Sure enough, there are
>> my log messages.
>>
>> But some optional packages are now a problem that worked fine in Equinox.
>>
>> I suspect that this will be impossible for anyone to comment on unless
>> I can build a minimized test case.
>>
>> I get a class not found for a class in a package that I have
>> intentionally left out of this deployment. Leaving it out is
>> facilitated by the use of resolution:=optional. In Equinox, this works
>> fine. In Felix, somehow, something decides that it needs to wire up
>> this and fails.
>>
>> If by some really unlikely accident this has the earmarks of a
>> well-known phenomenon, I'm sure someone will let me know. Otherwise,
>> I'll either bail back to Equinox or do the more complex refactoring
>> that I'm deferring and be able to remove the optional resolution.
>>
>>
>>
>> Caused by: java.lang.ClassNotFoundException:
>> org.apache.cxf.common.i18n.Exception not found by
>> com.basistech.ws.rosapi-common [21]
>> at 
>> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1574)
>> at 
>> org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)
>> at 
>> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2018)
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Solved felix SCR Logging, but replaced that with a problem with optional dependency resolution in the framework

[Benson Margulies]

Quite some time ago, we had a requirement to have read-only
provisioned OSGi caches. So I had set up our standard configuration to
use Equinox rather than Felix.

Equinox sets up a LogService of its own, which in turn requires a
'LogReader' to get the log messages to show up anywhere. Adding
another LogService doesn't work. I have yet to figure out how to
politely instruct Equinox to stay out of the way in this respect.

As it turns out, the read-only requirement is gone. So I decided that
since I am in the occasional habit of asking for help on the Felix
list, it would be good if I was, well, using more of Felix.

So I switched to the Felix framework (5.4.0). Sure enough, there are
my log messages.

But some optional packages are now a problem that worked fine in Equinox.

I suspect that this will be impossible for anyone to comment on unless
I can build a minimized test case.

I get a class not found for a class in a package that I have
intentionally left out of this deployment. Leaving it out is
facilitated by the use of resolution:=optional. In Equinox, this works
fine. In Felix, somehow, something decides that it needs to wire up
this and fails.

If by some really unlikely accident this has the earmarks of a
well-known phenomenon, I'm sure someone will let me know. Otherwise,
I'll either bail back to Equinox or do the more complex refactoring
that I'm deferring and be able to remove the optional resolution.



Caused by: java.lang.ClassNotFoundException:
org.apache.cxf.common.i18n.Exception not found by
com.basistech.ws.rosapi-common [21]
at 
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1574)
at 
org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)
at 
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2018)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

DS logging, still

[Benson Margulies]

I think I'm still missing something simple about DS logging.

I have added org.slf4j:osgi-over-slf4j to my container to provide a LogService.

In pax-exam, I did:

frameworkProperty("ds.loglevel").value("debug"),


SLF4J messages from my code show up. Nothing shows up from Felix SCR.

Any ideas?

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Bundles needed to use DS/SCR

[Benson Margulies]

Yup, I have it all working. I have to have a family of an abstract
class and subclasses of tests if each test needs different CM
properties, but that's better than the bigger mess I was making
before.

On Thu, Aug 11, 2016 at 2:59 AM, Christian Schneider
<ch...@die-schneider.net> wrote:
> pax-exam-cm just sets up the config. As far as I know it does not install
> config admin so you will still need the bundle.
>
> Christian
>
> 2016-08-11 1:42 GMT+02:00 Benson Margulies <ben...@basistech.com>:
>
>> For one of my tests, pax-exam-cm looks great. Do I include felix
>> config admin with it or not?
>>
>> For another, I need each test method to have different configuration,
>> so I'd have to make multiple test classes, no?
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>>
>>
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.liquid-reality.de>
>
> Open Source Architect
> http://www.talend.com
> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.talend.com>

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Registering a ConfigurationListener

[Benson Margulies]

On Wed, Aug 10, 2016 at 5:44 PM, David Jencks
<david_jen...@yahoo.com.invalid> wrote:
> I can’t think of any circumstances where you’d want to register with the 
> system bundle, normally you’d register with the bundle interested in the 
> configuration.  It won’t make any difference unless you are using framework 
> hooks to control service visibility.  An example of where it would make a 
> difference is if you installed a bunch of isolated subsystems each containing 
> their own config admin implementation. Registering the listener with a bundle 
> in one of these subsystems will make it visible only to that subsystem’s 
> config admin.  Depending on how the isolation is set up registering with the 
> system bundle is likely to make it invisible to all the subsystem config 
> admins or possibly visible to all of them.
>

> out of curiosity, why do you need your own ConfigurationListener?

Oh, it's the collision of two issues.

First, I need to have the arrangement of '.cfg' file make sense to a
human being who is configuring a system, not just be a mirror of my
momentary set of modularity decisions into @Component classes. So I
can't use the DS connection to config-admin very well, since I need
multiple objects to read the same configuration.

Second, purely in my tests, I was having trouble making sure that the
config of one of these items was present _before_ its @Activate was
called, so I considered deferring the work until a
ConfigurationListener was called back. When I registered it on the
bundle at hand, it was never called. I probably registered it wrong.
I've found a simpler approach.



>
> thanks
> david jencks
>
>> On Aug 10, 2016, at 2:02 PM, Benson Margulies <ben...@basistech.com> wrote:
>>
>> I see examples that seem to be just registering these as a service on
>> any old bundle. The javadoc says, "ConfigurationListener objects are
>> registered with the Framework service registry". Does that mean the
>> system bundle?
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Bundles needed to use DS/SCR

[Benson Margulies]

For one of my tests, pax-exam-cm looks great. Do I include felix
config admin with it or not?

For another, I need each test method to have different configuration,
so I'd have to make multiple test classes, no?

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Bundles needed to use DS/SCR

[Benson Margulies]

On Wed, Aug 10, 2016 at 11:35 AM, David Jencks
<david_jen...@yahoo.com.invalid> wrote:
> As discussed on another thread today, this one-arg getConfiguration call 
> nails the configuration to the bundle doing the calling, which usually isn’t 
> what you want since it usually isn’t the bundle with the component you’re 
> trying to configure.  Use the 2-arg getConfiguration method passing either 
> null, the actual bundle location, or “?”.

Oh, gosh, I should have caught that. Unfortunately, passing in that
"?" did not change the behavior. Is there also a problem with the
'setBundleLocation(null)' call I cargo-culted into my code?



g! scr:info com.basistech.ws.worker.core.config.WorkerConfigurationImpl
*** Bundle: rosapi-worker-core (56)
Component Description:
  Name: com.basistech.ws.worker.core.config.WorkerConfigurationImpl
  Implementation Class:
com.basistech.ws.worker.core.config.WorkerConfigurationImpl
  Default State: enabled
  Activation: immediate
  Configuration Policy: require
  Activate Method: activate
  Deactivate Method: deactivate
  Modified Method: -
  Configuration Pid:
[com.basistech.ws.worker.core.config.WorkerConfigurationImpl]
  Services:
com.basistech.ws.worker.core.config.WorkerConfiguration
  Service Scope: singleton
  Reference: ConfigurationAdmin
Interface Name: org.osgi.service.cm.ConfigurationAdmin
Cardinality: 1..1
Policy: static
Policy option: reluctant
Reference Scope: bundle
  Component Description Properties:
  (No Component Configurations)

>
>
> Since DS is no longer trying to set the bundle location, null leaves your 
> component vulnerable to something else that does set it to the wrong bundle.
> Using the actual bundle location means you have to know what it is, but 
> restricts the configuration to that one bundle.
> “?” lets all bundles see the configuration.
>
> david jencks
>
>> On Aug 10, 2016, at 8:29 AM, Benson Margulies <ben...@basistech.com> wrote:
>>
>> Configuration-wise, I have the following code. Logging-wise, I have
>> pax-exam installing logging, but I will recheck that.
>>
>>
>> org.osgi.service.cm.Configuration workerConf =
>> configurationAdmin.getConfiguration("com.basistech.ws.worker");
>> Dictionary<String, Object> props = new Hashtable<>();
>>
>> Path mainWorkerConfigPath =
>> Paths.get("../../assemblies/common/configuration/src/main/resources/rosapi/worker-config.yaml");
>> Path testEndpointPath = Paths.get("src/test/config/endpoints.yaml");
>>
>> props.put("configurationFilePathname",
>> mainWorkerConfigPath.toAbsolutePath().toString());
>> props.put("endpointsPathname", testEndpointPath.toAbsolutePath().toString());
>>
>> workerConf.setBundleLocation(null);
>> workerConf.update(props);
>>
>>
>>
>> On Wed, Aug 10, 2016 at 11:17 AM, David Jencks
>> <david_jen...@yahoo.com.invalid> wrote:
>>>> Configuration Policy: require
>>>
>>>> (No Component Configurations)
>>>
>>> You need a configuration or change the configuration policy.
>>>
>>> Is your minimal container so minimal that it doesn’t include a log service 
>>> or something to collect messages from it?
>>>
>>> david jencks
>>>
>>>> On Aug 10, 2016, at 8:14 AM, Benson Margulies <ben...@basistech.com> wrote:
>>>>
>>>> I have some more information. While I still don't know where my log
>>>> message are going, I turned on the gogo remote shell. According to
>>>> scr:info, my component is alive.
>>>>
>>>> However, I can't obtain a service reference to the service it exports
>>>> with a plain old ServiceTracker or call to my bundle context. I'd be
>>>> grateful for any diagnostic advice.
>>>>
>>>>
>>>> scr:info com.basistech.ws.worker.core.config.WorkerConfigurationImpl
>>>> *** Bundle: rosapi-worker-core (56)
>>>> Component Description:
>>>> Name: com.basistech.ws.worker.core.config.WorkerConfigurationImpl
>>>> Implementation Class:
>>>> com.basistech.ws.worker.core.config.WorkerConfigurationImpl
>>>> Default State: enabled
>>>> Activation: immediate
>>>> Configuration Policy: require
>>>> Activate Method: activate
>>>> Deactivate Method: deactivate
>>>> Modified Method: -
>>>> Configuration Pid:
>>>> [com.basistech.ws.worker.core.config.WorkerConfigurationImpl]
>>>> Services:
>>>>   com.basistech.ws.worker.core.config.WorkerConfiguration
>>>> Ser

Re: Bundles needed to use DS/SCR

[Benson Margulies]

I see a much dumber mistake here. Sorry for the noise. The test is not
pushing the config to the right PID at all.


On Wed, Aug 10, 2016 at 11:43 AM, Benson Margulies <ben...@basistech.com> wrote:
> On Wed, Aug 10, 2016 at 11:35 AM, David Jencks
> <david_jen...@yahoo.com.invalid> wrote:
>> As discussed on another thread today, this one-arg getConfiguration call 
>> nails the configuration to the bundle doing the calling, which usually isn’t 
>> what you want since it usually isn’t the bundle with the component you’re 
>> trying to configure.  Use the 2-arg getConfiguration method passing either 
>> null, the actual bundle location, or “?”.
>
> Oh, gosh, I should have caught that. Unfortunately, passing in that
> "?" did not change the behavior. Is there also a problem with the
> 'setBundleLocation(null)' call I cargo-culted into my code?
>
>
>
> g! scr:info com.basistech.ws.worker.core.config.WorkerConfigurationImpl
> *** Bundle: rosapi-worker-core (56)
> Component Description:
>   Name: com.basistech.ws.worker.core.config.WorkerConfigurationImpl
>   Implementation Class:
> com.basistech.ws.worker.core.config.WorkerConfigurationImpl
>   Default State: enabled
>   Activation: immediate
>   Configuration Policy: require
>   Activate Method: activate
>   Deactivate Method: deactivate
>   Modified Method: -
>   Configuration Pid:
> [com.basistech.ws.worker.core.config.WorkerConfigurationImpl]
>   Services:
> com.basistech.ws.worker.core.config.WorkerConfiguration
>   Service Scope: singleton
>   Reference: ConfigurationAdmin
> Interface Name: org.osgi.service.cm.ConfigurationAdmin
> Cardinality: 1..1
> Policy: static
> Policy option: reluctant
> Reference Scope: bundle
>   Component Description Properties:
>   (No Component Configurations)
>
>>
>>
>> Since DS is no longer trying to set the bundle location, null leaves your 
>> component vulnerable to something else that does set it to the wrong bundle.
>> Using the actual bundle location means you have to know what it is, but 
>> restricts the configuration to that one bundle.
>> “?” lets all bundles see the configuration.
>>
>> david jencks
>>
>>> On Aug 10, 2016, at 8:29 AM, Benson Margulies <ben...@basistech.com> wrote:
>>>
>>> Configuration-wise, I have the following code. Logging-wise, I have
>>> pax-exam installing logging, but I will recheck that.
>>>
>>>
>>> org.osgi.service.cm.Configuration workerConf =
>>> configurationAdmin.getConfiguration("com.basistech.ws.worker");
>>> Dictionary<String, Object> props = new Hashtable<>();
>>>
>>> Path mainWorkerConfigPath =
>>> Paths.get("../../assemblies/common/configuration/src/main/resources/rosapi/worker-config.yaml");
>>> Path testEndpointPath = Paths.get("src/test/config/endpoints.yaml");
>>>
>>> props.put("configurationFilePathname",
>>> mainWorkerConfigPath.toAbsolutePath().toString());
>>> props.put("endpointsPathname", 
>>> testEndpointPath.toAbsolutePath().toString());
>>>
>>> workerConf.setBundleLocation(null);
>>> workerConf.update(props);
>>>
>>>
>>>
>>> On Wed, Aug 10, 2016 at 11:17 AM, David Jencks
>>> <david_jen...@yahoo.com.invalid> wrote:
>>>>> Configuration Policy: require
>>>>
>>>>> (No Component Configurations)
>>>>
>>>> You need a configuration or change the configuration policy.
>>>>
>>>> Is your minimal container so minimal that it doesn’t include a log service 
>>>> or something to collect messages from it?
>>>>
>>>> david jencks
>>>>
>>>>> On Aug 10, 2016, at 8:14 AM, Benson Margulies <ben...@basistech.com> 
>>>>> wrote:
>>>>>
>>>>> I have some more information. While I still don't know where my log
>>>>> message are going, I turned on the gogo remote shell. According to
>>>>> scr:info, my component is alive.
>>>>>
>>>>> However, I can't obtain a service reference to the service it exports
>>>>> with a plain old ServiceTracker or call to my bundle context. I'd be
>>>>> grateful for any diagnostic advice.
>>>>>
>>>>>
>>>>> scr:info com.basistech.ws.worker.core.config.WorkerConfigurationImpl
>>>>> *** Bundle: rosapi-worker-core (56)
>>>>> Component Description:
>>>>&g

Re: Bundles needed to use DS/SCR

[Benson Margulies]

Configuration-wise, I have the following code. Logging-wise, I have
pax-exam installing logging, but I will recheck that.


org.osgi.service.cm.Configuration workerConf =
configurationAdmin.getConfiguration("com.basistech.ws.worker");
Dictionary<String, Object> props = new Hashtable<>();

Path mainWorkerConfigPath =
Paths.get("../../assemblies/common/configuration/src/main/resources/rosapi/worker-config.yaml");
Path testEndpointPath = Paths.get("src/test/config/endpoints.yaml");

props.put("configurationFilePathname",
mainWorkerConfigPath.toAbsolutePath().toString());
props.put("endpointsPathname", testEndpointPath.toAbsolutePath().toString());

workerConf.setBundleLocation(null);
workerConf.update(props);



On Wed, Aug 10, 2016 at 11:17 AM, David Jencks
<david_jen...@yahoo.com.invalid> wrote:
>> Configuration Policy: require
>
>> (No Component Configurations)
>
> You need a configuration or change the configuration policy.
>
> Is your minimal container so minimal that it doesn’t include a log service or 
> something to collect messages from it?
>
> david jencks
>
>> On Aug 10, 2016, at 8:14 AM, Benson Margulies <ben...@basistech.com> wrote:
>>
>> I have some more information. While I still don't know where my log
>> message are going, I turned on the gogo remote shell. According to
>> scr:info, my component is alive.
>>
>> However, I can't obtain a service reference to the service it exports
>> with a plain old ServiceTracker or call to my bundle context. I'd be
>> grateful for any diagnostic advice.
>>
>>
>> scr:info com.basistech.ws.worker.core.config.WorkerConfigurationImpl
>> *** Bundle: rosapi-worker-core (56)
>> Component Description:
>>  Name: com.basistech.ws.worker.core.config.WorkerConfigurationImpl
>>  Implementation Class:
>> com.basistech.ws.worker.core.config.WorkerConfigurationImpl
>>  Default State: enabled
>>  Activation: immediate
>>  Configuration Policy: require
>>  Activate Method: activate
>>  Deactivate Method: deactivate
>>  Modified Method: -
>>  Configuration Pid:
>> [com.basistech.ws.worker.core.config.WorkerConfigurationImpl]
>>  Services:
>>com.basistech.ws.worker.core.config.WorkerConfiguration
>>  Service Scope: singleton
>>  Reference: ConfigurationAdmin
>>Interface Name: org.osgi.service.cm.ConfigurationAdmin
>>Cardinality: 1..1
>>Policy: static
>>Policy option: reluctant
>>Reference Scope: bundle
>>  Component Description Properties:
>>  (No Component Configurations)
>>
>> On Wed, Aug 10, 2016 at 10:32 AM, Benson Margulies <ben...@basistech.com> 
>> wrote:
>>> For unit testing purposes, I'm setting up a minimal container that has 
>>> DS/SCR .
>>>
>>> I included:
>>>
>>> org.apache.felix
>>> org.apache.felix.scr
>>> 2.0.6
>>>
>>> I set the framework ds.loglevel property to debug, and I see no sign of 
>>> life.
>>>
>>> I'm using standard OSGi DS annotations.
>>>
>>> Can anyone tell me what I'm missing?
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Bundles needed to use DS/SCR

[Benson Margulies]

I have some more information. While I still don't know where my log
message are going, I turned on the gogo remote shell. According to
scr:info, my component is alive.

However, I can't obtain a service reference to the service it exports
with a plain old ServiceTracker or call to my bundle context. I'd be
grateful for any diagnostic advice.


scr:info com.basistech.ws.worker.core.config.WorkerConfigurationImpl
*** Bundle: rosapi-worker-core (56)
Component Description:
  Name: com.basistech.ws.worker.core.config.WorkerConfigurationImpl
  Implementation Class:
com.basistech.ws.worker.core.config.WorkerConfigurationImpl
  Default State: enabled
  Activation: immediate
  Configuration Policy: require
  Activate Method: activate
  Deactivate Method: deactivate
  Modified Method: -
  Configuration Pid:
[com.basistech.ws.worker.core.config.WorkerConfigurationImpl]
  Services:
com.basistech.ws.worker.core.config.WorkerConfiguration
  Service Scope: singleton
  Reference: ConfigurationAdmin
Interface Name: org.osgi.service.cm.ConfigurationAdmin
Cardinality: 1..1
Policy: static
Policy option: reluctant
Reference Scope: bundle
  Component Description Properties:
  (No Component Configurations)

On Wed, Aug 10, 2016 at 10:32 AM, Benson Margulies <ben...@basistech.com> wrote:
> For unit testing purposes, I'm setting up a minimal container that has DS/SCR 
> .
>
> I included:
>
> org.apache.felix
> org.apache.felix.scr
> 2.0.6
>
> I set the framework ds.loglevel property to debug, and I see no sign of life.
>
> I'm using standard OSGi DS annotations.
>
> Can anyone tell me what I'm missing?

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Bundles needed to use DS/SCR

[Benson Margulies]

For unit testing purposes, I'm setting up a minimal container that has DS/SCR .

I included:

org.apache.felix
org.apache.felix.scr
2.0.6

I set the framework ds.loglevel property to debug, and I see no sign of life.

I'm using standard OSGi DS annotations.

Can anyone tell me what I'm missing?

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Cannot use configuration pid ... for bundle XX because it belongs to bundle YY

[Benson Margulies]

In my experience, it means that you have annotated two different classes
with @Component and specified the same configurationPid. You can't do that;
if you need to share a configuration between DS components, you have to
inject the ConfigurationAdmin service instead of using the @Component
annotation.

On Wed, Aug 10, 2016 at 3:32 AM, Remo Liechti 
wrote:

> Hi guys
>
> During starting of bundles I get the following message:
>
>  pid=com.kuka.configuration.manager for bundle 17 because it belongs to
> bundle 7>
>
> What does this actually mean? I have not found good information with uncle
> sams google.
> What I do, is the following:
> - Wrap an osgi application into a j2ee web application (war file)
> - Using Felix on Weblogic: https://docs.oracle.com/
> middleware/1212/wls/WLPRG/osgi.htm
> - My main bundle activator is called, using a servlet I start all other
> bundles manually
>
>
> @Resource(lookup = "java:app/osgi/Bundle")
> Bundle bundle;
>
> BundleContext bc = bundle.getBundleContext();
> for (Bundle b : bc.getBundles()) {
> []
> b.start();
> [...]
> }
>
> Thanks,
> Remo
>
>
> This message may contain legally privileged or confidential information
> and is therefore addressed to the named persons only. The recipient should
> inform the sender and delete this message, if he/she is not named as
> addressee. The sender disclaims any and all liability for the integrity and
> punctuality of this message. The sender has activated an automatic virus
> scanning, but does not guarantee the virus free transmission of this
> message.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>

Re: Loading bundles from inside jars, and read-only filesystems

[Benson Margulies]

On Mon, Aug 8, 2016 at 2:40 PM, <list+org.apache.fe...@io7m.com> wrote:

> On 2016-08-08T14:31:07 -0400
> Benson Margulies <ben...@basistech.com> wrote:
> >
> > I believe that all OSGi containers can load bundles from InputStreams,
> > which is all you would need.
>
> Ah, OK.
>
> That should be fairly easy, then.
>
> > > Is it a question of "someone needs to implement the right services" or
> > > is it something more fundamental than that?
> >
> > It's moderately fundamental. There's a JIRA for it.
>
> This one?
>
>   https://issues.apache.org/jira/browse/FELIX-465


https://issues.apache.org/jira/browse/FELIX-4885


>
>
> It hadn't occurred to me that an in-memory cache would preclude native
> libraries. Perhaps I'll have to do without that one...
>
> Thanks!
>
> M
>

Re: Loading bundles from inside jars, and read-only filesystems

[Benson Margulies]

On Mon, Aug 8, 2016 at 2:19 PM, <list+org.apache.fe...@io7m.com> wrote:

> On 2016-08-08T14:10:38 -0400
> Benson Margulies <ben...@basistech.com> wrote:
> > On Mon, Aug 8, 2016 at 2:08 PM, <list+org.apache.fe...@io7m.com> wrote:
> > >
> > >
> > > 1. Is Felix able to load bundles from inside a jar?
>

I believe that all OSGi containers can load bundles from InputStreams,
which is all you would need.


> > >
> > > 2. Is Felix able to run on entirely read-only filesystems?
> >
> > No. Equinox can, but Felix cannot.
>
> Is it a question of "someone needs to implement the right services" or
> is it something more fundamental than that?
>

It's moderately fundamental. There's a JIRA for it.



>
> M
>

Re: Loading bundles from inside jars, and read-only filesystems

[Benson Margulies]

On Mon, Aug 8, 2016 at 2:08 PM,  wrote:

> Hello.
>
> Two quick questions:
>
> 1. Is Felix able to load bundles from inside a jar? Specifically: I
> would like to be able to embed Felix into a single-jar application
> by putting my Main class and Felix classes into a single jar along with
> the individual bundle jars.
>
> 2. Is Felix able to run on entirely read-only filesystems? I notice
> that the OSGi framework mandates caching, but it doesn't say that the
> cache has to be on the filesystem. Is there perhaps an in-memory cache
> implementation available?
>

No. Equinox can, but Felix cannot.


>
> Thanks,
> M
>

ObjectInputStreams, class loaders, OSGi

[Benson Margulies]

I've OSGi'ed a body of code that reads a model from an ObjectInputStream. I
didn't adjust the TCCL, and I didn't make a custom object input stream that
respects the TCCL, as per
http://tech-tauk.blogspot.com/2010/05/thread-context-classlaoder-in.html.
Yet, it works.

Except, strangely, when it does not. Under circumstances I am struggling to
isolate, it fails to read the object. This is not helped by the fact that
OIS, in this case, does not set the exception cause to reveal what actually
went wrong.

The exception is not a class-not-found at all. Has anyone else seen
anything like this?

java.lang.IllegalStateException: unread block data
at
java.io.ObjectInputStream$BlockDataInputStream.setBlockDataMode(ObjectInputStream.java:2431)[:1.8.0_60]
at
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1383)[:1.8.0_60]
at
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2000)[:1.8.0_60]

Re: Silently failing declarative services?

[Benson Margulies]

Is your @Component set up with immediate=true?

On Mon, Aug 1, 2016 at 1:08 PM,  wrote:

> On 2016-08-01T18:26:33 +0200
> Simon Chemouil  wrote:
>
> > list+org.apache.fe...@io7m.com a écrit le 01/08/2016 18:16 :
> > > I don't see a compiled bundle anywhere, only source code. Is there one
> > > available, or do I need to build it?
> >
> > http://felix.apache.org/downloads.cgi
> >
> > or straight from Maven Central.
> >
> > It's also good to have an implementation of Metatype and of the
> > LogService when you use Felix SCR, since it will complain (but not fail)
> > the former is missing, and uses the latter for logging.
>
> Thank you. Somehow failed to see that the links on that page were
> binaries (was looking at the source jars to the right).
>
> On adding the declarative services bundle, I ran across the following:
>
> Caused by: java.lang.ClassNotFoundException: *** Class
> 'org.osgi.service.cm.ConfigurationListener' was not found. Bundle
> org.apache.felix.scr [7] does not import package 'org.osgi.service.cm',
> nor is the package exported by any other bundle or available from the
> system class loader. ***
>
> Some checking online indicated that I needed the configuration admin
> bundle. I now have these bundles installed:
>
> g! lb
> START LEVEL 1
>ID|State  |Level|Name
> 0|Active |0|System Bundle (5.4.0)|5.4.0
> 1|Active |1|Apache Felix Bundle Repository (2.0.6)|2.0.6
> 2|Active |1|Apache Felix Configuration Admin Service
> (1.8.10)|1.8.10
> 3|Active |1|Apache Felix Gogo Command (0.16.0)|0.16.0
> 4|Active |1|Apache Felix Gogo Runtime (0.16.2)|0.16.2
> 5|Active |1|Apache Felix Gogo Shell (0.10.0)|0.10.0
> 6|Active |1|Apache Felix Log Service (1.0.1)|1.0.1
> 7|Active |1|Apache Felix Metatype Service (1.1.2)|1.1.2
> 8|Active |1|Apache Felix Declarative Services (2.0.4)|2.0.4
>
> However, this hasn't solved the original problem:
>
> g! install
> service0-provider-declarative/target/service0-provider-declarative-0.1.0.jar
> Bundle ID: 9
> g! start 9
> DEBUG: WIRE: [com.io7m.experimental.service0-provider-declarative [9](R
> 9.0)] osgi.ee; (&(osgi.ee=JavaSE)(version=1.8)) ->
> [org.apache.felix.framework [0](R 0)]
> g! lb
> START LEVEL 1
>ID|State  |Level|Name
> 0|Active |0|System Bundle (5.4.0)|5.4.0
> 1|Active |1|Apache Felix Bundle Repository (2.0.6)|2.0.6
> 2|Active |1|Apache Felix Configuration Admin Service
> (1.8.10)|1.8.10
> 3|Active |1|Apache Felix Gogo Command (0.16.0)|0.16.0
> 4|Active |1|Apache Felix Gogo Runtime (0.16.2)|0.16.2
> 5|Active |1|Apache Felix Gogo Shell (0.10.0)|0.10.0
> 6|Active |1|Apache Felix Log Service (1.0.1)|1.0.1
> 7|Active |1|Apache Felix Metatype Service (1.1.2)|1.1.2
> 8|Active |1|Apache Felix Declarative Services (2.0.4)|2.0.4
> 9|Active |1|service0-provider-declarative (0.1.0)|0.1.0
>
> The service0-provider-declarative bundle appears to be running, but none
> of the
> methods have been called.
>
> M
>

Does a filter with an OR express a preference in Felix DS?

[Benson Margulies]

If I write a filter expression that says A or B, is the order significant?

Ever since the OSGi wiki was replaced with the enroute site, it's
significantly harder to research this sort of thing.

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Backtrace for intentionally circular dependency

[Benson Margulies]

The curious thing is that my case works, noisily, unlike yours.

On Wed, Feb 24, 2016 at 3:00 PM, Victor Antonovich 
wrote:

> BTW, we have similar rather long-standing issue:
> https://issues.apache.org/jira/browse/FELIX-4417
>

Re: Backtrace for intentionally circular dependency

[Benson Margulies]

thanks, I filed https://issues.apache.org/jira/browse/FELIX-5197 and I'll
make the change unless someone else objects.

On Wed, Feb 24, 2016 at 2:29 PM, David Bosschaert <
david.bosscha...@gmail.com> wrote:

> Hi Benson,
>
> I looked at this as well in the past. I think it might be better to log
> this situation on the INFO level rather than error since the system
> recovers from it anyway being optional/dynamic...
>
> My 2c,
>
> David
>
> On 24 February 2016 at 15:40, Benson Margulies <ben...@basistech.com>
> wrote:
>
> > I have two components that have a pseudo-circular dependency.
> >
> >
> > Component 'WorkerInterface' has a reference like:
> >
> >
> > @Reference(cardinality = ReferenceCardinality.MULTIPLE, policy =
> > ReferencePolicy.DYNAMIC, policyOption = ReferencePolicyOption.GREEDY)
> > public void setWorkerComponentService(WorkerComponentService
> > workerComponentService) { ... }
> >
> > one of the components that provides 'WorkerComponentService' has:
> >
> > @Reference(cardinality = ReferenceCardinality.OPTIONAL, policy =
> > ReferencePolicy.DYNAMIC, unbind = "unbindWorkerInterface")
> > public void setWorkerInterface(WorkerInterface workerInterface) { ..
> }
> >
> > This all works: The second activates, the first activates, and then
> > the second gets called with the reference to the first. However, along
> > the way, an alarming ERROR-level log message is delivered, as below.
> >
> > Is there something I could do differently to avoid this? Is it worthy of
> a
> > JIRA?
> >
> >
> >
> >
> > 2016-02-24 10:25:30,963 | ERROR | lixDispatchQueue |
> > rosapi-worker-rni-rnt-sdk| 51 -
> > com.basistech.ws.rosapi-worker-rni-rnt-sdk - 0.8.101.v20160224031931 |
> > FrameworkEvent ERROR - com.basistech.ws.rosapi-worker-rni-rnt-sdk
> >
> > org.osgi.framework.ServiceException: ServiceFactory.getService()
> > resulted in a cycle.
> >
> > at
> >
> org.apache.felix.framework.ServiceRegistry.getService(ServiceRegistry.java:301)[org.apache.felix.framework-5.4.0.jar:]
> >
> > at
> >
> org.apache.felix.framework.Felix.getService(Felix.java:3699)[org.apache.felix.framework-5.4.0.jar:]
> >
> > at
> >
> org.apache.felix.framework.BundleContextImpl.getService(BundleContextImpl.java:470)[org.apache.felix.framework-5.4.0.jar:]
> >
> > at
> >
> org.apache.felix.scr.impl.manager.SingleRefPair.getServiceObject(SingleRefPair.java:72)[129:org.apache.felix.scr:2.0.2]
> >
> > at
> >
> org.apache.felix.scr.impl.helper.BindMethod.getServiceObject(BindMethod.java:646)[129:org.apache.felix.scr:2.0.2]
> >
> > at
> >
> org.apache.felix.scr.impl.manager.DependencyManager.getServiceObject(DependencyManager.java:2137)[129:org.apache.felix.scr:2.0.2]
> >
> > at
> >
> org.apache.felix.scr.impl.manager.DependencyManager$SingleDynamicCustomizer.prebind(DependencyManager.java:872)[129:org.apache.felix.scr:2.0.2]
> >
> > at
> >
> org.apache.felix.scr.impl.manager.DependencyManager.prebind(DependencyManager.java:1457)[129:org.apache.felix.scr:2.0.2]
> >
> > at
> >
> org.apache.felix.scr.impl.manager.AbstractComponentManager.collectDependencies(AbstractComponentManager.java:983)[129:org.apache.felix.scr:2.0.2]
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> > For additional commands, e-mail: users-h...@felix.apache.org
> >
> >
>

Backtrace for intentionally circular dependency

[Benson Margulies]

I have two components that have a pseudo-circular dependency.


Component 'WorkerInterface' has a reference like:


@Reference(cardinality = ReferenceCardinality.MULTIPLE, policy =
ReferencePolicy.DYNAMIC, policyOption = ReferencePolicyOption.GREEDY)
public void setWorkerComponentService(WorkerComponentService
workerComponentService) { ... }

one of the components that provides 'WorkerComponentService' has:

@Reference(cardinality = ReferenceCardinality.OPTIONAL, policy =
ReferencePolicy.DYNAMIC, unbind = "unbindWorkerInterface")
public void setWorkerInterface(WorkerInterface workerInterface) { .. }

This all works: The second activates, the first activates, and then
the second gets called with the reference to the first. However, along
the way, an alarming ERROR-level log message is delivered, as below.

Is there something I could do differently to avoid this? Is it worthy of a JIRA?




2016-02-24 10:25:30,963 | ERROR | lixDispatchQueue |
rosapi-worker-rni-rnt-sdk| 51 -
com.basistech.ws.rosapi-worker-rni-rnt-sdk - 0.8.101.v20160224031931 |
FrameworkEvent ERROR - com.basistech.ws.rosapi-worker-rni-rnt-sdk

org.osgi.framework.ServiceException: ServiceFactory.getService()
resulted in a cycle.

at 
org.apache.felix.framework.ServiceRegistry.getService(ServiceRegistry.java:301)[org.apache.felix.framework-5.4.0.jar:]

at 
org.apache.felix.framework.Felix.getService(Felix.java:3699)[org.apache.felix.framework-5.4.0.jar:]

at 
org.apache.felix.framework.BundleContextImpl.getService(BundleContextImpl.java:470)[org.apache.felix.framework-5.4.0.jar:]

at 
org.apache.felix.scr.impl.manager.SingleRefPair.getServiceObject(SingleRefPair.java:72)[129:org.apache.felix.scr:2.0.2]

at 
org.apache.felix.scr.impl.helper.BindMethod.getServiceObject(BindMethod.java:646)[129:org.apache.felix.scr:2.0.2]

at 
org.apache.felix.scr.impl.manager.DependencyManager.getServiceObject(DependencyManager.java:2137)[129:org.apache.felix.scr:2.0.2]

at 
org.apache.felix.scr.impl.manager.DependencyManager$SingleDynamicCustomizer.prebind(DependencyManager.java:872)[129:org.apache.felix.scr:2.0.2]

at 
org.apache.felix.scr.impl.manager.DependencyManager.prebind(DependencyManager.java:1457)[129:org.apache.felix.scr:2.0.2]

at 
org.apache.felix.scr.impl.manager.AbstractComponentManager.collectDependencies(AbstractComponentManager.java:983)[129:org.apache.felix.scr:2.0.2]

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

bundle plugin comes up with an export of version=""

[Benson Margulies]

Has anyone else ever seen the bundle plugin come up with something like:

Export-Package: com.basistech.rosette.apimodel;version="";uses:="com.bas
 istech.util"

The POM instruction is just
com.basistech.rosette.apimodel

The result is a bnd error, not too surprisingly.


Here's what -X has to say, sorry for the length.


[DEBUG] Configuring mojo
org.apache.felix:maven-bundle-plugin:3.0.1:bundle from plugin realm
ClassRealm[plugin>org.apache.felix:maven-bundle-plugin:3.0.1, parent:
sun.misc.Launcher$AppClassLoader@33909752]
[DEBUG] Configuring mojo
'org.apache.felix:maven-bundle-plugin:3.0.1:bundle' with basic
configurator -->
[DEBUG]   (s) addMavenDescriptor = true
[DEBUG]   (s) addDefaultImplementationEntries = true
[DEBUG]   (s) manifest =
org.apache.maven.archiver.ManifestConfiguration@508863eb
[DEBUG]   (s) manifestEntries = {Bundle-Vendor=Basis Technology Corp.,
Implementation-Vendor=Basis Technology Corp.,
Implementation-Version=0.7.1-SNAPSHOT}
[DEBUG]   (f) archive =
org.apache.maven.archiver.MavenArchiveConfiguration@7d8802cf
[DEBUG]   (f) buildDirectory = /Users/benson/x/new-java-binding/model/target
[DEBUG]   (f) dependencyReducedPomLocation =
/Users/benson/x/new-java-binding/model/dependency-reduced-pom.xml
[DEBUG]   (f) dumpInstructions =
/Users/benson/x/new-java-binding/model/target/instructions.txt
[DEBUG]   (f) finalName = rosette-api-model-0.7.1-SNAPSHOT
[DEBUG]   (f) instructions = {Bundle-Version=0.7.1.v20151210122325,
Export-Package=com.basistech.rosette.apimodel,
_consumer-policy=${range;[===,+)}}
[DEBUG]   (f) localRepository =   id: local
  url: file:///Users/benson/.m2/repository/
   layout: default
snapshots: [enabled => true, update => always]
 releases: [enabled => true, update => always]

[DEBUG]   (f) m_mavenSession = org.apache.maven.execution.MavenSession@20411320
[DEBUG]   (f) manifestLocation =
/Users/benson/x/new-java-binding/model/target/classes/META-INF
[DEBUG]   (f) niceManifest = true
[DEBUG]   (f) outputDirectory =
/Users/benson/x/new-java-binding/model/target/classes
[DEBUG]   (f) project = MavenProject:
com.basistech.rosette:rosette-api-model:0.7.1-SNAPSHOT @
/Users/benson/x/new-java-binding/model/pom.xml
[DEBUG]   (f) remoteArtifactRepositories = [  id: basis.qa
  url: http://maven.basistech.net/nexus/content/groups/basis.qa/
   layout: default
snapshots: [enabled => false, update => never]
 releases: [enabled => true, update => always]
,   id: Nexus
  url: http://nexus.basistech.net:8081/nexus/content/groups/public
   layout: default
snapshots: [enabled => false, update => daily]
 releases: [enabled => true, update => daily]
]
[DEBUG]   (f) session = org.apache.maven.execution.MavenSession@20411320
[DEBUG] -- end configuration --
[DEBUG] building maven31 dependency graph for
com.basistech.rosette:rosette-api-model:bundle:0.7.1-SNAPSHOT
[DEBUG] Using mirror Nexus
(http://nexus.basistech.net:8081/nexus/content/groups/public) for
central (https://repo.maven.apache.org/maven2).
[DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=0,
ConflictMarker.markTime=0, ConflictMarker.nodeCount=2,
ConflictIdSorter.graphTime=0, ConflictIdSorter.topsortTime=0,
ConflictIdSorter.conflictIdCount=1,
ConflictIdSorter.conflictIdCycleCount=0, ConflictResolver.totalTime=0,
ConflictResolver.conflictItemCount=1,
DefaultDependencyCollector.collectTime=0,
DefaultDependencyCollector.transformTime=0}
[DEBUG] com.basistech.rosette:rosette-api-model:bundle:0.7.1-SNAPSHOT
[DEBUG]com.basistech:common-api:jar:35.3.0:compile
[DEBUG] BND Instructions:
#---
#Wed Dec 09 19:23:26 EST 2015
pom.id=com.basistech.rosette\:rosette-api-model\:bundle\:0.7.1-SNAPSHOT
file.encoding.pkg=sun.io
env.COPYFILE_DISABLE=true
pom.organization.name=Basis Technology Corp.
env.BT_BUILD=amd64-darwin13-xcode5
env.KARAF_DEBUG=true
maven-surefire-plugin.version=2.19
java.home=/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/jre
env.CMD_DURATION=6.21s
env.DISPLAY=/private/tmp/com.apple.launchd.UR481FPA4Z/org.macosforge.xquartz\:0
buildtools.version=1.0.0
pom.contributors=[]
bt-jackson-version=2.6.2
java.awt.headless=true
project.build.developers=[org.apache.maven.model.Developer@5f7a2a79]
classworlds.conf=/opt/maven-basis/bin/m2.conf
env.SECURITYSESSIONID=186a7
project.description=Rosette API data models
pom.pomFile=/Users/benson/x/new-java-binding/model/pom.xml
java.endorsed.dirs=/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/jre/lib/endorsed
Bundle-DocURL=http\://www.basistech.com
project.build.groupId=com.basistech.rosette
env.LOGNAME=benson
pom.organization=org.apache.maven.model.Organization@fcdeb50
maven-bundle-plugin.version=3.0.1
project.build.scm=org.apache.maven.model.Scm@72090715
sun.os.patch.level=unknown
java.vendor.url=http\://java.oracle.com/
maven-antrun-plugin.version=1.7
pom.profiles=[]
maven-symbolicname=com.basistech.rosette.api-model
java.version=1.8.0_60

When two bundles compete to export a package ...

[Benson Margulies]

I am trying to use @Inject in a pax-exam test.

pax-exam uses 

org.apache.geronimo.specs
geronimo-atinject_1.0_spec
${dependency.atinject.version}


Karaf 4 uses the alternative from servicemix.

When I use the karaf container to test, I end up with both. And, as
luck would have it, pax-exam ends up with Inject.class from the
servicemix bundle, while my test ends up with it from the geronimo
bundle.

I don't know how the geronimo bundle gets itself provisioned; but I
assume that pax-exam is arranging this somehow.

anyway, is there any OSGi header i can use to encourage my test bundle
to wire to the servicemix bundle?

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Using bnd macros in the maven-bundle-plugin

[Benson Margulies]

And 2 minutes of further exploration while writing the JIRA revealed
$${...}. Sorry for the noise, I'll improve the documentation.

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Using bnd macros in the maven-bundle-plugin

[Benson Margulies]

I'm reasonably convinced that this is fact a bug. I'll file a JIRA and fix it.


On Tue, Dec 1, 2015 at 7:43 AM, Benson Margulies <ben...@basistech.com> wrote:
> Before I file a JIRA and think I'm debugging a problem:
>
>  <_consumer-policy>\${range;[===,+)}
>
> results in
>
>-consumer-policy=\\${range;[\=\=\=,+)}
>
> in the bnd file written out by the plugin, and a literally
> ${range[===,+]} in the produced manifest.
>
>
>  <_consumer-policy>${range;[===,+)}
>
> results in
>
>  -consumer-policy=
>
> in the bnd file, and an error from bnd.
>
> Is there a way around this that I'm missing, or is this a bug in the plugin?

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Using bnd macros in the maven-bundle-plugin

[Benson Margulies]

Before I file a JIRA and think I'm debugging a problem:

 <_consumer-policy>\${range;[===,+)}

results in

   -consumer-policy=\\${range;[\=\=\=,+)}

in the bnd file written out by the plugin, and a literally
${range[===,+]} in the produced manifest.


 <_consumer-policy>${range;[===,+)}

results in

 -consumer-policy=

in the bnd file, and an error from bnd.

Is there a way around this that I'm missing, or is this a bug in the plugin?

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

DS and .. Fragments (not)?

[Benson Margulies]

Thanks to all of you who educated me yesterday about DS annotation
inheritance in bnd. I implemented it and it works very well. However,
I have an incremental challenge.

What I have here is a gaggle of web services. Most of the logic is
common across them and lives in a base class, which now has @Reference
injection to pick up things it needs from the larger environment, and
activate/deactivate to manage lifecycle.

However, I'd like to enable these services to come from disparate
teams. Given the injunction to avoid cross-bundle inheritance of the
DS annotations, I can't just export the package containing the base
class from one bundle and then tell the teams to import and inherit.

It only took about five minutes to think of the idea of putting each
service in a fragment -- and then discard it, due to the fact that
fragments can't carry DS metadata (according to Stack Overflow).

Is there another trail to follow here, or is there just an inescapable
dilemma between repeating DS annotations and decoupling the pieces?

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: DS and .. Fragments (not)?

[Benson Margulies]

On Wed, Nov 18, 2015 at 7:38 AM, Neil Bartlett <njbartl...@gmail.com> wrote:
> Fragments are not allowed to declare the Service-Component header (or
> rather, if they do it will be ignored by SCR). It is however possible for
> the DS XML and/or classes to be located in fragments, so long as the
> Service-Component header is declared on the host bundle. So that may be one
> route.

Right, that's the reading I did that caused me to conclude that I
couldn't just trivially decorate classes in a fragment with DS
annotations. I don't want the host to 'know' in advance the inventory
of the fragments.

>
> Why not follow a composition approach rather than inheritance? You could
> have a single aggregator component that is injected with all the various
> services, and is then published as a service. Each of your smaller
> components can then inject the aggregate service component.

I more or less started with this, but the problem I had was deciding
when all the services had arrived at the aggregator. I had to give the
aggregator a property that told it how many services to expect, and
this made me sad. I might be able to make the aggregator deal with
them one-at-a-time instead of needing them all together, and then this
would work tolerably well.

Another line of thought I have involves letting them be fragments and
then having the host collect them all and aggregate them. Is there a
tasteful pattern for a host bundle to take note of its fragments, or
is that inevitably ugly?


>
> Neil
>
> On Wed, Nov 18, 2015 at 12:23 PM, Benson Margulies <ben...@basistech.com>
> wrote:
>
>> Thanks to all of you who educated me yesterday about DS annotation
>> inheritance in bnd. I implemented it and it works very well. However,
>> I have an incremental challenge.
>>
>> What I have here is a gaggle of web services. Most of the logic is
>> common across them and lives in a base class, which now has @Reference
>> injection to pick up things it needs from the larger environment, and
>> activate/deactivate to manage lifecycle.
>>
>> However, I'd like to enable these services to come from disparate
>> teams. Given the injunction to avoid cross-bundle inheritance of the
>> DS annotations, I can't just export the package containing the base
>> class from one bundle and then tell the teams to import and inherit.
>>
>> It only took about five minutes to think of the idea of putting each
>> service in a fragment -- and then discard it, due to the fact that
>> fragments can't carry DS metadata (according to Stack Overflow).
>>
>> Is there another trail to follow here, or is there just an inescapable
>> dilemma between repeating DS annotations and decoupling the pieces?
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>>
>>

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: DS and .. Fragments (not)?

[Benson Margulies]

On Wed, Nov 18, 2015 at 8:14 AM, Neil Bartlett <njbartl...@gmail.com> wrote:
>
>> On 18 Nov 2015, at 12:46, Benson Margulies <ben...@basistech.com> wrote:
>>
>> On Wed, Nov 18, 2015 at 7:38 AM, Neil Bartlett <njbartl...@gmail.com 
>> <mailto:njbartl...@gmail.com>> wrote:
>>> Fragments are not allowed to declare the Service-Component header (or
>>> rather, if they do it will be ignored by SCR). It is however possible for
>>> the DS XML and/or classes to be located in fragments, so long as the
>>> Service-Component header is declared on the host bundle. So that may be one
>>> route.
>>
>> Right, that's the reading I did that caused me to conclude that I
>> couldn't just trivially decorate classes in a fragment with DS
>> annotations. I don't want the host to 'know' in advance the inventory
>> of the fragments.
>
> Right, this is certainly a limitation. Also you really don’t want to use 
> fragments if you can avoid it.
>
>>
>>>
>>> Why not follow a composition approach rather than inheritance? You could
>>> have a single aggregator component that is injected with all the various
>>> services, and is then published as a service. Each of your smaller
>>> components can then inject the aggregate service component.
>>
>> I more or less started with this, but the problem I had was deciding
>> when all the services had arrived at the aggregator. I had to give the
>> aggregator a property that told it how many services to expect, and
>> this made me sad. I might be able to make the aggregator deal with
>> them one-at-a-time instead of needing them all together, and then this
>> would work tolerably well.
>
>
> Notwithstanding your mood swings, what is wrong with setting the service 
> references to mandatory (which is the default anyway)? Then the aggregator 
> component will not be published until the references are satisfied.

Mood swing humor aside, there might be 10 today, and 15 tomorrow. I
prefer it to just self-organize. However, since I now think that I can
make the aggregator deal with them one at a time, I can follow your
general advice without any problem at all.

>
>
>>
>> Another line of thought I have involves letting them be fragments and
>> then having the host collect them all and aggregate them. Is there a
>> tasteful pattern for a host bundle to take note of its fragments, or
>> is that inevitably ugly?
>
> Given your BundleWiring instance, you can find all the wires provided by your 
> bundle in the ‘osgi.wiring.host' namespace (HostNamespace.HOST_NAMESPACE) and 
> following them through to their requirers. But I’m not sure what you are 
> planning to do next with this information…

Something pretty unpleasant. I will stick to the aggregation pattern
you suggested.


>
>
>>
>>
>>>
>>> Neil
>>>
>>> On Wed, Nov 18, 2015 at 12:23 PM, Benson Margulies <ben...@basistech.com>
>>> wrote:
>>>
>>>> Thanks to all of you who educated me yesterday about DS annotation
>>>> inheritance in bnd. I implemented it and it works very well. However,
>>>> I have an incremental challenge.
>>>>
>>>> What I have here is a gaggle of web services. Most of the logic is
>>>> common across them and lives in a base class, which now has @Reference
>>>> injection to pick up things it needs from the larger environment, and
>>>> activate/deactivate to manage lifecycle.
>>>>
>>>> However, I'd like to enable these services to come from disparate
>>>> teams. Given the injunction to avoid cross-bundle inheritance of the
>>>> DS annotations, I can't just export the package containing the base
>>>> class from one bundle and then tell the teams to import and inherit.
>>>>
>>>> It only took about five minutes to think of the idea of putting each
>>>> service in a fragment -- and then discard it, due to the fact that
>>>> fragments can't carry DS metadata (according to Stack Overflow).
>>>>
>>>> Is there another trail to follow here, or is there just an inescapable
>>>> dilemma between repeating DS annotations and decoupling the pieces?
>>>>
>>>> -
>>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>>>> For additional commands, e-mail: users-h...@felix.apache.org
>>>>
>>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org 
>> <mailto:users-unsubscr...@felix.apache.org>
>> For additional commands, e-mail: users-h...@felix.apache.org 
>> <mailto:users-h...@felix.apache.org>

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

DRY for DS?

[Benson Margulies]

I'm feeling a bit sad; I have a family of 12 very similar services,
but I can't put the @Reference, @Activate, and @Deactivate into the
base class, I have to copy and paste it into each component class.

Have I missed an alternative?

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: DRY for DS?

[Benson Margulies]

They are.

On Tue, Nov 17, 2015 at 1:10 PM, David Jencks <david.a.jen...@gmail.com> wrote:
> sure you can
>
> -dsannotations-options=inherit
>
> not spec yet, but maybe we can eventually twist some arms :-)
>
> I really recommend only doing this if all the classes with annotations are in 
> the same bundle.
>
> david jencks
>
>> On Nov 17, 2015, at 1:00 PM, Benson Margulies <ben...@basistech.com> wrote:
>>
>> I'm feeling a bit sad; I have a family of 12 very similar services,
>> but I can't put the @Reference, @Activate, and @Deactivate into the
>> base class, I have to copy and paste it into each component class.
>>
>> Have I missed an alternative?
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>>
>

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: DRY for DS?

[Benson Margulies]

On Tue, Nov 17, 2015 at 2:43 PM, Robert Munteanu <romb...@apache.org> wrote:
> Hi Benson,
>
> On Tue, Nov 17, 2015 at 8:00 PM, Benson Margulies <ben...@basistech.com> 
> wrote:
>> I'm feeling a bit sad; I have a family of 12 very similar services,
>> but I can't put the @Reference, @Activate, and @Deactivate into the
>> base class, I have to copy and paste it into each component class.
>>
>> Have I missed an alternative?
>
> The @Activate and @Deactivate annotations are optional if you stick to
> the standard 'activate' and 'deactivate' method names.

I've also got some @References being repeated.

As far as 'standard' goes, this is the standard that specs how bnd
turns .class files into XML? So my only concern would be that some
other tool might not do it?


>
> See 112.5.8 - Activate Method and 112.5.15 - Deactivate Method in the
> OSGi R6 Compendium specs for details.
>
> Robert
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: DRY for DS?

[Benson Margulies]

On Tue, Nov 17, 2015 at 3:32 PM, David Jencks <david.a.jen...@gmail.com> wrote:
> nonstandard == not in the DS 1.3 spec.
>
> These options are only supported by bnd, but I don’t really foresee anyone 
> else writing a ds annotation processing tool.  Do you?

That was the point I was trying to make.

>
> thanks
> david jencks
>
>> On Nov 17, 2015, at 2:47 PM, Benson Margulies <ben...@basistech.com> wrote:
>>
>> On Tue, Nov 17, 2015 at 2:43 PM, Robert Munteanu <romb...@apache.org> wrote:
>>> Hi Benson,
>>>
>>> On Tue, Nov 17, 2015 at 8:00 PM, Benson Margulies <ben...@basistech.com> 
>>> wrote:
>>>> I'm feeling a bit sad; I have a family of 12 very similar services,
>>>> but I can't put the @Reference, @Activate, and @Deactivate into the
>>>> base class, I have to copy and paste it into each component class.
>>>>
>>>> Have I missed an alternative?
>>>
>>> The @Activate and @Deactivate annotations are optional if you stick to
>>> the standard 'activate' and 'deactivate' method names.
>>
>> I've also got some @References being repeated.
>>
>> As far as 'standard' goes, this is the standard that specs how bnd
>> turns .class files into XML? So my only concern would be that some
>> other tool might not do it?
>>
>>
>>>
>>> See 112.5.8 - Activate Method and 112.5.15 - Deactivate Method in the
>>> OSGi R6 Compendium specs for details.
>>>
>>> Robert
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>>> For additional commands, e-mail: users-h...@felix.apache.org
>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

[ANN] Felix Maven Bundle Plugin version 3.0.1 Released

[Benson Margulies]

The Felix team is pleased to announce the release of Felix Maven
Bundle Plugin version 3.0.1

The Maven Bundle Plugin provides Maven integration for the bnd tool
that adds OSGi metadata to jar files.

  http://felix.apache.org/components/bundle-plugin

This release is available from
http://felix.apache.org/site/downloads.cgi and Maven:

  
org.apache.felix
maven-bundle-plugin
3.0.1
  

Release Notes:

Release Notes - Felix - Version maven-bundle-plugin-3.0.1

** Bug
* [FELIX-5062] - maven-bundle-plugin includes tests dependencies
in package analysis
* [FELIX-5070] - Simple syntax for specifying embedded
dependencies has broken

** Improvement
* [FELIX-5073] - Option to create dependency-reduced-pom exists

Enjoy!

-The Felix team

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

https://issues.apache.org/jira/browse/FELIX-5073

[Benson Margulies]

Could I please get some feedback on this pull request? If a plain
patch file was preferable I'll make one.

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Split-package warnings from embedded jars

[Benson Margulies]

On Fri, Oct 2, 2015 at 5:43 PM, Neil Bartlett <njbartl...@gmail.com> wrote:
>
>> On 2 Oct 2015, at 22:30, Benson Margulies <ben...@basistech.com> wrote:
>>
>> On Fri, Oct 2, 2015 at 4:21 PM, Neil Bartlett <njbartl...@gmail.com 
>> <mailto:njbartl...@gmail.com>> wrote:
>>> It does sound wrong to me.
>>>
>>> maven-bundle-plugin is a Felix project.

FELIX-5069.



>>
>> Yes, I do know that. But some problems point down to the bndtools
>> below, and some don’t.
>
>
> True, but I think it’s best to report the error to the project that you are 
> directly using, and let the developers work out if it’s actually a 
> lower-level dependency going wrong.
>
>
>>
>> I will endeavour to create a test case.
>>
>>>
>>> Neil
>>>
>>>> On 2 Oct 2015, at 16:56, Benson Margulies <ben...@basistech.com> wrote:
>>>>
>>>> With maven-bundle-plugin 3.0.0, we are getting split-package
>>>> complaints about packages that are (merely) split between two jar
>>>> files both being embedded into the final result.
>>>>
>>>> This surprises me. If it sounds wrong to the experts, can you suggest
>>>> whether to point the bug report to bndtools or felix?
>>>>
>>>> -
>>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>>>> For additional commands, e-mail: users-h...@felix.apache.org
>>>>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org 
>>> <mailto:users-unsubscr...@felix.apache.org>
>>> For additional commands, e-mail: users-h...@felix.apache.org 
>>> <mailto:users-h...@felix.apache.org>
>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org 
>> <mailto:users-unsubscr...@felix.apache.org>
>> For additional commands, e-mail: users-h...@felix.apache.org 
>> <mailto:users-h...@felix.apache.org>

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Debugging disappearing imports in the maven-bundle-plugin

[Benson Margulies]

We have a new project where the manifest is generated, by 3.0.0, with
a handful of missing dependencies. These are ordinary maven
dependencies, and when we run we get wiring errors.

We can work around them with explicit Import-Package instructions.

Is there any diagnostic approach to this?

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Split-package warnings from embedded jars

[Benson Margulies]

With maven-bundle-plugin 3.0.0, we are getting split-package
complaints about packages that are (merely) split between two jar
files both being embedded into the final result.

This surprises me. If it sounds wrong to the experts, can you suggest
whether to point the bug report to bndtools or felix?

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Split-package warnings from embedded jars

[Benson Margulies]

On Fri, Oct 2, 2015 at 4:21 PM, Neil Bartlett <njbartl...@gmail.com> wrote:
> It does sound wrong to me.
>
> maven-bundle-plugin is a Felix project.

Yes, I do know that. But some problems point down to the bndtools
below, and some don't.

I will endeavour to create a test case.

>
> Neil
>
>> On 2 Oct 2015, at 16:56, Benson Margulies <ben...@basistech.com> wrote:
>>
>> With maven-bundle-plugin 3.0.0, we are getting split-package
>> complaints about packages that are (merely) split between two jar
>> files both being embedded into the final result.
>>
>> This surprises me. If it sounds wrong to the experts, can you suggest
>> whether to point the bug report to bndtools or felix?
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

scr:details reports greedy as static with karaf 4.0.1

[Benson Margulies]

Code:

@Reference(cardinality = ReferenceCardinality.MULTIPLE, policyOption =
ReferencePolicyOption.GREEDY)
public void setWorkerComponentService(WorkerComponentService
workerComponentService) {

this.allComponents.put(workerComponentService.getComponentService().componentType().getType(),
workerComponentService);
LOG.info("Found component " +
workerComponentService.getComponentService().componentType());
}


scr:details:

References
  Reference   : WorkerComponentService
State : satisfied
Multiple  : multiple
Optional  : optional
Policy: static
Service Reference : Bound Service ID 147
(com.basistech.ws.worker.rbl.BaseLinguisticsComponentServiceImpl)
Service Reference : Bound Service ID 148
(com.basistech.ws.worker.mockpnm.MockPairwiseNameMatchingService)
Service Reference : Bound Service ID 154
(com.basistech.ws.worker.mocknametranslation.impl.MockNameTranslationService)
Service Reference : Bound Service ID 155
(com.basistech.ws.sdk.mockrli.impl.MockRliComponentServiceImpl)

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Surprise with Embed-Dependency with 3.0.0

[Benson Margulies]

THis works:

*;groupId=com.basistech.rbl|com.ibm.icu;scope=compile

This does not include ICU:

*;groupId=com.basistech.rbl;scope=compile,icu4j

Why? Is this intended? It's not what I expected from the doc.

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Next bundle plugin release

[Benson Margulies]

Given the 'repeated execution' problems with the current released
version, could we please have a new one?

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Dependency Manager does not behave as expected

[Benson Margulies]

On Thu, Sep 17, 2015 at 6:29 AM, Hubert Felber  wrote:
> Hi Pierre,
>
> Thank you for all your efforts!
>
> unfortunately I could not check it out using svn.
> I get a "Redirect cycle detected for URL 
> 'http://svn.apache.org/viewvc/felix/sandbox/pderop/dependencymanager.test'"
> on both linux and windows

you don't checkout through a viewvc link. That's just for browsing.

https://svn.apache.org/repos/asf/felix/sandbox/...

>
>
> And I don´t have Eclipse installed since we work with IntelliJ Idea
>
> nevertheless I was able to load the relevant files via http and try them.
>
> I made the same observation: as soon as a add a ServiceDependency
> then ComponentImpl#startDependencies() is called -- before I added the 
> component
> to DM.
> Of course the service cannot be started then, the state remains inactive, but 
> DM tries to do so and
> maybe can do this, before I finished the component configuration.
>
> I reduced the snippet:
>
> Component comp = createComponent()
> //.setInterface(toString(LoggingConfService.class,
> //ManagedService.class), null)
> //.setImplementation(LoggingConfigServiceImpl.class)
>
> // after this, DM tries to start the service -> state remains INACTIVE
>
> 
> .add(createServiceDependency().setService(LoggingService.class).setRequired(true));
>
> // before I add the component to DM
>
> System.out.println("Adding component to dependency manager");
> dependencyManager.add(comp);
>
>
> after this, DM tries to start the service agein -> state now is 
> WAITING_FOR_REQUIRED
> which is what I expected. The service will start as soon as the dependency is 
> resolved.
>
>
> You should be able to see this with a breakpoint on 
> ComponentImpl#calculateNewState
> after adding the service dependency.
> In my opinion DM should not try to start the service before I finally add the 
> component
> to DM, but now it tries to start the service, as soon as add a 
> ServiceDependency.
>
> Tested with DM 4.1.0
>
> Thank you again
> Hubert
>
>
 Pierre De Rop  17.09.2015 01:03 >>>
> Hi Hubert;
>
> I don't understand how this is possible, because a DM component initial
> state is Inactive, and remains in this state until you add it to a
> DependencyManager object.
>
> So, your service implementation can not be called in start() before you add
> the component to the dm object.
>
> Ok, in order to go ahead, I have made a (temporary) commit of a
> dependencymanager.test project in my sandbox (see [1]).
>
> So, can you please take a look at it ? I tried to follow your samples by
> creating two bundles:
>
> dependencymanager.test.log.jar -> contains the LoggingService + its
> Activator
> dependencymanager.test.logconfig.jar -> contains the LoggingConfigService
> that depends on the LoggingService.
>
> Here is the Activator for the dependencymanager.test.logconfig.jar bundle
> (I made it a bit more compact, by reusing the methods available from the
> DependencyActivatorBase)
>
> public class Activator extends DependencyActivatorBase {
>
> @Override
> public void init(BundleContext ctx, DependencyManager dm) throws
> Exception {
> Component comp = createComponent()
> .setInterface(toString(LoggingConfigService.class,
> ManagedService.class), null)
> .setImplementation(LoggingConfigServiceImpl.class)
>
> .add(createServiceDependency().setService(LoggingService.class).setRequired(true));
>
> System.out.println("Adding component to dependency manager");
> dm.add(comp);
> }
>
> // Helper used to convert an array of classes to an array of class
> strings
> String[] toString(Class ... services) {
> return Stream.of(services).map(c ->
> c.getName()).toArray(String[]::new);
> }
>
> }
>
>
> So, can you install an Eclipse mars + java8 + latest bndtool (Use the
> dependencymanager.test directory as the eclipse workspace directory).
>
> Then open the bndtools perspective.
>
> Then click on File -> Import -> General -> Existing Projects into workspace
> -> Browse -> Ok -> Finish
>
> Then click on the dependencymanager.test/bnd.bnd file -> Run tab -> Run
> OSGi.
>
> You will then see in the console:
>
>Adding component to dependency manager
>LoggingConfigServiceImpl is starting.
>
> So, the "Adding component to dependency manager" message is displayed, then
> after, when the component is added to the DependencyManager "dm" object,
> then when the component is injected with the LoggingService, it is then
> started and you see the log "LoggingConfigServiceImpl is starting" message.
>
> You can also type "dm" shell command in the console:
>
> dm
>
> [8] dependencymanager.test.logconfig
>  [0] dependencymanager.test.logconf.LoggingConfigService,
> org.osgi.service.cm.ManagedService registered
> dependencymanager.test.log.LoggingService service required available
> [9] dependencymanager.test.log
>  [1] 

Re: Need help debugging Felix OSGi bundles (with Eclipse)

[Benson Margulies]

What goes wrong when you add:

-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005

to the java command line and then attach from Eclipse?


On Sat, Sep 12, 2015 at 3:31 PM, Pedro Domingues
 wrote:
> Hi,
>
> I really need to debug my code by the use of breakpoints, however this seems
> a complex undertaking with an OSGi container.
>
> I have Eclipse and Felix (both the latest). My project is a raw OSGi
> project, I am not using PDE, just maven bundle plugin to generate the
> bundles and then copy them to the /bundle folder in felix, then I perform
> java -jar bin/felix.jar and the project runs. So no fuss here.
>
> However I cannot debug the application that way. I've tried to read the docs
> (http://felix.apache.org/documentation/development/integrating-felix-with-eclipse.html)
> but they are outdated/broken and cant make them work...
>
> How can I debug this? Will I have to avoid using OSGi just because debug is
> not supported...? :(
>
> Thanks!
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: How to 'let the dust settle' with DS?

[Benson Margulies]

The whole thing works with 1.8.2; I look forward to some cleanup with
2.0, and I thank you all again for all the help.

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: How to 'let the dust settle' with DS?

[Benson Margulies]

On Tue, Sep 8, 2015 at 1:47 PM, David Jencks <david.a.jen...@gmail.com> wrote:
> If the reference is static greedy, then the component having the reference 
> has to be deactivated/reactivated each time the set of available services 
> changes.
>
> If the component exposes a service, and is not immediate, then each get/unget 
> cycle will result in activating/deactivating the instance.
>
> You need to include a lot more information about exactly what your components 
> look like and the circumstances around the behavior you report to assign  a 
> specific cause to it.

OK, I've got it; that's exactly the situation at hand (static greedy).
That works for me for now until I can use the newer version.



>
> thanks
> david jencks
>
>> On Sep 8, 2015, at 1:23 PM, Benson Margulies <ben...@basistech.com> wrote:
>>
>> JB says he'll have Karaf up to date next week. In the mean time, I've
>> onto the second chunk of blueprint that I wanted to fix.
>>
>> This time, all in one bundle, I have one multiple @Reference, and a
>> bundle of services that want to feed into it.
>>
>> I observe that an object is created, activate is called, and then
>> deactivate is called.
>> Then a new object is created, and the @Reference method gets called
>> before activate is called.
>>
>> Can you help me find the place in the spec that explains this lifecycle?
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: How to 'let the dust settle' with DS?

[Benson Margulies]

JB says he'll have Karaf up to date next week. In the mean time, I've
onto the second chunk of blueprint that I wanted to fix.

This time, all in one bundle, I have one multiple @Reference, and a
bundle of services that want to feed into it.

I observe that an object is created, activate is called, and then
deactivate is called.
Then a new object is created, and the @Reference method gets called
before activate is called.

Can you help me find the place in the spec that explains this lifecycle?

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

How to 'let the dust settle' with DS?

[Benson Margulies]

I am hoping that David Jencks will continue his charity to strangers here.

David, if you have any gogo jiras you'd like help with in return, just ask.

Three bundles:

B1 registers service S1.

B2 consumes S1 and uses it in the implementation of S2. That is to
say, it picks up a reference to S1 with a DS @Reference with
cardinality MANDATORY.

B3 consumes B2, but it anticipates that B2 will have siblings. So it
consumes a reference to a List with cardinality AT_LEAST_ONE.

It can take B2 and buddies a bit of time to activate.

I appreciate that the most general case is intended to be that
services come and go, and B3 should dynamically reconfigure itself.
I'd rather not do that yet; I'd like to arrange things so that B3
waits to finish starting itself until all the B2-ish guys are fully
set up.

Assuming that B2 and friends are all started at an earlier start
level, is there an 'esthetic' way to arrange this? Or should I really
suck it up and do the late-binding so that B3 says, 'OK, _now_ I need
B2 service x=y, block until it's available?'

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: How to 'let the dust settle' with DS?

[Benson Margulies]

That is precisely what I needed. Thanks.
On Sep 7, 2015 11:06 AM, "David Jencks" <david_jen...@yahoo.com.invalid>
wrote:

> Hi Benson,
>
> I don’t really understand what you are asking, but I’m going to guess.
>
> I think you have say 5  B2 services and you want B3 to wait to activate
> until all 5 B2’s are available?
>
> There is a way to do this with DS 1.3, but you have to make B3
> configuration-policy=REQUIRE.
>
> So you have in B3:
> @Component(configuration-policy=REQUIRE)
> public class B3 {
>
> @Reference(cardinality=MULTIPLE)
> void setB2(B2 b2) {}
> }
> In your (required) configuration for B3 you put a property
>
> B2.cardinality.minimum: 5
>
> that is, .cardinality.minimum = 
>
> Don’t mess with start levels, they will be unreliable for this purpose.
> There’s no guarantee that a bundle starting will start all the DS services
> it provides.  They might have all sorts of unsatisfied dependencies….. such
> as missing configurations.
>
> Let me know if this guess is a total miss :-)
>
> thanks
> david jencks
>
>
>
> > On Sep 7, 2015, at 10:52 AM, Benson Margulies <ben...@basistech.com>
> wrote:
> >
> > I am hoping that David Jencks will continue his charity to strangers
> here.
> >
> > David, if you have any gogo jiras you'd like help with in return, just
> ask.
> >
> > Three bundles:
> >
> > B1 registers service S1.
> >
> > B2 consumes S1 and uses it in the implementation of S2. That is to
> > say, it picks up a reference to S1 with a DS @Reference with
> > cardinality MANDATORY.
> >
> > B3 consumes B2, but it anticipates that B2 will have siblings. So it
> > consumes a reference to a List with cardinality AT_LEAST_ONE.
> >
> > It can take B2 and buddies a bit of time to activate.
> >
> > I appreciate that the most general case is intended to be that
> > services come and go, and B3 should dynamically reconfigure itself.
> > I'd rather not do that yet; I'd like to arrange things so that B3
> > waits to finish starting itself until all the B2-ish guys are fully
> > set up.
> >
> > Assuming that B2 and friends are all started at an earlier start
> > level, is there an 'esthetic' way to arrange this? Or should I really
> > suck it up and do the late-binding so that B3 says, 'OK, _now_ I need
> > B2 service x=y, block until it's available?'
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> > For additional commands, e-mail: users-h...@felix.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>

Re: How to 'let the dust settle' with DS?

[Benson Margulies]

On Mon, Sep 7, 2015 at 12:45 PM, David Jencks
<david_jen...@yahoo.com.invalid> wrote:
> I think both of those suggestions are rather inappropriate to be used in a DS 
> component activate method, which generally should not block….. although 
> having it take a long time is also very much less than ideal.
>
> Certainly the second method seems to imply someone knows how many B2s there  
> are so the minimum cardinality can be set based on that knowledge, possibly 
> by whatever code has that knowledge.  The (proprietary) metatype/config admin 
> I work with does this, it can count how many cm Configurations there are for 
> B2 and set properties based on that.
>
> If you make B3 expose a service and not be immediate, then it won’t be 
> activated until someone needs it and will pick up however many are then 
> available, even without the cardinality set.

Dilemma: B3's job in life is to publish a JAX-RS service via CXF,
which does not involve publishing an OSGi service. So I may need to
stick with one of these less-than-ideal alternatives.


>
> david jencks
>
>> On Sep 7, 2015, at 11:46 AM, Neil Bartlett <njbartl...@gmail.com> wrote:
>>
>> Just to add a bit of detail…
>>
>> If you wait for 5 service instances before performing your initialisation, 
>> that’s great. But bear in mind that you might get a 6th and a 7th very soon 
>> afterwards, and depending on your implementation you may have to 
>> re-initialise each time that happens.
>>
>> If your (re)initialisation is expensive, you might want to avoid doing it 
>> too many times, especially if there is a rapid sequence of changes. This is 
>> typically the case during application startup for example. There are two 
>> general solutions to this:
>>
>> 1) You could start a timer each time the service set changes. If there are 
>> no further changes before the timer expires, then you do your 
>> reinitialisation. If there *are* changes then you cancel the existing timer 
>> and start a new one.
>>
>> 2) Use the Coordinator Service (OSGi Compendium Specification, chapter 130). 
>> Whoever is making changes to the set of installed bundles — e.g. the 
>> launcher, or some kind of management agent like FileInstall — should start a 
>> Coordination before it does anything, and end the coordination after that 
>> series of changes. Your component should be a Participant which detects 
>> whether there is a current coordination. If there is NO current coordination 
>> then it should immediately action any changes in the service set. However if 
>> there is a current coordination, then those changes should only be actioned 
>> when the coordination ends. This has the advantage that you don’t waste time 
>> waiting for an arbitrary-length timer to expire.
>>
>> Hope that helps. Regards,
>> Neil
>>
>>
>>
>>> On 7 Sep 2015, at 16:16, Benson Margulies <ben...@basistech.com> wrote:
>>>
>>> That is precisely what I needed. Thanks.
>>> On Sep 7, 2015 11:06 AM, "David Jencks" <david_jen...@yahoo.com.invalid>
>>> wrote:
>>>
>>>> Hi Benson,
>>>>
>>>> I don’t really understand what you are asking, but I’m going to guess.
>>>>
>>>> I think you have say 5  B2 services and you want B3 to wait to activate
>>>> until all 5 B2’s are available?
>>>>
>>>> There is a way to do this with DS 1.3, but you have to make B3
>>>> configuration-policy=REQUIRE.
>>>>
>>>> So you have in B3:
>>>> @Component(configuration-policy=REQUIRE)
>>>> public class B3 {
>>>>
>>>> @Reference(cardinality=MULTIPLE)
>>>> void setB2(B2 b2) {}
>>>> }
>>>> In your (required) configuration for B3 you put a property
>>>>
>>>> B2.cardinality.minimum: 5
>>>>
>>>> that is, .cardinality.minimum = 
>>>>
>>>> Don’t mess with start levels, they will be unreliable for this purpose.
>>>> There’s no guarantee that a bundle starting will start all the DS services
>>>> it provides.  They might have all sorts of unsatisfied dependencies….. such
>>>> as missing configurations.
>>>>
>>>> Let me know if this guess is a total miss :-)
>>>>
>>>> thanks
>>>> david jencks
>>>>
>>>>
>>>>
>>>>> On Sep 7, 2015, at 10:52 AM, Benson Margulies <ben...@basistech.com>
>>>> wrote:
>>>>>
>>>>> I am hoping that David Jencks 

Re: How to 'let the dust settle' with DS?

[Benson Margulies]

On Mon, Sep 7, 2015 at 1:12 PM, David Jencks
<david_jen...@yahoo.com.invalid> wrote:
> If cxf really does not have this capability, which I find hard to believe, I 
> would do the “publish to cxf” generically by having a component with a 
> dynamic reference (or a service tracker, but if your component is DS a 
> dynamic reference is easier) that uses service properties to figure out what 
> to tell cxf.
>
> A pretty simple example of how to do this is in the aries imx jmx-whiteboard 
> project, which is more complicated than you would need since it has to deal 
> with multiple MBean servers whereas I think you would have only one cxf.

I am studying the relevant CXF code now, but I think that the thing
you are looking for (register a service and CXF publishes it) will
exist only if I make it exist.

I have made a first pass at coding what you wrote here, but it doesn't
work yet. What a surprise. More spelunking to do.



>
> thanks
> david jencks
>
>> On Sep 7, 2015, at 12:46 PM, Benson Margulies <ben...@basistech.com> wrote:
>>
>> On Mon, Sep 7, 2015 at 12:45 PM, David Jencks
>> <david_jen...@yahoo.com.invalid <mailto:david_jen...@yahoo.com.invalid>> 
>> wrote:
>>> I think both of those suggestions are rather inappropriate to be used in a 
>>> DS component activate method, which generally should not block….. although 
>>> having it take a long time is also very much less than ideal.
>>>
>>> Certainly the second method seems to imply someone knows how many B2s there 
>>>  are so the minimum cardinality can be set based on that knowledge, 
>>> possibly by whatever code has that knowledge.  The (proprietary) 
>>> metatype/config admin I work with does this, it can count how many cm 
>>> Configurations there are for B2 and set properties based on that.
>>>
>>> If you make B3 expose a service and not be immediate, then it won’t be 
>>> activated until someone needs it and will pick up however many are then 
>>> available, even without the cardinality set.
>>
>> Dilemma: B3's job in life is to publish a JAX-RS service via CXF,
>> which does not involve publishing an OSGi service. So I may need to
>> stick with one of these less-than-ideal alternatives.
>>
>>
>>>
>>> david jencks
>>>
>>>> On Sep 7, 2015, at 11:46 AM, Neil Bartlett <njbartl...@gmail.com> wrote:
>>>>
>>>> Just to add a bit of detail…
>>>>
>>>> If you wait for 5 service instances before performing your initialisation, 
>>>> that’s great. But bear in mind that you might get a 6th and a 7th very 
>>>> soon afterwards, and depending on your implementation you may have to 
>>>> re-initialise each time that happens.
>>>>
>>>> If your (re)initialisation is expensive, you might want to avoid doing it 
>>>> too many times, especially if there is a rapid sequence of changes. This 
>>>> is typically the case during application startup for example. There are 
>>>> two general solutions to this:
>>>>
>>>> 1) You could start a timer each time the service set changes. If there are 
>>>> no further changes before the timer expires, then you do your 
>>>> reinitialisation. If there *are* changes then you cancel the existing 
>>>> timer and start a new one.
>>>>
>>>> 2) Use the Coordinator Service (OSGi Compendium Specification, chapter 
>>>> 130). Whoever is making changes to the set of installed bundles — e.g. the 
>>>> launcher, or some kind of management agent like FileInstall — should start 
>>>> a Coordination before it does anything, and end the coordination after 
>>>> that series of changes. Your component should be a Participant which 
>>>> detects whether there is a current coordination. If there is NO current 
>>>> coordination then it should immediately action any changes in the service 
>>>> set. However if there is a current coordination, then those changes should 
>>>> only be actioned when the coordination ends. This has the advantage that 
>>>> you don’t waste time waiting for an arbitrary-length timer to expire.
>>>>
>>>> Hope that helps. Regards,
>>>> Neil
>>>>
>>>>
>>>>
>>>>> On 7 Sep 2015, at 16:16, Benson Margulies <ben...@basistech.com> wrote:
>>>>>
>>>>> That is precisely what I needed. Thanks.
>>>>> On Sep 7, 2015 11:06 AM, "David Jencks" <david_jen...@yahoo.com.in

Re: How to 'let the dust settle' with DS?

[Benson Margulies]

The use of REQUIRED seems to be landing me with an unsatisfiable reference.

Here's the situation with the 'B2' service, which seems to be very happy:

 23 | Active   |  76 | 1.5.0.v20150907054257 | rosapi-worker-dummy-sdk
karaf@root>bundle:services 23

rosapi-worker-dummy-sdk (23) provides:
--
[com.basistech.ws.worker.api.WorkerComponentService]


karaf@root>scr:details
com.basistech.ws.sdk.dummy.impl.DummyWorkerComponentServiceImpl
Component Details
  Name:
com.basistech.ws.sdk.dummy.impl.DummyWorkerComponentServiceImpl
  State   : REGISTERED
  Properties  :
component-name=template-tokenization
ComponentService.target=(component-name=template-tokenization)

component.name=com.basistech.ws.sdk.dummy.impl.DummyWorkerComponentServiceImpl
Warmup.target=(component-name=template-tokenization)
component.id=1
References
  Reference   : ComponentService
State : satisfied
Multiple  : single
Optional  : mandatory
Policy: static
Service Reference : No Services bound
  Reference   : Warmup
State : satisfied
Multiple  : single
Optional  : mandatory
Policy: static
Service Reference : No Services bound

For B3:

On my component, I have:

@Component(configurationPolicy = ConfigurationPolicy.REQUIRE,
configurationPid = "com.basistech.ws.worker")

and then:

@Reference(cardinality = ReferenceCardinality.AT_LEAST_ONE)
public void setAllComponents(List allComponents) {

But...


karaf@root>scr:details com.basistech.ws.worker.service.Worker
Component Details
  Name: com.basistech.ws.worker.service.Worker
  State   : UNSATISFIED
  Properties  :
service.pid=com.basistech.ws.worker

configurationFilePathname=/Users/benson/x/rosapi1.5/assemblies/minimal-test/target/assembly/etc/anvils/worker-config.yaml
component.name=com.basistech.ws.worker.service.Worker

felix.fileinstall.filename=file:/Users/benson/x/rosapi1.5/assemblies/minimal-test/target/assembly/etc/com.basistech.ws.worker.cfg
component.id=2
References
  Reference   : AllComponents
State : unsatisfied
Multiple  : multiple
Optional  : mandatory
Policy: static
Service Reference : No Services bound
  Reference   : Bus
State : satisfied
Multiple  : single
Optional  : mandatory
Policy: static
Service Reference : No Services bound

On Mon, Sep 7, 2015 at 1:17 PM, Benson Margulies <ben...@basistech.com> wrote:
> On Mon, Sep 7, 2015 at 1:12 PM, David Jencks
> <david_jen...@yahoo.com.invalid> wrote:
>> If cxf really does not have this capability, which I find hard to believe, I 
>> would do the “publish to cxf” generically by having a component with a 
>> dynamic reference (or a service tracker, but if your component is DS a 
>> dynamic reference is easier) that uses service properties to figure out what 
>> to tell cxf.
>>
>> A pretty simple example of how to do this is in the aries imx jmx-whiteboard 
>> project, which is more complicated than you would need since it has to deal 
>> with multiple MBean servers whereas I think you would have only one cxf.
>
> I am studying the relevant CXF code now, but I think that the thing
> you are looking for (register a service and CXF publishes it) will
> exist only if I make it exist.
>
> I have made a first pass at coding what you wrote here, but it doesn't
> work yet. What a surprise. More spelunking to do.
>
>
>
>>
>> thanks
>> david jencks
>>
>>> On Sep 7, 2015, at 12:46 PM, Benson Margulies <ben...@basistech.com> wrote:
>>>
>>> On Mon, Sep 7, 2015 at 12:45 PM, David Jencks
>>> <david_jen...@yahoo.com.invalid <mailto:david_jen...@yahoo.com.invalid>> 
>>> wrote:
>>>> I think both of those suggestions are rather inappropriate to be used in a 
>>>> DS component activate method, which generally should not block….. although 
>>>> having it take a long time is also very much less than ideal.
>>>>
>>>> Certainly the second method seems to imply someone knows how many B2s 
>>>> there  are so the minimum cardinality can be set based on that knowledge, 
>>>> possibly by whatever code has that knowledge.  The (proprietary) 
>>>> metatype/config admin I work with does this, it can count how many cm 
>>>> Configurations there are for B2 and set properties based on that.
>>>>
>>>> If you make B3 expose a service and not be immediate, then it won’t be 
>>>> activated until someone needs i

Re: How to 'let the dust settle' with DS?

[Benson Margulies]

On Mon, Sep 7, 2015 at 11:46 AM, Neil Bartlett <njbartl...@gmail.com> wrote:
> Just to add a bit of detail…
>
> If you wait for 5 service instances before performing your initialisation, 
> that’s great. But bear in mind that you might get a 6th and a 7th very soon 
> afterwards, and depending on your implementation you may have to 
> re-initialise each time that happens.
>
> If your (re)initialisation is expensive, you might want to avoid doing it too 
> many times, especially if there is a rapid sequence of changes. This is 
> typically the case during application startup for example. There are two 
> general solutions to this:
>
> 1) You could start a timer each time the service set changes. If there are no 
> further changes before the timer expires, then you do your reinitialisation. 
> If there *are* changes then you cancel the existing timer and start a new one.
>
> 2) Use the Coordinator Service (OSGi Compendium Specification, chapter 130). 
> Whoever is making changes to the set of installed bundles — e.g. the 
> launcher, or some kind of management agent like FileInstall — should start a 
> Coordination before it does anything, and end the coordination after that 
> series of changes. Your component should be a Participant which detects 
> whether there is a current coordination. If there is NO current coordination 
> then it should immediately action any changes in the service set. However if 
> there is a current coordination, then those changes should only be actioned 
> when the coordination ends. This has the advantage that you don’t waste time 
> waiting for an arbitrary-length timer to expire.
>
> Hope that helps. Regards,
> Neil

Neil, thanks.

To begin with, I'm going to have a static collection of services
present in the Karaf container via the Karaf assembly mechanism. I
just need to start up in an orderly way with them. I may never need or
want to add or subtract on the fly.


>
>
>
>> On 7 Sep 2015, at 16:16, Benson Margulies <ben...@basistech.com> wrote:
>>
>> That is precisely what I needed. Thanks.
>> On Sep 7, 2015 11:06 AM, "David Jencks" <david_jen...@yahoo.com.invalid>
>> wrote:
>>
>>> Hi Benson,
>>>
>>> I don’t really understand what you are asking, but I’m going to guess.
>>>
>>> I think you have say 5  B2 services and you want B3 to wait to activate
>>> until all 5 B2’s are available?
>>>
>>> There is a way to do this with DS 1.3, but you have to make B3
>>> configuration-policy=REQUIRE.
>>>
>>> So you have in B3:
>>> @Component(configuration-policy=REQUIRE)
>>> public class B3 {
>>>
>>> @Reference(cardinality=MULTIPLE)
>>> void setB2(B2 b2) {}
>>> }
>>> In your (required) configuration for B3 you put a property
>>>
>>> B2.cardinality.minimum: 5
>>>
>>> that is, .cardinality.minimum = 
>>>
>>> Don’t mess with start levels, they will be unreliable for this purpose.
>>> There’s no guarantee that a bundle starting will start all the DS services
>>> it provides.  They might have all sorts of unsatisfied dependencies….. such
>>> as missing configurations.
>>>
>>> Let me know if this guess is a total miss :-)
>>>
>>> thanks
>>> david jencks
>>>
>>>
>>>
>>>> On Sep 7, 2015, at 10:52 AM, Benson Margulies <ben...@basistech.com>
>>> wrote:
>>>>
>>>> I am hoping that David Jencks will continue his charity to strangers
>>> here.
>>>>
>>>> David, if you have any gogo jiras you'd like help with in return, just
>>> ask.
>>>>
>>>> Three bundles:
>>>>
>>>> B1 registers service S1.
>>>>
>>>> B2 consumes S1 and uses it in the implementation of S2. That is to
>>>> say, it picks up a reference to S1 with a DS @Reference with
>>>> cardinality MANDATORY.
>>>>
>>>> B3 consumes B2, but it anticipates that B2 will have siblings. So it
>>>> consumes a reference to a List with cardinality AT_LEAST_ONE.
>>>>
>>>> It can take B2 and buddies a bit of time to activate.
>>>>
>>>> I appreciate that the most general case is intended to be that
>>>> services come and go, and B3 should dynamically reconfigure itself.
>>>> I'd rather not do that yet; I'd like to arrange things so that B3
>>>> waits to finish starting itself until all the B2-ish guys are fully
>>>> set up.
>>>>
>>>> Assuming that 

Re: How to 'let the dust settle' with DS?

[Benson Margulies]

Apparently, I can't read, either. Please ignore the last question I
stuck on the end, which you had just answered.

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: How to 'let the dust settle' with DS?

[Benson Margulies]

This is easy to explain. The version of felix scr in karaf is too old.

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: How to 'let the dust settle' with DS?

[Benson Margulies]

The cardinality in the config admin does not seem to be sticking:

@Component(configurationPolicy = ConfigurationPolicy.REQUIRE,
configurationPid = "com.basistech.ws.worker")

And:

@Reference(cardinality = ReferenceCardinality.MULTIPLE, policyOption =
ReferencePolicyOption.GREEDY)
public void setWorkerComponentService(WorkerComponentService
workerComponentService) {

And in the relevant Karaf cfg file (com.basistech.ws.worker.cfg):

# This is a DS property. It tells DS that there is one component
service that we are consuming.
WorkerComponentService.cardinality.minimum=1

And the reference name in the DS metadata is WorkerComponentService.

but the component goes ahead and activates when it has none (due to
leaving out the component); the activation throws an exception due to
my own code complaining.

In spite of the exception thrown in the @Activate method, the
component goes to REGISTERED, is there some particular exception that
would prevent that?

I have it working (up to the point of fun with Json deserialization
from CXF, which is also working mostly) by putting the component in
place, but eventually I need the constraint to hold things up; and it
would be nice to have a way for an exception in activation to stop the
train.

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: How to 'let the dust settle' with DS?

[Benson Margulies]

On Mon, Sep 7, 2015 at 4:07 PM, David Jencks
<david_jen...@yahoo.com.invalid> wrote:
> So it looks like we lost most of the thread but to try to keep this from 
> turning into more of a tangled ball of yarn the cat played with….

I'm sorry to be so poor at communicating.
>
>
> 1) NO!:
>
> @Reference(cardinality = ReferenceCardinality.AT_LEAST_ONE)
> public void setAllComponents(List allComponents) {
>
>
> This might be a blueprint-ism but DOESNT WORK FOR DS
>
> The event methods (bind/unbind/updated) don’t have to be called anything in 
> particular but they need to take only ONE service/service 
> reference/properties NOT a collection.

Oh, so they get called more than once? Yea, apparently I caught a
social disease from Blueprint!


>
> So
> @Reference(cardinality = ReferenceCardinality.AT_LEAST_ONE)
> public void setWorkerComponentService(WorkerComponentService wcs) { …}
>
> If you use DS 1.3 reference fields it can be a collection valued field.  I’ve 
> never used these except possibly in some tests.
>
> 2) the minimum cardinality property has to be supplied from config admin, not 
> component.xml.  So it is runtime modifiable.  I might have missed it but I 
> didn’t see what your configuration was or how you were installing it.  You 
> cannot set the minimum cardinality at compile time.

OK, I get it. That does simplify things.

>
> I think you are making life too hard for yourself.  From your description, 
> when you set up the deployment of your stuff, you know exactly how many 
> WorkerComponentService instances to expect, so you can put that value in the 
> configuration.  Then DS will do the waiting for you, and your restful service 
> component will get the references and activate once the appropriate number 
> are ready.  If you expect to have more WorkerComponentServices registered, 
> say 10, and want to restrict yourself to only using a particular 5 of them, 
> you can, along with the cardinality to assure you get at least 5, use a 
> target filter to find the exact 5 you want.  For instance, if the 
> WorkerComponentServices have a “type” property that identifies which one they 
> are, your filter in the configuration would look something like
>
> WorkerComponentService.cardinality.minimum=5
> WorkerComponentService.target=“(|(type=foo1)(type=foo2)(type=foo3)(type=foo4)(type=foo5))”

Do I really have to enumerate the types if I happen to have
provisioned only the ones I want.

>
> Wiring up DS services is really powerful.  I haven’t figured out the exact 
> computational strength available but to me it has the feel of logic 
> programming.
>
> thanks
> david jencks
>
>
>
>> On Sep 7, 2015, at 2:55 PM, Benson Margulies <ben...@basistech.com> wrote:
>>
>> I think I now understand what I have failed to explain here (and I
>> probably know why my service is acting like tantalus).
>>
>> My plan is to create a series of docker containers. Call them
>> 'workers'. Each worker publishes the same restful service; each one of
>> them handles one or more 'tasks'. The worker accepts work via a single
>> RESTful service, and dispatches the work to the tasks based on
>> parameters in the requests to the service.
>>
>> The set of tasks implemented on a particular worker is controlled the
>> set of OSGi bundles I provision in it. I have a whole slew of them,
>> each registers a 'RosetteComponentService'.
>>
>> Each of these task bundles has, potentially, a bit of a startup delay
>> as it gets organized.
>>
>> I don't want to open the restful service until the components are all set up.
>>
>> In spite of all the email I've sent up to this point, it dawns on me,
>> a bit belatedly, that my own configuration file for a worker does list
>> the components that it expects to find.
>>
>> So, I can set up a protocol where the restful service component waits
>> for all the components to 'light up' and then lights itself up, since
>> it knows what is supposed to be there. But not at compile time, so I
>> can't use a cardinality property.
>>
>> One approach would be to @Reference the list, and then do a little
>> sleep loop waiting until everyone arrives. I am going to go read on
>> event admin to see if I can use that to sleep on an event that would
>> indicate that a new example has shown up.
>>
>> Thanks for all your patience; I think this much will keep me out of
>> your hair for a while.
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org