from:"Roy Teeuwen"

Websockets in Apache Felix / OSGi

2023-01-19 Thread Roy Teeuwen

Hey all,

I'd like to create a websockets servlet in Apache Felix and I'm searching for 
good examples. 
When trying to install a standard websocket example using javax.websocket as 
package, I see that the package is not provided by default with Apache Felix. 
Is there any way I can use the HTTP Service to active my endpoint annotated 
with @ServerEndpoint?

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

Re: Optional OSGi Service

2023-01-14 Thread Roy Teeuwen

Damn, bad blog post I copy pasted from ;) thanks!

> On 14 Jan 2023, at 19:11, Richard Hall  wrote:
> 
> I think the syntax is "resolution:=optional" since that is a directive, not
> a matching attribute.
> 
> 
> On Sat, Jan 14, 2023, 12:27 Roy Teeuwen  wrote:
> 
>> Hey all,
>> 
>> I am creating an OSGi bundle that has some OSGi services which import
>> packages that might or might not be available in the OSGi environment. I
>> want the bundle to become active, but the OSGi services itself to not
>> become active if the packages are not available to be imported.
>> 
>> I already stated in the Import-Package:
>> com.optional.package.*;resolution=optional,* and the Manifest.MF file seems
>> to be ok, but when I install the bundle, I still get the following
>> exception:
>> 
>> 14.01.2023 17:23:12.350 *INFO* [OsgiInstallerImpl]
>> org.apache.sling.installer.core.impl.tasks.BundleStartTask Could not start
>> bundle test-bundle [225]. Reason: {}. Will retry.
>> org.osgi.framework.BundleException: Unable to resolve test-bundle [225](R
>> 225.5): missing requirement [test-bundle [225](R 225.5)]
>> osgi.wiring.package;
>> (&(osgi.wiring.package=com.optional.package.mailer)(resolution=optional)(version>=6.0.0)(!(version>=7.0.0)))
>> Unresolved requirements: [[test-bundle [225](R 225.5)] osgi.wiring.package;
>> (&(osgi.wiring.package=com.optional.package.mailer)(resolution=optional)(version>=6.0.0)(!(version>=7.0.0)))]
>>at
>> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4398)
>>at org.apache.felix.framework.Felix.startBundle(Felix.java:2308)
>>at
>> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:1006)
>>at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:992)
>>at
>> org.apache.sling.installer.core.impl.tasks.BundleStartTask.execute(BundleStartTask.java:97)
>> [org.apache.sling.installer.core:3.12.0]
>>at
>> org.apache.sling.installer.core.impl.OsgiInstallerImpl.doExecuteTasks(OsgiInstallerImpl.java:918)
>> [org.apache.sling.installer.core:3.12.0]
>>at
>> org.apache.sling.installer.core.impl.OsgiInstallerImpl.executeTasks(OsgiInstallerImpl.java:755)
>> [org.apache.sling.installer.core:3.12.0]
>>at
>> org.apache.sling.installer.core.impl.OsgiInstallerImpl.run(OsgiInstallerImpl.java:304)
>> [org.apache.sling.installer.core:3.12.0]
>>at java.base/java.lang.Thread.run(Thread.java:833)
>> 
>> What can I do to make the bundle become active and ignore the OSGi
>> services that have optional requirements that are not available?
>> 
>> Thanks!
>> Roy


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

Optional OSGi Service

2023-01-14 Thread Roy Teeuwen

Hey all,

I am creating an OSGi bundle that has some OSGi services which import packages 
that might or might not be available in the OSGi environment. I want the bundle 
to become active, but the OSGi services itself to not become active if the 
packages are not available to be imported.

I already stated in the Import-Package: 
com.optional.package.*;resolution=optional,* and the Manifest.MF file seems to 
be ok, but when I install the bundle, I still get the following exception:

14.01.2023 17:23:12.350 *INFO* [OsgiInstallerImpl] 
org.apache.sling.installer.core.impl.tasks.BundleStartTask Could not start 
bundle test-bundle [225]. Reason: {}. Will retry.
org.osgi.framework.BundleException: Unable to resolve test-bundle [225](R 
225.5): missing requirement [test-bundle [225](R 225.5)] osgi.wiring.package; 
(&(osgi.wiring.package=com.optional.package.mailer)(resolution=optional)(version>=6.0.0)(!(version>=7.0.0)))
 Unresolved requirements: [[test-bundle [225](R 225.5)] osgi.wiring.package; 
(&(osgi.wiring.package=com.optional.package.mailer)(resolution=optional)(version>=6.0.0)(!(version>=7.0.0)))]
at 
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4398)
at org.apache.felix.framework.Felix.startBundle(Felix.java:2308)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:1006)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:992)
at 
org.apache.sling.installer.core.impl.tasks.BundleStartTask.execute(BundleStartTask.java:97)
 [org.apache.sling.installer.core:3.12.0]
at 
org.apache.sling.installer.core.impl.OsgiInstallerImpl.doExecuteTasks(OsgiInstallerImpl.java:918)
 [org.apache.sling.installer.core:3.12.0]
at 
org.apache.sling.installer.core.impl.OsgiInstallerImpl.executeTasks(OsgiInstallerImpl.java:755)
 [org.apache.sling.installer.core:3.12.0]
at 
org.apache.sling.installer.core.impl.OsgiInstallerImpl.run(OsgiInstallerImpl.java:304)
 [org.apache.sling.installer.core:3.12.0]
at java.base/java.lang.Thread.run(Thread.java:833)

What can I do to make the bundle become active and ignore the OSGi services 
that have optional requirements that are not available?

Thanks!
Roy

Fwd: Updating OSGI weaving hooks at runtime

2020-08-10 Thread Roy Teeuwen

Trying it out here if there may be more response

> Begin forwarded message:
> 
> From: Roy Teeuwen 
> Subject: Updating OSGI weaving hooks at runtime
> Date: 5 August 2020 at 08:49:09 CEST
> To: Apache Felix Developer List 
> 
> Hey devs,
> 
> I found a repo with some weaving hooks examples 
> (https://github.com/bdelacretaz/OSGi-weaving-hook-examples/blob/master/src/main/java/ch/x42/osgi/weavinghook/LogMethodCallsHook.java
>  
> <https://github.com/bdelacretaz/OSGi-weaving-hook-examples/blob/master/src/main/java/ch/x42/osgi/weavinghook/LogMethodCallsHook.java>,
>  even though it is pretty old) and found it interesting. What I would like to 
> try out is to mimick the behaviour of Rookout ( https://www.rookout.com/ 
> <https://www.rookout.com/> ). Rookout allows (read-only) debugging of a 
> production instance by adding a java agent that is able to get object field 
> values at runtime without attaching a real java remote debugging instance.
> 
> How I would like to mimick this is by creating an OSGi Weaving Hook, based on 
> the LogMethodCallsHook class, that would allow you to create an OSGi weaving 
> hook at runtime by creating for example an OSGi configuration factory that 
> registers a weaving hook for a class with a method in a specific bundle. Do 
> you see this feasible? Is it possible to register a weaving hook without 
> having to reload the entire bundle again and going through the Activator 
> method again?
> 
> I already had a comment from the repo owner himself and he doesn’t think its 
> feasable but he gave me the remark to ask here as well! 
> (https://github.com/bdelacretaz/OSGi-weaving-hook-examples/issues/1 
> <https://github.com/bdelacretaz/OSGi-weaving-hook-examples/issues/1>)
> 
> Thanks!
> Roy

Re: Elasticsearch rest client

2018-11-26 Thread Roy Teeuwen

That would be nice Alain, thanks!

> On 25 Nov 2018, at 23:01, Alain Picard  
> wrote:
> 
> Roy,
> 
> Right now I'm including all of those jar in my bundle classpath, I have not
> yet integrated this as part of our target platform with a formal
> repository. I can always provide you with a jar of our PDE project with
> just the Elasticsearch piece.
> 
> Let me know what you want to do
> 
> Alain
> 
> 
> On Sun, Nov 25, 2018 at 3:09 PM Roy Teeuwen  wrote:
> 
>> Hey Alain,
>> 
>> Thanks! You don't happen to have a pom / plugin example to build this jar?
>> Would make it a bit easier.
>> 
>> @Francois @Jean-Baptiste thanks! Didn't know about the JestClient, maybe
>> this will do as well, it makes it already a bit better than the low level
>> one, but having a real builder like the rest-client would still be more
>> prefereable
>> 
>> Greets,
>> Roy
>> 
>>> On 24 Nov 2018, at 15:44, Alain Picard 
>> wrote:
>>> 
>>> Roy,
>>> 
>>> Not sure how well that will match for you, but here's the list from our
>>> search bundle and it includes the high-level client.
>>> 
>>> YMMV
>>> 
>>> Cheers,
>>> Alain
>>> 
>>> lib/elasticsearch-6.4.0.jar,
>>> lib/elasticsearch-rest-high-level-client-6.4.0.jar,
>>> lib/elasticsearch-rest-client-6.4.0.jar,
>>> lib/elasticsearch-core-6.4.0.jar,
>>> lib/lucene-core-7.4.0.jar,
>>> lib/lucene-queryparser-7.4.0.jar,
>>> lib/lucene-join-7.4.0.jar,
>>> lib/transport-6.4.0.jar,
>>> lib/log4j-api-2.11.1.jar,
>>> lib/elasticsearch-x-content-6.4.0.jar,
>>> lib/lang-mustache-client-6.4.0.jar,
>>> lib/rank-eval-client-6.4.0.jar,
>>> lib/httpasyncclient-4.1.2.jar,
>>> lib/transport-netty4-client-6.4.0.jar,
>>> lib/reindex-client-6.4.0.jar,
>>> lib/percolator-client-6.4.0.jar,
>>> lib/parent-join-client-6.4.0.jar,
>>> lib/hppc-0.7.1.jar,
>>> lib/jackson-core-2.9.0.jar,
>>> lib/netty-common-4.1.16.Final.jar,
>>> lib/netty-buffer-4.1.16.Final.jar,
>>> lib/netty-transport-4.1.16.Final.jar,
>>> lib/lucene-sandbox-7.4.0.jar,
>>> lib/elasticsearch-cli-6.4.0.jar,
>>> lib/lucene-highlighter-7.4.0.jar,
>>> lib/lucene-queries-7.4.0.jar,
>>> lib/t-digest-3.2.jar,
>>> lib/lucene-misc-7.4.0.jar,
>>> lib/netty-resolver-4.1.16.Final.jar,
>>> lib/netty-handler-4.1.16.Final.jar,
>>> lib/netty-codec-4.1.16.Final.jar,
>>> lib/joda-time-2.9.9.jar
>>> 
>>> 
>>> 
>>> On Sat, Nov 24, 2018 at 9:08 AM Roy Teeuwen  wrote:
>>> 
>>>> Hey,
>>>> 
>>>> I am trying to use the Elasticsearch rest client (version 6) in Felix /
>>>> Sling, but it seems I am only capable of using the (wrapped) low level
>> rest
>>>> client because the high level one has sooo many dependencies and I
>> haven't
>>>> been capable to get it to work yet. Anyone maybe ever made a wrapper for
>>>> the v6 that has all the dependencies embedded and only the correct
>> packages
>>>> for using it as client exported?
>>>> 
>>>> Thanks,
>>>> Roy
>>>> -
>>>> 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: Elasticsearch rest client

2018-11-25 Thread Roy Teeuwen

Hey Alain,

Thanks! You don't happen to have a pom / plugin example to build this jar? 
Would make it a bit easier.

@Francois @Jean-Baptiste thanks! Didn't know about the JestClient, maybe this 
will do as well, it makes it already a bit better than the low level one, but 
having a real builder like the rest-client would still be more prefereable

Greets,
Roy

> On 24 Nov 2018, at 15:44, Alain Picard  
> wrote:
> 
> Roy,
> 
> Not sure how well that will match for you, but here's the list from our
> search bundle and it includes the high-level client.
> 
> YMMV
> 
> Cheers,
> Alain
> 
> lib/elasticsearch-6.4.0.jar,
> lib/elasticsearch-rest-high-level-client-6.4.0.jar,
> lib/elasticsearch-rest-client-6.4.0.jar,
> lib/elasticsearch-core-6.4.0.jar,
> lib/lucene-core-7.4.0.jar,
> lib/lucene-queryparser-7.4.0.jar,
> lib/lucene-join-7.4.0.jar,
> lib/transport-6.4.0.jar,
> lib/log4j-api-2.11.1.jar,
> lib/elasticsearch-x-content-6.4.0.jar,
> lib/lang-mustache-client-6.4.0.jar,
> lib/rank-eval-client-6.4.0.jar,
> lib/httpasyncclient-4.1.2.jar,
> lib/transport-netty4-client-6.4.0.jar,
> lib/reindex-client-6.4.0.jar,
> lib/percolator-client-6.4.0.jar,
> lib/parent-join-client-6.4.0.jar,
> lib/hppc-0.7.1.jar,
> lib/jackson-core-2.9.0.jar,
> lib/netty-common-4.1.16.Final.jar,
> lib/netty-buffer-4.1.16.Final.jar,
> lib/netty-transport-4.1.16.Final.jar,
> lib/lucene-sandbox-7.4.0.jar,
> lib/elasticsearch-cli-6.4.0.jar,
> lib/lucene-highlighter-7.4.0.jar,
> lib/lucene-queries-7.4.0.jar,
> lib/t-digest-3.2.jar,
> lib/lucene-misc-7.4.0.jar,
> lib/netty-resolver-4.1.16.Final.jar,
> lib/netty-handler-4.1.16.Final.jar,
> lib/netty-codec-4.1.16.Final.jar,
> lib/joda-time-2.9.9.jar
> 
> 
> 
> On Sat, Nov 24, 2018 at 9:08 AM Roy Teeuwen  wrote:
> 
>> Hey,
>> 
>> I am trying to use the Elasticsearch rest client (version 6) in Felix /
>> Sling, but it seems I am only capable of using the (wrapped) low level rest
>> client because the high level one has sooo many dependencies and I haven't
>> been capable to get it to work yet. Anyone maybe ever made a wrapper for
>> the v6 that has all the dependencies embedded and only the correct packages
>> for using it as client exported?
>> 
>> Thanks,
>> Roy
>> -
>> 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

Elasticsearch rest client

2018-11-24 Thread Roy Teeuwen

Hey,

I am trying to use the Elasticsearch rest client (version 6) in Felix / Sling, 
but it seems I am only capable of using the (wrapped) low level rest client 
because the high level one has sooo many dependencies and I haven't been 
capable to get it to work yet. Anyone maybe ever made a wrapper for the v6 that 
has all the dependencies embedded and only the correct packages for using it as 
client exported?

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

Re: Deep Dependency Issue

2018-11-24 Thread Roy Teeuwen

Hey,

You could have a look at 
https://github.com/apache/sling-org-apache-sling-scripting-thymeleaf 


Thats an osgi bundle for thymeleaf

Greets,
Roy

> On 24 Nov 2018, at 14:34, Rob McKinnon  wrote:
> 
> I am trying to add Thymeleaf to an OSGi bundle and I am running into
> dependency issues. As I add the dependencies from the maven dependency:tree
> report I see further decencies for JDK level stuff like.
> 
> (&(package=com.sun.jdi.connect))
> (&(package=com.sun.jdi))
> 
> Is there a way around this? I am assuming I would need to add such things
> into my bundle.
> 
> 
> Thanks,
> 
> Rob

Creating a fatJar with only the classes / methods actually being used

2018-02-19 Thread Roy Teeuwen

Hey guys,

I am trying to use Elasticsearch in an OSGi environment, which doesn't seem to 
be that easy. They have two jars that they provide as clients (since 
elasticsearch 5)

- elasticsearch-rest-client
- elasticsearch-rest-high-level-client [1]

The first one is a low level api client, it uses apache http client to send 
json requests to a elasticsearch cluster. The second one, the high level 
client, uses the low level client and has all the marshalling and unmarshalling 
of the results included. How this was built though, is by using the already 
existing classes before elasticsearch 5, which had a internal java transport 
client inside the core elasticsearch project, and use those to marshall and 
unmarshall. This way existing clients didn't need a big migration to the new 
high level client.

This of course comes with a downside, if you want to use the high level client, 
you have to include the entire elasticsearch jar, and in consequence all the 
dependencies, which is a lot more than you want from just a rest client jar. So 
what I would like to achieve is to sort of shade a fatJar which takes the 
elasticsearch-rest-high-level-client jar, which only has like 4 java classes!, 
and calculate all the needed classes to run those 4 java classes and put them 
in one fatJar. In the end this shouldn't be that big of a jar, seeing as its 
only the GetResponse, GetResult, SearchHits and classes like that, that will be 
taken from the core elasticsearch jar and be included.

Is there an easy way to achieve this? I know you can inline classes with the 
bundle plugin, so it would just need a bit of more "automagic" to make it work 
;)

Greets,
Roy

[1] 
https://www.elastic.co/guide/en/elasticsearch/client/java-rest/current/java-rest-high.html
 



signature.asc
Description: Message signed with OpenPGP

Re: [ANN] New Apache Felix PMC Chair: Karl Pauls

2017-11-16 Thread Roy Teeuwen

Congratulations Karl!

Greets,
Roy

> On 16 Nov 2017, at 15:25, Carsten Ziegeler  wrote:
> 
> Hi,
> 
> it's my pleasure to announce that Karl took up the role as our new PMC
> chair.
> 
> Congrats Karl!
> 
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org



signature.asc
Description: Message signed with OpenPGP

Re: Which osgi core dependency to use in maven projects

2017-05-12 Thread Roy Teeuwen

Hey Mark,

But for this to work, you have to know which interfaces Felix supports of OSGi 
R6, no? Because else why not write everything against the 6.0.0 dependency?

Greets,
Roy
> On 11 May 2017, at 11:39, list+org.apache.fe...@io7m.com wrote:
> 
> On 2017-05-09T21:33:46 +0200
> Roy Teeuwen  wrote:
> 
>> Hey all,
>> 
>> I was wondering how you can know what version you can use as dependency in 
>> your maven project when using felix. For example my current project has as 
>> system bundle org.apache.felix.framework version 4.6.1. How can I know then 
>> what artifact version I can use for org.osgi.core then?
>> 
>> I see that the following header is provided, does that help me?
>> 
>> Provide-Capability: osgi.ee; osgi.ee="OSGi/Minimum"; version:List="1.0, 1.1, 
>> 1.2", osgi.ee; osgi.ee="JavaSE"; version:List="1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 
>> 1.6, 1.7, 1.8"
> 
> Hello.
> 
> I think you have to think in terms of the version(s) of the OSGi APIs
> that you need. For example, if you're writing code that depends on the
> interfaces and semantics provided by OSGi R6, then you'd probably use a
> dependency like:
> 
>  
>org.osgi
>org.osgi.core
>[6.0.0, 7.0.0)
>provided
>  
> 
> The specification versions going back to 4.0.0 are in Central.
> 
> M



signature.asc
Description: Message signed with OpenPGP

Which osgi core dependency to use in maven projects

2017-05-09 Thread Roy Teeuwen

Hey all,

I was wondering how you can know what version you can use as dependency in your 
maven project when using felix. For example my current project has as system 
bundle org.apache.felix.framework version 4.6.1. How can I know then what 
artifact version I can use for org.osgi.core then?

I see that the following header is provided, does that help me?

Provide-Capability: osgi.ee; osgi.ee="OSGi/Minimum"; version:List="1.0, 1.1, 
1.2", osgi.ee; osgi.ee="JavaSE"; version:List="1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 
1.6, 1.7, 1.8"

Thanks!
Roy



signature.asc
Description: Message signed with OpenPGP

Re: Using OSGi DS and old Apache Felix SCR together

2017-03-17 Thread Roy Teeuwen

Hey Stefan,

I used the plugin in the maven-bundle-plugin, but it seems that some of my 
bundles give following exception, any idea what might be causing this?

[ERROR] Manifest mygroupId:myartifactId:bundle:30.0-SNAPSHOT : Got unexpected 
exception while analyzing:org.apache.felix.scrplugin.SCRDescriptorException: 
Unable to load compiled class: 
org.apache.commons.collections.DoubleOrderedMap$1$1
at 
org.apache.felix.scrplugin.helper.ClassScanner.scanSources(ClassScanner.java:156)
at 
org.apache.felix.scrplugin.SCRDescriptorGenerator.execute(SCRDescriptorGenerator.java:146)
at 
org.apache.felix.scrplugin.bnd.SCRDescriptorBndPlugin.analyzeJar(SCRDescriptorBndPlugin.java:178)
at aQute.bnd.osgi.Analyzer.doPlugins(Analyzer.java:656)
at aQute.bnd.osgi.Analyzer.analyze(Analyzer.java:209)
at aQute.bnd.osgi.Builder.analyze(Builder.java:389)
at aQute.bnd.osgi.Analyzer.calcManifest(Analyzer.java:687)
at aQute.bnd.osgi.Builder.build(Builder.java:105)
at 
org.apache.felix.bundleplugin.ManifestPlugin.getAnalyzer(ManifestPlugin.java:291)
at 
org.apache.felix.bundleplugin.ManifestPlugin.execute(ManifestPlugin.java:98)
at 
org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:384)
at 
org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:375)
at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at 
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
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:498)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
at org.codehaus.classworlds.Launcher.main(Launcher.java:47)
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:498)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
Caused by: java.lang.IllegalAccessError: class 
org.apache.commons.collections.DoubleOrderedMap$1$1 cannot access its 
superclass 
org.apache.commons.collections.DoubleOrderedMap$DoubleOrderedMapIterator
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at 
org.apache.felix.scrplugin.helper.ClassScanner.scanSources(ClassScanner.java:144)
... 39 more

Thanks!
Roy

> On 16 Mar 2017, at 17:49, Stefan Seifert  wrote:
> 
> 
>> I think the bnd support is for the proprietary bnd an

Re: Using OSGi DS and old Apache Felix SCR together

2017-03-16 Thread Roy Teeuwen

Hey Stefan,

Thanks, thats exactly what I need! And yes, we are in the process of making all 
the new services in OSGi DS annotations and gradually migrating the Apache 
Felix SCR annotations to the new OSGi DS, but this will help to make it an 
incremental process instead of having to do everything at once.

Greets,
Roy

> On 16 Mar 2017, at 10:09, Stefan Seifert  wrote:
> 
> you should not use the maven-scr-plugin at all in this case - there is a bnd 
> plugin for the old felix SCR annotations that does the same job.
> so use only maven-bundle-plugin and add an instruction
> <_plugin>org.apache.felix.scrplugin.bnd.SCRDescriptorBndPlugin;destdir=${project.build.outputDirectory}
> 
> for a full example see [1]
> 
> on the long run you should migrate to the OSGi annotations and remove the 
> felix scr annotations.
> 
> stefan
> 
> [1] 
> https://github.com/wcm-io/wcm-io-tooling/blob/develop/maven/aem-global-parent/pom.xml
> 
> 
>> -Original Message-
>> From: Roy Teeuwen [mailto:r...@teeuwen.be]
>> Sent: Thursday, March 16, 2017 9:03 AM
>> To: users@felix.apache.org
>> Subject: Using OSGi DS and old Apache Felix SCR together
>> 
>> Hey all,
>> 
>> I am running in a problem when trying to use OSGi DS annotations and Apache
>> Felix annotations together. I have unit tests that depend on the service
>> xml's being present (I am using the Apache Sling osgi-mock to run unit
>> tests), but the problem that I am facing is that when the maven-bundle-
>> plugin:manifest phase has been executed, the maven-scr-plugin deletes the
>> maven-bundle-plugin xml's again created by the maven-bundle manifest phase,
>> is there any way to avoid this and make it that they are merged togheter?
>> All xmls are present in the JAR file when everything is compiled so in the
>> end it works out, but I need them for the unit tests too.
>> 
>> The configuration I am currently using at the moment:
>> 
>> 
>>   org.apache.felix
>>   maven-bundle-plugin
>>   3.2.0
>>   
>>   
>>   ...
>>   <_dsannotations>*
>>   <_metatypeannotations>*
>>   
>>   true
>>   
>>   
>>   
>>   
>>   scr-metadata
>>   
>>   manifest
>>   
>>   
>>   true
>>   
>>   
>>   
>> 
>> 
>>   org.apache.felix
>>   maven-scr-plugin
>>   1.24.0
>>   
>>   
>>   generate-scr-reportDescriptor
>>   
>>   scr
>>   
>>   
>>   
>> 
>> 
>> Greetings,
>> Roy
>> -
>> 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 OSGi DS and old Apache Felix SCR together

2017-03-16 Thread Roy Teeuwen

Hey all,

I am running in a problem when trying to use OSGi DS annotations and Apache 
Felix annotations together. I have unit tests that depend on the service xml's 
being present (I am using the Apache Sling osgi-mock to run unit tests), but 
the problem that I am facing is that when the maven-bundle-plugin:manifest 
phase has been executed, the maven-scr-plugin deletes the maven-bundle-plugin 
xml's again created by the maven-bundle manifest phase, is there any way to 
avoid this and make it that they are merged togheter? All xmls are present in 
the JAR file when everything is compiled so in the end it works out, but I need 
them for the unit tests too. 

The configuration I am currently using at the moment:


org.apache.felix
maven-bundle-plugin
3.2.0


...
<_dsannotations>*
<_metatypeannotations>*

true




scr-metadata

manifest


true





org.apache.felix
maven-scr-plugin
1.24.0


generate-scr-reportDescriptor

scr





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

Re: Using webconsole name hints with OSGi DS annotations

2017-01-30 Thread Roy Teeuwen

Hey Stefan,

Thanks, this seems to work! Can you explain why this one will be hidden 
automatically? Or maybe why it doesn't work when putting it in the property = { 
} block?

Greets,
Roy


> On 30 Jan 2017, at 12:26, Stefan Seifert  wrote:
> 
> it should work if you include a property like this in you config annotation:
> 
>  String webconsole_configurationFactory_nameHint() default "Root path: {" + 
> ResourceProvider.PROPERTY_ROOT + "}";
> 
> this property then should be hidden by the web console automatically so it is 
> not editable by the user.
> 
> stefan
> 
>> -Original Message-
>> From: Roy Teeuwen [mailto:r...@teeuwen.be]
>> Sent: Monday, January 30, 2017 12:11 PM
>> To: users@felix.apache.org
>> Subject: Using webconsole name hints with OSGi DS annotations
>> 
>> Hey all,
>> 
>> I am trying to use the webconsole namehints with the osgi annotations, I
>> have the following class:
>> 
>> @Component(
>>   service = SomeConfiguration.class,
>>   property = {
>>   "webconsole.configurationFactory.nameHint=Configuration
>> id: {configuration.id}"
>>   }
>> )
>> @Designate(ocd = SomeConfiguration.Config.class, factory = true)
>> public class SomeConfiguration {
>> 
>> 
>>   @ObjectClassDefinition(name = "Some configuration")
>>   @interface Config {
>> 
>>   String configuration_id();
>>   }
>> }
>> 
>> But it doesn't seem to work. If I debug in the ConfigAdminSupport and
>> look at the
>> org.apache.felix.webconsole.internal.configuration.ConfigAdminSupport#ge
>> tConfigurationFactoryNameHint, it doesn't seem to get the webconsole
>> namehint from the configuration properties. Am I using it wrong? It
>> works of course when I put the webconsole.configurationFactory.nameHint
>> inside the config class but I don't want it to be something
>> configureable for the user itself. It should be a private property.
>> 
>> I am using the webconsole version 4.2.7 by the way
>> 
>> Greets,
>> Roy
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
> 



signature.asc
Description: Message signed with OpenPGP

Using webconsole name hints with OSGi DS annotations

2017-01-30 Thread Roy Teeuwen

Hey all,

I am trying to use the webconsole namehints with the osgi annotations, I have 
the following class:

@Component(
service = SomeConfiguration.class,
property = {
"webconsole.configurationFactory.nameHint=Configuration id: 
{configuration.id}"
}
)
@Designate(ocd = SomeConfiguration.Config.class, factory = true)
public class SomeConfiguration {


@ObjectClassDefinition(name = "Some configuration")
@interface Config {

String configuration_id();
}
}

But it doesn't seem to work. If I debug in the ConfigAdminSupport and look at 
the 
org.apache.felix.webconsole.internal.configuration.ConfigAdminSupport#getConfigurationFactoryNameHint,
 it doesn't seem to get the webconsole namehint from the configuration 
properties. Am I using it wrong? It works of course when I put the 
webconsole.configurationFactory.nameHint inside the config class but I don't 
want it to be something configureable for the user itself. It should be a 
private property.

I am using the webconsole version 4.2.7 by the way

Greets,
Roy


signature.asc
Description: Message signed with OpenPGP

Re: Maven bundle plugin with OSGi DS annotations

2016-12-04 Thread Roy Teeuwen

Hey JB,

It seems that by accident I found a way to do it by looking at the slingshot 
sample project at Apache Sling, thanks though! 

org.apache.felix
maven-bundle-plugin
true



scr-metadata

manifest


true





true


Greets,
Roy

> On 4 Dec 2016, at 14:44, Roy Teeuwen  wrote:
> 
> Hey JB,
> 
> My configuration is the following:
> 
> 
> org.apache.felix
> maven-bundle-plugin
> 3.2.0
> true
> 
> 
> <_dsannotations>*
> <_metatypeannotations>*
> 
> 
> 
> Greetings,
> Roy
> 
>> On 4 Dec 2016, at 13:44, Jean-Baptiste Onofré > <mailto:j...@nanthrax.net>> wrote:
>> 
>> Hi Roy,
>> 
>> which maven-bundle-plugin version are you using ?
>> 
>> Regards
>> JB
>> 
>> On 12/04/2016 01:12 PM, Roy Teeuwen wrote:
>>> Hey all,
>>> 
>>> Since switching to OSGi DS I have been using the maven-bundle-plugin, 
>>> instead of the maven-scr-plugin, by adding the 
>>> <_dsannotations>* and 
>>> <_metatypeannotations>*.
>>> 
>>> What I noticed now is that, in contrary to the maven-scr-plugin, this does 
>>> not generate the OSGI-INF folder in the target/classes folder. Only when 
>>> looking in the JAR file it actually generates this. This has two downsides:
>>> 
>>> It is harded to see the actual scr component.xml's that are generated, 
>>> seeing as I have to open the generated JAR file.
>>> When running tests in IntelliJ, it does not find the OSGI-INF folder 
>>> anymore that are needed for some unit tests that I run, seeing as IntelliJ 
>>> uses the classes in the target folder and does not have m2e like Eclipse 
>>> has.
>>> 
>>> Is there any way to fix it that it goes back to the old situation and 
>>> actually put the OSGI-INF folder also in the target/classes folder instead 
>>> of only inside the produces end JAR ?
>>> 
>>> Thanks!
>>> Roy
>>> 
>> 
>> -- 
>> Jean-Baptiste Onofré
>> jbono...@apache.org <mailto:jbono...@apache.org>
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>> 
>

Re: Maven bundle plugin with OSGi DS annotations

2016-12-04 Thread Roy Teeuwen

Hey JB,

My configuration is the following:


org.apache.felix
maven-bundle-plugin
3.2.0
true


<_dsannotations>*
<_metatypeannotations>*



Greetings,
Roy

> On 4 Dec 2016, at 13:44, Jean-Baptiste Onofré  wrote:
> 
> Hi Roy,
> 
> which maven-bundle-plugin version are you using ?
> 
> Regards
> JB
> 
> On 12/04/2016 01:12 PM, Roy Teeuwen wrote:
>> Hey all,
>> 
>> Since switching to OSGi DS I have been using the maven-bundle-plugin, 
>> instead of the maven-scr-plugin, by adding the 
>> <_dsannotations>* and 
>> <_metatypeannotations>*.
>> 
>> What I noticed now is that, in contrary to the maven-scr-plugin, this does 
>> not generate the OSGI-INF folder in the target/classes folder. Only when 
>> looking in the JAR file it actually generates this. This has two downsides:
>> 
>> It is harded to see the actual scr component.xml's that are generated, 
>> seeing as I have to open the generated JAR file.
>> When running tests in IntelliJ, it does not find the OSGI-INF folder anymore 
>> that are needed for some unit tests that I run, seeing as IntelliJ uses the 
>> classes in the target folder and does not have m2e like Eclipse has.
>> 
>> Is there any way to fix it that it goes back to the old situation and 
>> actually put the OSGI-INF folder also in the target/classes folder instead 
>> of only inside the produces end JAR ?
>> 
>> Thanks!
>> Roy
>> 
> 
> -- 
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>

Maven bundle plugin with OSGi DS annotations

2016-12-04 Thread Roy Teeuwen

Hey all,

Since switching to OSGi DS I have been using the maven-bundle-plugin, instead 
of the maven-scr-plugin, by adding the <_dsannotations>* and 
<_metatypeannotations>*.

What I noticed now is that, in contrary to the maven-scr-plugin, this does not 
generate the OSGI-INF folder in the target/classes folder. Only when looking in 
the JAR file it actually generates this. This has two downsides:

It is harded to see the actual scr component.xml's that are generated, seeing 
as I have to open the generated JAR file.
When running tests in IntelliJ, it does not find the OSGI-INF folder anymore 
that are needed for some unit tests that I run, seeing as IntelliJ uses the 
classes in the target folder and does not have m2e like Eclipse has.

Is there any way to fix it that it goes back to the old situation and actually 
put the OSGI-INF folder also in the target/classes folder instead of only 
inside the produces end JAR ?

Thanks!
Roy

Re: SCR: Issues with static reference mixed with multiple dynamic ref

2016-11-29 Thread Roy Teeuwen

Hey all,

Thanks guys :) that explains it all and it works!
So many options and things you have to read before you know the actual final 
outcome of what you are setting.

Greets,
Roy
> On 29 Nov 2016, at 09:54, Karel Haeck  wrote:
> 
> 
> Roy,
> 
> indeed your field definition is not consistent with the reference fieldOption 
> REPLACE.
> DS will log an error that the field is not volatile, but will still activate 
> your component as it can work with zero interfaces,
> and effectively ignores your @Reference.
> 
> Basically you have to choose between
> 
> @Reference(policy=ReferencePolicy.DYNAMIC)// final implies fieldOption 
> UPDATE but defaults to STATIC
> private final List interfaces = new CopyOnWriteArrayList<>();
> 
> @Reference // volatile implies both DYNAMIC and REPLACE
> private volatile List interfaces;
> 
> Alternatively you can add the proper field option to your reference 
> annotation.
> 
> @Reference(policy = ReferencePolicy.DYNAMIC, fieldOption=FieldOption.UPDATE)
>   private List interfaces = new 
> CopyOnWriteArrayList();
> 
>  Note that the ReferenceCardinality.MULTIPLE is redundant, as it default is 
> derived from the field type
> 
>  regards,
>  Karel
> 
> 
> 
> On 29/11/2016 1:12, David Jencks wrote:
>> I didn’t investigate, so there might be a bug, but note that your field 
>> example has fieldOption REPLACE, so the CopyOnWriteArrayList  you set will 
>> never actually be used, DS will install it’s own list.  What is your 
>> evidence that the field is never set?  What happens if you make the field 
>> final, which will result in the UPDATE fieldOption?
>> 
>> thanks
>> david jencks
>> 
>>> On Nov 28, 2016, at 2:51 PM, Roy Teeuwen  wrote:
>>> 
>>> Hey,
>>> 
>>> Maybe I should start making a new thread for this hehe :). Not sure if this 
>>> is a bug or if I'm just using it incorrectly.
>>> 
>>> So created some test classes quickly.
>>> Don't know when it used to work with the immediate = true, but I guess it 
>>> might not be related then, seeing as it wont work for field even with 
>>> immediate true.
>>> I tried the following two examples. The one with the bind method does work, 
>>> the one with field reference does not.
>>> 
>>> # Field reference:
>>> 
>>> @Component(service = TestAggregator.class)
>>> public class TestAggregator {
>>> 
>>>@Reference(policy = ReferencePolicy.DYNAMIC, cardinality = 
>>> ReferenceCardinality.MULTIPLE)
>>>private List interfaces = new 
>>> CopyOnWriteArrayList();
>>> 
>>> }
>>> 
>>> generates following xml:
>>> 
>>> 
>>> http://www.osgi.org/xmlns/scr/v1.3.0"; 
>>> name="org.apache.felix.osgi.ds.TestAggregator">
>>>
>>>
>>>
>>>
>>>>> interface="org.apache.felix.osgi.ds.TestInterface" field="interfaces" 
>>> field-collection-type="service"/>
>>> 
>>> 
>>> # Method reference:
>>> 
>>> @Component(service = TestAggregator.class)
>>> public class TestAggregator {
>>> 
>>>@Reference(policy = ReferencePolicy.DYNAMIC, cardinality = 
>>> ReferenceCardinality.MULTIPLE)
>>>protected void bindTestInterface(TestInterface testInterface) {
>>>interfaces.add(testInterface);
>>>}
>>> 
>>>protected void unbindTestInterface(TestInterface testInterface) {
>>>interfaces.remove(testInterface);
>>>}
>>> }
>>> 
>>> generates following xml:
>>> 
>>> 
>>> 
>>>
>>>
>>>
>>>
>>>>>   interface="org.apache.felix.osgi.ds.TestInterface" 
>>> bind="bindTestInterface"
>>>   unbind="unbindTestInterface"/>
>>> 
>>> 
>>> The field reference one won't bind an existing TestInterface service, the 
>>> method reference will.
>>> 
>>> Greets,
>>> Roy
>>> 
>>> 
>>>> On 29 Nov 2016, at 00:28, David Jencks  wrote:
>>>> 
>>>> As everyone has said, the immediate setting isn’t going to make any 
>>>> difference to the binding.  You may be able to investigate what is going 
>>>> on by installing gogo and looking at the output of scr:info in various 
>>>> circumstanc

Re: SCR: Issues with static reference mixed with multiple dynamic ref

2016-11-28 Thread Roy Teeuwen

Hey,

 Maybe I should start making a new thread for this hehe :). Not sure if this is 
a bug or if I'm just using it incorrectly.

So created some test classes quickly. 
Don't know when it used to work with the immediate = true, but I guess it might 
not be related then, seeing as it wont work for field even with immediate true. 
I tried the following two examples. The one with the bind method does work, the 
one with field reference does not.

# Field reference:

@Component(service = TestAggregator.class)
public class TestAggregator {

@Reference(policy = ReferencePolicy.DYNAMIC, cardinality = 
ReferenceCardinality.MULTIPLE)
private List interfaces = new 
CopyOnWriteArrayList();

}

generates following xml:


http://www.osgi.org/xmlns/scr/v1.3.0"; 
name="org.apache.felix.osgi.ds.TestAggregator">







# Method reference: 

@Component(service = TestAggregator.class)
public class TestAggregator {

@Reference(policy = ReferencePolicy.DYNAMIC, cardinality = 
ReferenceCardinality.MULTIPLE)
protected void bindTestInterface(TestInterface testInterface) {
interfaces.add(testInterface);
}

protected void unbindTestInterface(TestInterface testInterface) {
interfaces.remove(testInterface);
}
}

generates following xml:










The field reference one won't bind an existing TestInterface service, the 
method reference will.

Greets,
Roy


> On 29 Nov 2016, at 00:28, David Jencks  wrote:
> 
> As everyone has said, the immediate setting isn’t going to make any 
> difference to the binding.  You may be able to investigate what is going on 
> by installing gogo and looking at the output of scr:info in various 
> circumstances and also by installing an osgi logger and setting the 
> ds.loglevel=debug framework or ds configuration property and examining the 
> resulting voluminous log output.
> 
> For the @Reference-on-field question could you show the component xml 
> generated by bnd (perhaps via the maven-bundle-plugin)?  Which version of bnd 
> is in use?  Some older versions didn’t figure out the service type very well, 
> and I’m not sure anyone has tested with the <> “diamond” notation (although I 
> can’t imagine how this could mess anything up).
> 
> thanks
> david jencks
> 
>> On Nov 28, 2016, at 12:33 PM, Roy Teeuwen  wrote:
>> 
>> Hey Karel,
>> 
>> Sorry to go further than the original question, but seeing as my question is 
>> related to exactly the same thing, maybe you can help me understand it 
>> better. 
>> Using the exact same example as the in the initial post, if I don't put 
>> immediate=true, it won't bind all of the services get created at startup or 
>> get added during the runtime. Is there a reason why it has to be immediate = 
>> true?
>> 
>> I also tried it by using the following notation, and then this it doesn't 
>> even bind any of services:
>> 
>> @Reference(cardinality = ReferenceCardinality.MULTIPLE, policy = 
>> ReferencePolicy.DYNAMIC)
>> private List stateMachines = new CopyOnWriteArrayList<>();
>> 
>> Greetings,
>> Roy
>>> On 28 Nov 2016, at 21:39, Karel Haeck  wrote:
>>> 
>>> Nicolas,
>>> 
>>> the spec does not specify that static references should be injected before 
>>> dynamic,
>>> but it does specify that references must be processed in sequence as 
>>> specified in the component xml:
>>> 
>>> "When binding services, the references are processed in the order in which 
>>> they are specified in the
>>> component description. That is, target services from the first specified 
>>> reference are bound before
>>> services from the next specified reference."
>>> 
>>> In addition the spec specifies how @Reference annotations are ordered:
>>> 
>>> " In the generated Component Description for a component, the references 
>>> must be ordered in ascending
>>> lexicographical order (using String.compareTo ) of the reference names."
>>> 
>>> Note that the default name is based on the field or method name. In your 
>>> case get aclService  for the static reference
>>> and "" (empty string) for the dynamic reference as spec states that the add 
>>> , bind or set prefix is removed.
>>> ( Actually if one uses Java naming conventions the event methods will have 
>>> names starting with an upper case character and precede the field 
>>> references).
>>> 
>>> By specifying e.g.  @Reference( name = "zStateMachine", cardinality = 
>>> ReferenceCardinality.

Re: SCR: Issues with static reference mixed with multiple dynamic ref

2016-11-28 Thread Roy Teeuwen

Hey Neil, Karel,

I want to try to make a POC in pure Apache Felix. I am used to working with 
Apache Sling, but I would like to make a pure Apache Felix example as to rule 
out anything else. 
Is there nothing like the slingstart-maven-plugin for pure Apache Felix? This 
so that I can make a self contained maven project that makes a bundle of itself 
with the maven-bundle-plugin and then also starts a felix container with some 
bundles I specify in a configuration? Or what would be the best approach for 
making a sort of "integration test" for this. The dictionaryservice.itest in 
examples seems totally out of date (the felix-maven-plugin in the pom.xml 
doesn't even exist (anymore), but was exactly what I was looking for I think)

Greets,
Roy
> On 28 Nov 2016, at 23:07, Neil Bartlett  wrote:
> 
> Roy,
> 
> Using immediate (or not) will have absolutely NO effect on the References in 
> your component… except of course that immediacy affects *when* your component 
> activates, and you can have different services visible at different times.
> 
> These are completely orthogonal aspects of the component. If you are seeing 
> an unexpected effect then please describe it in more detail. It’s either a 
> bug in SCR or in your component code.
> 
> Regards,
> Neil
> 
> 
>> On 28 Nov 2016, at 20:42, Roy Teeuwen  wrote:
>> 
>> Hey David,
>> 
>> True, I know thats what the immediate=true will do. 
>> What I don't understand is that when you don't use the immediate=true and my 
>> service does get lazily loaded when it is finally needed, that it doesn't 
>> load all it's references that are dynamic and multiple. 
>> Seeing as I have been taught to try and avoid the immediate=true when it 
>> isn't absolutely necessary, I am trying to see if there are possibilities to 
>> remove it and still get all the dynamic references.
>> 
>> Greets,
>> Roy
>>> On 28 Nov 2016, at 22:37, David Daniel  wrote:
>>> 
>>> I believe the immediate true separates the lifecycle from the resolution
>>> phase and is similar to starting a singleton.  If there is no immediate
>>> true then the lifecylce is based on when the service is a dependency and
>>> lazily loaded.  If another service depends on your service and is started
>>> then your service will be started as well but when the other service
>>> shutsdown and your service is not longer needed then your service will
>>> shutdown as well without the immediate = true.
>>> 
>>> On Mon, Nov 28, 2016 at 3:33 PM, Roy Teeuwen  wrote:
>>> 
>>>> Hey Karel,
>>>> 
>>>> Sorry to go further than the original question, but seeing as my question
>>>> is related to exactly the same thing, maybe you can help me understand it
>>>> better.
>>>> Using the exact same example as the in the initial post, if I don't put
>>>> immediate=true, it won't bind all of the services get created at startup or
>>>> get added during the runtime. Is there a reason why it has to be immediate
>>>> = true?
>>>> 
>>>> I also tried it by using the following notation, and then this it doesn't
>>>> even bind any of services:
>>>> 
>>>> @Reference(cardinality = ReferenceCardinality.MULTIPLE, policy =
>>>> ReferencePolicy.DYNAMIC)
>>>> private List stateMachines = new CopyOnWriteArrayList<>();
>>>> 
>>>> Greetings,
>>>> Roy
>>>>> On 28 Nov 2016, at 21:39, Karel Haeck  wrote:
>>>>> 
>>>>> Nicolas,
>>>>> 
>>>>> the spec does not specify that static references should be injected
>>>> before dynamic,
>>>>> but it does specify that references must be processed in sequence as
>>>> specified in the component xml:
>>>>> 
>>>>> "When binding services, the references are processed in the order in
>>>> which they are specified in the
>>>>> component description. That is, target services from the first specified
>>>> reference are bound before
>>>>> services from the next specified reference."
>>>>> 
>>>>> In addition the spec specifies how @Reference annotations are ordered:
>>>>> 
>>>>> " In the generated Component Description for a component, the references
>>>> must be ordered in ascending
>>>>> lexicographical order (using String.compareTo ) of the reference names."
>>>>> 
>>>>> Note that th

Re: SCR: Issues with static reference mixed with multiple dynamic ref

2016-11-28 Thread Roy Teeuwen

Hey David,

True, I know thats what the immediate=true will do. 
What I don't understand is that when you don't use the immediate=true and my 
service does get lazily loaded when it is finally needed, that it doesn't load 
all it's references that are dynamic and multiple. 
Seeing as I have been taught to try and avoid the immediate=true when it isn't 
absolutely necessary, I am trying to see if there are possibilities to remove 
it and still get all the dynamic references.

Greets,
Roy
> On 28 Nov 2016, at 22:37, David Daniel  wrote:
> 
> I believe the immediate true separates the lifecycle from the resolution
> phase and is similar to starting a singleton.  If there is no immediate
> true then the lifecylce is based on when the service is a dependency and
> lazily loaded.  If another service depends on your service and is started
> then your service will be started as well but when the other service
> shutsdown and your service is not longer needed then your service will
> shutdown as well without the immediate = true.
> 
> On Mon, Nov 28, 2016 at 3:33 PM, Roy Teeuwen  wrote:
> 
>> Hey Karel,
>> 
>> Sorry to go further than the original question, but seeing as my question
>> is related to exactly the same thing, maybe you can help me understand it
>> better.
>> Using the exact same example as the in the initial post, if I don't put
>> immediate=true, it won't bind all of the services get created at startup or
>> get added during the runtime. Is there a reason why it has to be immediate
>> = true?
>> 
>> I also tried it by using the following notation, and then this it doesn't
>> even bind any of services:
>> 
>> @Reference(cardinality = ReferenceCardinality.MULTIPLE, policy =
>> ReferencePolicy.DYNAMIC)
>> private List stateMachines = new CopyOnWriteArrayList<>();
>> 
>> Greetings,
>> Roy
>>> On 28 Nov 2016, at 21:39, Karel Haeck  wrote:
>>> 
>>> Nicolas,
>>> 
>>> the spec does not specify that static references should be injected
>> before dynamic,
>>> but it does specify that references must be processed in sequence as
>> specified in the component xml:
>>> 
>>> "When binding services, the references are processed in the order in
>> which they are specified in the
>>> component description. That is, target services from the first specified
>> reference are bound before
>>> services from the next specified reference."
>>> 
>>> In addition the spec specifies how @Reference annotations are ordered:
>>> 
>>> " In the generated Component Description for a component, the references
>> must be ordered in ascending
>>> lexicographical order (using String.compareTo ) of the reference names."
>>> 
>>> Note that the default name is based on the field or method name. In your
>> case get aclService  for the static reference
>>> and "" (empty string) for the dynamic reference as spec states that the
>> add , bind or set prefix is removed.
>>> ( Actually if one uses Java naming conventions the event methods will
>> have names starting with an upper case character and precede the field
>> references).
>>> 
>>> By specifying e.g.  @Reference( name = "zStateMachine", cardinality =
>> ReferenceCardinality.MULTIPLE, policy = ReferencePolicy.DYNAMIC)
>>> the static reference should be bound first.
>>> 
>>> Note that there is still a potential race condition between the add and
>> an activate method if present,
>>> or between two concurrent add() executions.
>>> 
>>> regards,
>>> Karel
>>> 
>>> On 28/11/2016 12:09, Nicolas Brasey wrote:
>>>> Hi,
>>>> 
>>>> I have a bind order issue with a component that has :
>>>> 
>>>> 1) A static reference specified with annotation @Reference on the
>> private
>>>> field
>>>> 2) A dynamic multiple reference specificed with annotation on a method
>>>> 
>>>> The static reference is not bound before the dynamic ones.
>>>> 
>>>> The code looks like this:
>>>> 
>>>> @Component(immediate = true)
>>>> public class MyServiceImpl implements MyService {
>>>> 
>>>>@Reference
>>>>private AclService aclService;
>>>> 
>>>>@Reference(
>>>>cardinality = ReferenceCardinality.MULTIPLE,
>>>>policy = ReferencePolicy.DYNAMIC
>>>>)
>&g

Re: SCR: Issues with static reference mixed with multiple dynamic ref

2016-11-28 Thread Roy Teeuwen

Hey Karel,

Sorry to go further than the original question, but seeing as my question is 
related to exactly the same thing, maybe you can help me understand it better. 
Using the exact same example as the in the initial post, if I don't put 
immediate=true, it won't bind all of the services get created at startup or get 
added during the runtime. Is there a reason why it has to be immediate = true?

I also tried it by using the following notation, and then this it doesn't even 
bind any of services:

@Reference(cardinality = ReferenceCardinality.MULTIPLE, policy = 
ReferencePolicy.DYNAMIC)
private List stateMachines = new CopyOnWriteArrayList<>();

Greetings,
Roy
> On 28 Nov 2016, at 21:39, Karel Haeck  wrote:
> 
> Nicolas,
> 
> the spec does not specify that static references should be injected before 
> dynamic,
> but it does specify that references must be processed in sequence as 
> specified in the component xml:
> 
> "When binding services, the references are processed in the order in which 
> they are specified in the
> component description. That is, target services from the first specified 
> reference are bound before
> services from the next specified reference."
> 
> In addition the spec specifies how @Reference annotations are ordered:
> 
> " In the generated Component Description for a component, the references must 
> be ordered in ascending
> lexicographical order (using String.compareTo ) of the reference names."
> 
> Note that the default name is based on the field or method name. In your case 
> get aclService  for the static reference
> and "" (empty string) for the dynamic reference as spec states that the add , 
> bind or set prefix is removed.
> ( Actually if one uses Java naming conventions the event methods will have 
> names starting with an upper case character and precede the field references).
> 
> By specifying e.g.  @Reference( name = "zStateMachine", cardinality = 
> ReferenceCardinality.MULTIPLE, policy = ReferencePolicy.DYNAMIC)
> the static reference should be bound first.
> 
> Note that there is still a potential race condition between the add and an 
> activate method if present,
> or between two concurrent add() executions.
> 
> regards,
> Karel
> 
> On 28/11/2016 12:09, Nicolas Brasey wrote:
>> Hi,
>> 
>> I have a bind order issue with a component that has :
>> 
>> 1) A static reference specified with annotation @Reference on the private
>> field
>> 2) A dynamic multiple reference specificed with annotation on a method
>> 
>> The static reference is not bound before the dynamic ones.
>> 
>> The code looks like this:
>> 
>> @Component(immediate = true)
>> public class MyServiceImpl implements MyService {
>> 
>> @Reference
>> private AclService aclService;
>> 
>> @Reference(
>> cardinality = ReferenceCardinality.MULTIPLE,
>> policy = ReferencePolicy.DYNAMIC
>> )
>> public void add(StateMachine stateMachine) {
>>
>> 
>> }
>> 
>> 
>> According to the Declarative Service specifications, the static references
>> should always be injected before the activate method.
>> 
>> 
>> Does anyone have any idea what might be wrong ?
>> 
>> 
>> My env is Apache Karaf 4.0.5 with Felix SCR 2.0.2
>> 
>> 
>> Thanks for you help!
>> 
>> Nicolas
>> 
> 
> 
> -
> 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: OSGi Declarative Services

2016-10-03 Thread Roy Teeuwen

Thanks Carsten!

Cheers,
Roy
> On 3 Oct 2016, at 12:02, Carsten Ziegeler  wrote:
> 
> Roy Teeuwen wrote
>> Hey Neil,
>> 
>> Thanks, I guess I have to use ObjectClassDefinition and AttributeDefinition 
>> annotations then :)
>> 
> Yepp,
> I've some additional tutorials/samples at:
> 
> http://blog.osoco.de/2015/11/osgi-components-simply-simple-part-iii/
> 
> 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: OSGi Declarative Services

2016-10-02 Thread Roy Teeuwen

Hey Neil,

Thanks, I guess I have to use ObjectClassDefinition and AttributeDefinition 
annotations then :)

Greets
Roy
> On 2 Oct 2016, at 23:46, Neil Bartlett  wrote:
> 
> Oh I see. For that you should use a configuration type. See the first section 
> of http://njbartlett.name/2015/08/17/osgir6-declarative-services.html 
> <http://njbartlett.name/2015/08/17/osgir6-declarative-services.html>
> 
> Regards,
> Neil
> 
> 
> 
>> On 2 Oct 2016, at 22:43, Roy Teeuwen > <mailto:r...@teeuwen.be>> wrote:
>> 
>> Hey Neil,
>> 
>> See 
>> http://felix.apache.org/documentation/subprojects/apache-felix-maven-scr-plugin/scr-annotations.html#property
>>  
>> <http://felix.apache.org/documentation/subprojects/apache-felix-maven-scr-plugin/scr-annotations.html#property><http://felix.apache.org/documentation/subprojects/apache-felix-maven-scr-plugin/scr-annotations.html#property
>>  
>> <http://felix.apache.org/documentation/subprojects/apache-felix-maven-scr-plugin/scr-annotations.html#property>>
>> Here you see you can also assign a label and a description to a property, 
>> these will then be shown when configuring a component in the felix web 
>> console. 
>> Thats what I am looking for in the new OSGi DS
>> 
>> Greets,
>> Roy
>>> On 2 Oct 2016, at 23:37, Neil Bartlett  wrote:
>>> 
>>> Hi Roy,
>>> 
>>> What are you looking for exactly? Service properties are simply key-value 
>>> pairs.
>>> 
>>> Regards,
>>> Neil
>>> 
>>> 
>>>> On 2 Oct 2016, at 22:13, Roy Teeuwen  wrote:
>>>> 
>>>> Hey all,
>>>> 
>>>> Seeing as we upgraded our instance, we want to switch from Apache Felix 
>>>> SCR Annotations to OSGi Declarative Services for new components. 
>>>> One of the things I noticed is that there is no @Property and @Properties 
>>>> in declarative services. Is there still a way to provide label and 
>>>> descriptions for properties? 
>>>> Looking at the @Component it is just key=value property types, without any 
>>>> extra metadata.
>>>> 
>>>> Greets,
>>>> Roy
>>>> -
>>>> 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>

Re: OSGi Declarative Services

2016-10-02 Thread Roy Teeuwen

Hey Neil,

See 
http://felix.apache.org/documentation/subprojects/apache-felix-maven-scr-plugin/scr-annotations.html#property
 
<http://felix.apache.org/documentation/subprojects/apache-felix-maven-scr-plugin/scr-annotations.html#property>
Here you see you can also assign a label and a description to a property, these 
will then be shown when configuring a component in the felix web console. 
Thats what I am looking for in the new OSGi DS

Greets,
Roy
> On 2 Oct 2016, at 23:37, Neil Bartlett  wrote:
> 
> Hi Roy,
> 
> What are you looking for exactly? Service properties are simply key-value 
> pairs.
> 
> Regards,
> Neil
> 
> 
>> On 2 Oct 2016, at 22:13, Roy Teeuwen  wrote:
>> 
>> Hey all,
>> 
>> Seeing as we upgraded our instance, we want to switch from Apache Felix SCR 
>> Annotations to OSGi Declarative Services for new components. 
>> One of the things I noticed is that there is no @Property and @Properties in 
>> declarative services. Is there still a way to provide label and descriptions 
>> for properties? 
>> Looking at the @Component it is just key=value property types, without any 
>> extra metadata.
>> 
>> Greets,
>> Roy
>> -
>> 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
>

OSGi Declarative Services

2016-10-02 Thread Roy Teeuwen

Hey all,

Seeing as we upgraded our instance, we want to switch from Apache Felix SCR 
Annotations to OSGi Declarative Services for new components. 
One of the things I noticed is that there is no @Property and @Properties in 
declarative services. Is there still a way to provide label and descriptions 
for properties? 
Looking at the @Component it is just key=value property types, without any 
extra metadata.

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

Websockets in Apache Felix / OSGi

Re: Optional OSGi Service

Optional OSGi Service

Fwd: Updating OSGI weaving hooks at runtime

Re: Elasticsearch rest client

Re: Elasticsearch rest client

Elasticsearch rest client

Re: Deep Dependency Issue

Creating a fatJar with only the classes / methods actually being used

Re: [ANN] New Apache Felix PMC Chair: Karl Pauls

Re: Which osgi core dependency to use in maven projects

Which osgi core dependency to use in maven projects

Re: Using OSGi DS and old Apache Felix SCR together

Re: Using OSGi DS and old Apache Felix SCR together

Using OSGi DS and old Apache Felix SCR together

Re: Using webconsole name hints with OSGi DS annotations

Using webconsole name hints with OSGi DS annotations

Re: Maven bundle plugin with OSGi DS annotations

Re: Maven bundle plugin with OSGi DS annotations

Maven bundle plugin with OSGi DS annotations

Re: SCR: Issues with static reference mixed with multiple dynamic ref

Re: SCR: Issues with static reference mixed with multiple dynamic ref

Re: SCR: Issues with static reference mixed with multiple dynamic ref

Re: SCR: Issues with static reference mixed with multiple dynamic ref

Re: SCR: Issues with static reference mixed with multiple dynamic ref

Re: OSGi Declarative Services

Re: OSGi Declarative Services

Re: OSGi Declarative Services

OSGi Declarative Services

29 matches

Site Navigation

Mail list logo

Footer information