Re: Issue running Jetty (12) inside a bundle
eloader;filter:="(osgi.serviceloader=org.eclipse.jetty.io.ssl.ALPNProcessor$Server)";resolution:=optional;cardinality:=multiple > > > osgi.serviceloader;osgi.serviceloader="org.eclipse.jetty.http.HttpFieldPreEncoder";register:="org.eclipse.jetty.http.Http1FieldPreEncoder", > osgi.serviceloader;osgi.serviceloader="org.eclipse.jetty.http.HttpFieldPreEncoder";register:="org.eclipse.jetty.http2.hpack.HpackFieldPreEncoder", > osgi.serviceloader;osgi.serviceloader="org.eclipse.jetty.io.ssl.ALPNProcessor$Server";register:="org.eclipse.jetty.alpn.java.server.JDK9ServerALPNProcessor", > osgi.serviceloader;osgi.serviceloader="org.eclipse.jetty.webapp.Configuration";register:="org.eclipse.jetty.webapp.WebXmlConfiguration", > osgi.serviceloader;osgi.serviceloader="org.eclipse.jetty.webapp.Configuration";register:="org.eclipse.jetty.webapp.WebInfConfiguration", > osgi.serviceloader;osgi.serviceloader="org.eclipse.jetty.webapp.Configuration";register:="org.eclipse.jetty.webapp.WebAppConfiguration", > osgi.serviceloader;osgi.serviceloader="org.eclipse.jetty.webapp.Configuration";register:="org.eclipse.jetty.webapp.ServletsConfiguration", > osgi.serviceloader;osgi.serviceloader="org.eclipse.jetty.webapp.Configuration";register:="org.eclipse.jetty.webapp.MetaInfConfiguration", > osgi.serviceloader;osgi.serviceloader="org.eclipse.jetty.webapp.Configuration";register:="org.eclipse.jetty.webapp.JspConfiguration", > osgi.serviceloader;osgi.serviceloader="org.eclipse.jetty.webapp.Configuration";register:="org.eclipse.jetty.webapp.JndiConfiguration", > osgi.serviceloader;osgi.serviceloader="org.eclipse.jetty.webapp.Configuration";register:="org.eclipse.jetty.webapp.JmxConfiguration", > osgi.serviceloader;osgi.serviceloader="org.eclipse.jetty.webapp.Configuration";register:="org.eclipse.jetty.webapp.JaspiConfiguration", > osgi.serviceloader;osgi.serviceloader="org.eclipse.jetty.webapp.Configuration";register:="org.eclipse.jetty.webapp.JaasConfiguration", > osgi.serviceloader;osgi.serviceloader="org.eclipse.jetty.webapp.Configuration";register:="org.eclipse.jetty.webapp.JettyWebXmlConfiguration", > osgi.serviceloader;osgi.serviceloader="org.eclipse.jetty.webapp.Configuration";register:="org.eclipse.jetty.webapp.FragmentConfiguration", > osgi.serviceloader;osgi.serviceloader="org.eclipse.jetty.webapp.Configuration";register:="org.eclipse.jetty.plus.webapp.PlusConfiguration", > osgi.serviceloader;osgi.serviceloader="org.eclipse.jetty.webapp.Configuration";register:="org.eclipse.jetty.plus.webapp.EnvConfiguration", > osgi.serviceloader;osgi.serviceloader="org.eclipse.jetty.webapp.Configuration";register:="org.eclipse.jetty.annotations.AnnotationConfiguration" > > > This requires use of Apache SPI-Fly. > > have registered on the BundleContext. The bundle does not instantiate > anything Jetty related yet (well, it did but I removed all code > that did > anything with Jetty), only the dependencies are in the POM and > they are > embedded in the bundle with > *;scope=compile|runtime which > causes the Jetty jars to appear inside the packaged bundle. > > When I remove the the ServiceEvents occur as > expected. But I need the Jetty dependencies in the bundle. > > Any ideas? > > Kind regards, > > Silvio > > > -- > > -- > VH -- -- VH This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it. -- Carsten Ziegeler Adobe cziege...@apache.org - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
CVE-2023-38435: Apache Felix Healthcheck Webconsole Plugin: XSS in healthcheck webconsole plugin
Severity: moderate
Affected versions:
- Apache Felix Healthcheck Webconsole Plugin through 2.0.2
Description:
An improper neutralization of input during web page generation ('Cross-site
Scripting') [CWE-79] vulnerability in Apache Felix Healthcheck Webconsole
Plugin version 2.0.2 and prior may allow an attacker to perform a reflected
cross-site scripting (XSS) attack.
Upgrade to Apache Felix Healthcheck Webconsole Plugin 2.1.0 or higher.
Credit:
This vulnerability was found by xray web vulnerability scanner
(github.com/chaitin/xray) (finder)
References:
https://felix.apache.org/
https://www.cve.org/CVERecord?id=CVE-2023-38435
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
Re: Roadmap for Apache Felix HTTP Jetty / Bridge compatibility with Jakarta Servlet 6.x ?
Hi, Support for Servlet 6 is imho a major task. There are at least two main problems. a) Jetty 12 which is the version supporting Servlet 6 requires Java 17. I'm not sure if we are ready to require Java 17 for all our users yet. b) Servlet 6 is not compatible to Servlet 5 as all deprecated methods have been removed. This creates a challenge when implementing support for Servlet 5 and 6 at the same time. It's doable, but requires more than just implementing the new methods in Servlet 6. We are usually not doing roadmap planning. But as Apache Felix is an open source project everyone is invited to help and to contribute to make things happen earlier. Regards Carsten On 09.03.2023 17:40, Michal Siemaszko wrote: Hi, Latest versions of both Apache Felix HTTP Jetty (`org.apache.felix.http.jetty`) Apache Felix HTTP Bridge (`org.apache.felix.http.bridge`) support Jakarta Servlet 5.x but exclude version 6.x or above, while latest version of GraphQL Java Servlet (`graphql-java-servlet`) – project we use internally in one of our open source projects – supports Jakarta Servlet starting at version 6.x. Therefore, I wanted to ask about roadmap for Apache Felix HTTP Jetty / Bridge compatibility with Jakarta Servlet 6.x ? Specifically, is such already in the works and if so, when at the earliest would such be released ? Regards, -- Carsten Ziegeler Adobe cziege...@apache.org - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Extensions to Configurator
On that note, this : https://github.com/apache/felix-dev/tree/master/cm.json/src/main/java/org/apache/felix/cm/json is actually an API that can be used to read (and write) OSGi configurations in the format specified by the Configurator. We separated this out to make it reusable for other use cases. So no need to use internal classes. It should be easy to put a small service on top that reads from anywhere else like a file system etc. Regards Carsten Am 09.08.2021 um 17:35 schrieb David Bosschaert: Hi Alexander, I think that the Felix community has always been open to extending OSGi spec-based implementations for use-cases not covered in the spec, as long as it's backward compatible. I don't really have your specific need (yet;) , but if there are others then I think it would make sense to extend the implementation. Another thing that is worth pointing out is that the TypeConverter class [1] contains a number of public methods that make it really easy to consume and produce Configurator definitions. If the extension you need deviates much from the 'base' Configurator implementation it might be easy enough to create a separate tool which uses the TypeConverter to easily work with the Configurator data. Cheers, David [1] https://github.com/apache/felix-dev/blob/master/cm.json/src/main/java/org/apache/felix/cm/json/impl/TypeConverter.java On Mon, 9 Aug 2021 at 15:49, Alexander Broekhuis wrote: Hi all, I'm looking at a way to extend the configurator to read configurations from more locations. I know the spec does not contain this, but is there some way to make this possible? The use case is that we have a dedicated server which is used to store/maintain configurations, and these configs are made available to OSGi components using the ConfigAdmin. However, components can also use the Configurator to configure itself using a local file or a config from a bundle. While those 2 solutions could work next to each other, it gets more complicated if ranking is necessary. Eg, for the configurator ranking can be used, which is handled by the configurator itself. However, since ranking is not something the ConfigAdmin does, this does not take configurations from the server into account (which would have the highest ranking in our case). I could, partially, solve this by using start levels. Eg make the component that reads from the server start after the configurator. However, if a new bundle is installed, those configurations are picked up by the configurator again, which might override the config from the server. Now I am looking for a way to extend the Configurator to be able to read configurations from other sources as well. I know I can clone the configurator and do this myself, but I'd like to know if there is any interest in such a feature. Having a clone, which will get outdated/needs merging, is not something I fancy. TiA -- Met vriendelijke groet, Alexander Broekhuis -- Carsten Ziegeler Adobe cziege...@apache.org - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: SCR duplicating service PIDs
Hi
that bug was fixed in the maven-scr-plugin:
https://issues.apache.org/jira/browse/FELIX-5304
Regards
Carsten
Am 03.12.2020 um 15:15 schrieb Pavel Horal:
Hello,
thank you for the clarification. I am actually in the process of migrating
stuff (mainly reference / service filters) away from service.pid to
component.name where applicable.
I was confused by the fact that legacy SCR plugin did exactly what I was
trying to achieve (createPid parameter) -
https://felix.apache.org/documentation/subprojects/apache-felix-maven-scr-plugin/scr-annotations.html#component
. In such environment one can always expect all services to have
service.pid set (not just those with a configuration).
Thank you for all the replies,
Pavel
On Thu, 3 Dec 2020 at 07:31, David Jencks wrote:
On Dec 2, 2020, at 7:27 PM, Raymond Auge
wrote:
On Wed, Dec 2, 2020 at 6:09 PM Pavel Horal
wrote:
---
My sample component:
@Component(
name = "hello",
property = "service.pid=hello",
This is not quite correct actually. I would have expected SCR to complain
about this because service.pid should be one of the "managed" component
properties. (i.e. never pass service.pid as a property)
Since you have set _name_ property, what you want is simply:
@Component(
name = "hello",
immediate = true)
public class HelloComponent { ... }
... without setting _configurationPid_ property, 'service.pid' is implied
from _name_.
With that, you should notice that your component responds as you expect
when a configuration with pid "hello" appears.
HTH
PS: _All components are configurable_ (even ones you never anticipated
passing configuration to) because they always infer at least their
component name as a service.pid (AFAIC this is one of the most
understated
wonders of DS.)
What if you’ve specified configuration policy IGNORE?
Otherwise, I agree it’s a wonderful feature, although I always preferred
configuration policy REQUIRE.
David Jencks
--
*Raymond Augé* (@rotty3000)
Senior Software Architect *Liferay, Inc.* (@Liferay)
OSGi Fellow
-
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
Re: SCR duplicating service PIDs
In addition to what Ray wrote, service.pid is defined as a multi value
string property. If code is inspecting this property it must deal with
that.
Regards
Carsten
Am 03.12.2020 um 04:27 schrieb Raymond Auge:
On Wed, Dec 2, 2020 at 6:09 PM Pavel Horal wrote:
---
My sample component:
@Component(
name = "hello",
property = "service.pid=hello",
This is not quite correct actually. I would have expected SCR to complain
about this because service.pid should be one of the "managed" component
properties. (i.e. never pass service.pid as a property)
Since you have set _name_ property, what you want is simply:
@Component(
name = "hello",
immediate = true)
public class HelloComponent { ... }
... without setting _configurationPid_ property, 'service.pid' is implied
from _name_.
With that, you should notice that your component responds as you expect
when a configuration with pid "hello" appears.
HTH
PS: _All components are configurable_ (even ones you never anticipated
passing configuration to) because they always infer at least their
component name as a service.pid (AFAIC this is one of the most understated
wonders of DS.)
--
--
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
Re: Web Console and javax.portlet
Thanks for the issue, it looks good to me :) Regards Carsten Am 14.09.2020 um 13:27 schrieb Per-Erik Svensson: Hi, Thanks for the help. I've never reported an issue before to Felix so I hope this suffices and that it is reported to the correct project/component: FELIX-6328. I'll try the workaround. If that works, this is absolutely good enough for me. Thanks! Best regards, Per-Erik Svensson -Original Message----- From: Carsten Ziegeler Sent: 14 September 2020 13:08 To: users@felix.apache.org Subject: Re: Web Console and javax.portlet Hi, this looks like a bug in the "all in one" bundle; it seems an update of the bnd tooling brought in a clever variant of it creating this import. Could you please file a jira issue for this? You can workaround this by using the plain webconsole bundle, together with commons-io and commons-fileupload - not nice, but should work Regards Carsten Am 14.09.2020 um 13:01 schrieb Per-Erik Svensson: Hi, I'm trying to install Web Console (All In One) in Felix but it seems to have a dependency on javax.portlet. This is the output from lb (in gogo) just to show which bundles I have installed: START LEVEL 1 ID|State |Level|Name 0|Active | 0|System Bundle (6.0.3)|6.0.3 1|Active | 1|jansi (1.17.1)|1.17.1 2|Active | 1|JLine Bundle (3.7.0)|3.7.0 3|Active | 1|Apache Felix File Install (3.6.8)|3.6.8 4|Active | 1|Apache Felix Gogo Command (1.0.2)|1.0.2 5|Active | 1|Apache Felix Gogo JLine Shell (1.1.0)|1.1.0 6|Active | 1|Apache Felix Gogo Runtime (1.1.0)|1.1.0 7|Active | 1|Apache Felix Servlet API (1.1.2)|1.1.2 8|Active | 1|Apache Felix Http Jetty (4.0.20)|4.0.20 9|Active | 1|jersey-core-client (2.31.0)|2.31.0 10|Active | 1|javax.inject:1 as OSGi bundle (2.6.1)|2.6.1 11|Active | 1|jakarta.ws.rs-api (2.1.6)|2.1.6 12|Active | 1|Jakarta XML Binding API (2.3.3)|2.3.3 13|Active | 1|jersey-core-server (2.31.0)|2.31.0 14|Starting | 1|OSGi resource locator (1.0.3)|1.0.3 15|Active | 1|Jakarta Annotations API (1.3.5)|1.3.5 16|Active | 1|Jakarta Activation API jar (1.2.2)|1.2.2 17|Starting | 1|jersey-core-common (2.31.0)|2.31.0 18|Installed | 1|Apache Felix Web Management Console (All In One) (4.5.4.all)|4.5.4.all This is the output from "start 18": org.osgi.framework.BundleException: Unable to resolve org.apache.felix.webconsole [18](R 18.0): missing requirement [org.apache.felix.webconsole [18](R 18.0)] osgi.wiring.package; (osgi.wiring.package=javax.portlet) Unresolved requirements: [[org.apache.felix.webconsole [18](R 18.0)] osgi.wiring.package; (osgi.wiring.package=javax.portlet)] Looking into where this import is coming from (with bnd command below) gives: java -jar biz.aQute.bnd-5.1.2.jar print --by org.apache.felix.webconsole-4.5.4-all.jar [USEDBY] javax.portlet org.apache.commons.fileupload.portlet ... I thought the "All In One" bundle was supposed to have everything needed to run the web console (apart from having a servlet container, such as bundle 8 above, available)? Which bundle could I add to make the Web Console bundle resolve? For context, I'm trying to find a minimal set of bundles to make EJB+JPA+JAX-RS work but before going that far I'd just like to get EJB+JPA+some "utility" bundles working (such as File Install, DS and Web Console). Karaf and Aries both seem to pull in more than I need. Best regards, *PER-ERIK SVENSSON* Software developer +46 (0)54 21 27 28 per-e...@2c8.com <mailto:per-e...@2c8.com> Logo-2c8-RGB-400 *2conciliate Business Solutions AB* Älvgatan 5, SE-652 25 Karlstad www.2c8.com <http://www.2c8.com/> -- -- 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 -- -- 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
Re: Web Console and javax.portlet
Hi, this looks like a bug in the "all in one" bundle; it seems an update of the bnd tooling brought in a clever variant of it creating this import. Could you please file a jira issue for this? You can workaround this by using the plain webconsole bundle, together with commons-io and commons-fileupload - not nice, but should work Regards Carsten Am 14.09.2020 um 13:01 schrieb Per-Erik Svensson: Hi, I’m trying to install Web Console (All In One) in Felix but it seems to have a dependency on javax.portlet. This is the output from lb (in gogo) just to show which bundles I have installed: START LEVEL 1 ID|State |Level|Name 0|Active | 0|System Bundle (6.0.3)|6.0.3 1|Active | 1|jansi (1.17.1)|1.17.1 2|Active | 1|JLine Bundle (3.7.0)|3.7.0 3|Active | 1|Apache Felix File Install (3.6.8)|3.6.8 4|Active | 1|Apache Felix Gogo Command (1.0.2)|1.0.2 5|Active | 1|Apache Felix Gogo JLine Shell (1.1.0)|1.1.0 6|Active | 1|Apache Felix Gogo Runtime (1.1.0)|1.1.0 7|Active | 1|Apache Felix Servlet API (1.1.2)|1.1.2 8|Active | 1|Apache Felix Http Jetty (4.0.20)|4.0.20 9|Active | 1|jersey-core-client (2.31.0)|2.31.0 10|Active | 1|javax.inject:1 as OSGi bundle (2.6.1)|2.6.1 11|Active | 1|jakarta.ws.rs-api (2.1.6)|2.1.6 12|Active | 1|Jakarta XML Binding API (2.3.3)|2.3.3 13|Active | 1|jersey-core-server (2.31.0)|2.31.0 14|Starting | 1|OSGi resource locator (1.0.3)|1.0.3 15|Active | 1|Jakarta Annotations API (1.3.5)|1.3.5 16|Active | 1|Jakarta Activation API jar (1.2.2)|1.2.2 17|Starting | 1|jersey-core-common (2.31.0)|2.31.0 18|Installed | 1|Apache Felix Web Management Console (All In One) (4.5.4.all)|4.5.4.all This is the output from “start 18”: org.osgi.framework.BundleException: Unable to resolve org.apache.felix.webconsole [18](R 18.0): missing requirement [org.apache.felix.webconsole [18](R 18.0)] osgi.wiring.package; (osgi.wiring.package=javax.portlet) Unresolved requirements: [[org.apache.felix.webconsole [18](R 18.0)] osgi.wiring.package; (osgi.wiring.package=javax.portlet)] Looking into where this import is coming from (with bnd command below) gives: java -jar biz.aQute.bnd-5.1.2.jar print --by org.apache.felix.webconsole-4.5.4-all.jar [USEDBY] javax.portlet org.apache.commons.fileupload.portlet ... I thought the “All In One” bundle was supposed to have everything needed to run the web console (apart from having a servlet container, such as bundle 8 above, available)? Which bundle could I add to make the Web Console bundle resolve? For context, I’m trying to find a minimal set of bundles to make EJB+JPA+JAX-RS work but before going that far I’d just like to get some “utility” bundles working (such as File Install, DS and Web Console). Karaf and Aries both seem to pull in more than I need. Best regards, *PER-ERIK SVENSSON* Software developer +46 (0)54 21 27 28 per-e...@2c8.com <mailto:per-e...@2c8.com> Logo-2c8-RGB-400 *2conciliate Business Solutions AB* Älvgatan 5, SE-652 25 Karlstad www.2c8.com <http://www.2c8.com/> -- -- 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
Re: felix-dev examples will not build
he.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81) at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128) at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305) at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192) at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105) at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957) at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289) at org.apache.maven.cli.MavenCli.main (MavenCli.java:193) 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:282) at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406) at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347) Caused by: org.apache.maven.plugin.CompilationFailureException: Compilation failure at org.apache.maven.plugin.AbstractCompilerMojo.execute (AbstractCompilerMojo.java:516) at org.apache.maven.plugin.CompilerMojo.execute (CompilerMojo.java:114) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81) at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128) at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305) at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192) at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105) at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957) at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289) at org.apache.maven.cli.MavenCli.main (MavenCli.java:193) 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:282) at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406) at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347) -- -- 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
Re: Felix OBR releases.xml referencing http://repo1.maven.org
Thanks Wayne for reporting...as you note we didnt update that OBR repository for quiet a while...which is a little bit embarrassing... I've updated releases.xml by replacing http: with https: for most of the links, so you should be able to use this as-is from now on. If there is anything else, don't hesitate to send another mail or directly create a Jira issue ticket for it. Thanks Carsten On 10.04.2020 23:26, Wayne Tackabury wrote: Hi all….first time post, so be kind… :) I have to believe this has been asked enough to be a FAQ, but couldn’t find the reference in the users, dev list that I could see nor the Felix Jira list, StackOverflow, etc. Using Felix 6.0.3, the default configuration seems to reference felix.apache.org/obr/releases.xml which, well, hasn’t been updated since 2017. The only problem with that is there are a lot of references to http://repo1.maven.org... which get picked up. And the only problem with that is maven.org went https-only since start of this year; references to the non-secure HTTP link return 501 errors at deploy/start time. If this was a code problem in the Felix bundlerepository, or even the distro config.properties, I’d create an issue in Jira and try to fix it in code or conf, but that’s not the problem as this is an online resource at felix.apache.org. I’ve worked around by pulling the .xml, changing the repo1 refs, and changing my obr.repository .url entry in config.properties to reference that as a file:// URL, but that seems like a hack. Is there an alternate releases.xml resource? Or did I totally miss the memo (as I expect :) Thanks! Wayne - 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
Re: Felix
Hi Chris, thanks for reporting, I think I fixed this now (together with some other links). Regards Carsten Chris Pilsworth wrote Hi all, I've noticed recently that some of the felix website content is not being loaded properly as it's trying to load content over HTTP into a HTTPS page. The problematic content is an ad for ApacheCon that is included on all pages - with the mixed mode problem, the content isn't shown. The error in the browser console is as follows: Mixed Content: The page at 'https://felix.apache.org/' was loaded over HTTPS, but requested an insecure resource ' http://www.apache.org/ads/button.html'. This request has been blocked; the content must be served over HTTPS. I had a quick look around to see if this was something that could be easily fixed in a felix website repo, but couldn't find the original source. Regards, Chris Pilsworth -- 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
Re: how to enable http2 in jetty
That sounds pretty interesting to me :) Regards Carsten Am 22.10.2018 um 13:36 schrieb Bram Pouwelse: As a user I really like the single bundle distribution that's currently provided. And I feel a bit foolish as I have a hard time locating my http2 experiment workspace... in that workspace I created a single bundle providing a ConnectorFactory and the additional Jetty dependencies that are required for http2. Would that be of any value? In that I'll search a bit more Regards, Bram On Mon, Oct 22, 2018 at 1:14 PM Carsten Ziegeler wrote: I think delivering a module that has no way to be used on its own, is not very useful. If you always need at least the same 8 (or whatever number) of bundles just to get a base functionality running, then why are these 8 separate bundles? Especially as you have to use the same version across these bundles? I don't buy that the current way of bundling Jetty in Felix is just for a demo-case. Thats at least to my experience not true at all. We actually had requests from users to bundle everything into a single piece. We used to have the http base as a separate bundle, but merged it in on request. I personally find it very natural that if I want to get an implementation of the http service, I get a single bundle. In fact, today these are already two, the servlet api and the jetty bundle. But at least thats all you need. Telling me that I would need 25 bundle would make me look for a different solution. While that might be the theoretical way of doing things, its definitely not the most practical or useful way. I agree that we should try to make http2 a first class citizen and preferable - at least preferable in my opinion - would be a single bundle for this. If we end up with three or four that's fine as well, if we end up with a two digit number this does look like a user friendly way to me. Carsten Am 21.10.2018 um 02:33 schrieb Eric Norman: David, I don't believe that the OSGi support in jetty is just an afterthought and those modules are used in many high profile OSGi environments, such as the eclipse IDE. In fact, Jetty is hosted by the eclipse foundation who is all about OSGi. I think a reasonable explanation of the usage of ServiceLoader in their codebase is that jetty modules are not exclusively for OSGi so they are designed to work with or without OSGi involved. If I recall correctly, the ServiceLoader code was not used extensively in the jetty code. I think usage was only in a handful of places and most had reasonable defaults if no ServiceLoader services were found which is why it hasn't been a problem until now. My experience with the jetty project is that they are reasonable people who are open to a patch to make it work without the spi-fly shim. But even if the jetty code is refactored and improved to no long require spi-fly, I still don't think a fat bundle packaging of jetty is appropriate. But that's just my opinion, and I am perfectly content using my own fork for my projects if the community isn't interested. Regards, -Eric On Sat, Oct 20, 2018 at 3:24 PM David Jencks wrote: Jetty may be modular, and each of their jars may include OSGI metadata so they are bundles, but the use of service loader (implied I think by the discussion of spi-fly; I haven’t looked at jetty myself) carries an extremely strong presumption that the jetty modularity is not very compatible with osgi modularity. I’d regard the jetty modularity as very compatible with osgi if they provided “service” wiring that could use either the OSGI registry directly or service loader directly. Relying on service loader only has a bias towards everything being in the same class loader, so it’s more likely to work correctly with a fat bundle than with spi-fly. These are rather abstract or philosophical arguments, so they may or may not match the reality of using jetty in any particular way. david jencks On Oct 20, 2018, at 1:20 PM, Eric Norman wrote: Carsten and others, Well, if the newer jetty version of the jetty artifacts causes the code to not compile then perhaps that is an issue you would want to raise with the jetty folks to not make incompatible changes to the public APIs without incrementing the major version numbers of their exports? For me, the claim that the new jetty version breaks something isn't a compelling reason do continue on as before as the same argument could be made for any third party artifact. If the third party releases a new version that doesn't work with your bundles then it seems to me that the proper remedy would be to raise the issue with the third party, declare the known issue in your own documentation and/or declare a more specific version range for the bundle/package imports in the affected consumer bundles that you have control over. Perhaps, the felix http bundle documentation could have some statement that says which versions of jett
Re: how to enable http2 in jetty
#x27;t tested by jetty proper, so who can say what side effects may be lurking? The eclipse equinox impl of the http service works in the "thin" way like I have proposed and looks to me like a better solution. Is there much collaboration between equinox and felix on the parts that seem to be common to both? Regarding your suggestions: I still don't see a good solution with your hybrid approach either since the same problems I raised in the July message thread about the activation timing remain. For example. the bundle activator where jetty is started synchronously happens before the spifly bundle extender makes the ServiceLoader stuff available so any ServiceLoader configuration embedded inside of the felix.http bundle would not be available yet when jetty is starting up. Plus I'm not sure I like the impression that http/2 support would have the appearance of being a second-class feature when wider adoption of http/2 would be better for everyone. Regards, -Eric On Sat, Oct 20, 2018 at 5:25 AM Carsten Ziegeler wrote: Let's focus for a minute on having jetty as separate bundles. This will potentially create a lot of problems as people will use the wrong jetty version. I just recently updated from on 9.4.x version to the next 9.4.(x+1) version and our code was not even compiling anymore. Therefore ultimately our code is tied to a very specific version of Jetty. From that PoV it's dangerous to not bundle jetty. My suggestion is still: - we bundle Jetty as today but add the missing service loader files. This bundle has code to support http2 if the additional stuff is installed. - for people needing http2 they install a number of more bundles and voila everything works. Unless this plan is not possible, I don't see a reason why we shouldn't go there? Carsten Am 19.10.2018 um 17:34 schrieb Raymond Auge: On Fri, Oct 19, 2018 at 11:11 AM Carsten Ziegeler < cziege...@apache.org <mailto:cziege...@apache.org>> wrote: Am 19.10.2018 um 17:06 schrieb Raymond Auge: On Fri, Oct 19, 2018 at 10:55 AM Carsten Ziegeler mailto:cziege...@apache.org>> wrote: Well, you are assuming that people are using a tool which does the resolving. Today you can simply download the Apache Felix Jetty bundle, install and enjoy. No tooling required. With such a proposal we're breaking this experience Can I get a vote as to how many people actually get this experience? I feel this only works when you already know _exactly_ what you want, which I do not feel is the norm. Not sure if I can follow here, people know that they want the Jetty module, download it, install it and have a party. We've constantly seeing people in our mailing lists saying that. I understand this. Perhaps we should simply offer an additional packaging which relies on the jetty BOM as a dependency. The benefit being we don't have to wait for Jetty to provide something special, since they already provide the BOM for exactly this purpose. I feel most people do not go to the Felix website and download jars except as part of experiments. It is my own experience that people use a build tool which relies on dependencies stored in maven central (using maven or gradle or some other build tool). In that way, and because felix.http.jetty is a implementation, they don't care about how the transitive dependencies are handled or provided; as long as the parts they need get into their deployment. - Ray While resolver based tooling is awesome, it's not the way all people work. Whether that is good or bad, does not matter. Requiring over 20 bundles to be installed to get a single functionality working seems really like overkill. Regards Carsten - Ray Carsten Am 19.10.2018 um 16:10 schrieb Raymond Auge: I know in the past I argued against exposing all the jetty bundles. But I feel I was probably wrong back then. I think that with the jetty BOM and the OSGi resolver, figuring out which bundles you need, and then adding additional ones to suite your case, is not so hard. Furthermore, Service Loader Mediator is not as painful anymore, just use an R7 framework with the SpiFly framework extension. - Ray On Fri, Oct 19, 2018 at 9:30 AM Raymond Auge mailto:raymond.a...@liferay.com>> wrote: Why not start relying on the Jetty BOM and let people depend on the bundles what they want, at least this way they can let the resolver assemble the bundles they need? - Ray On Fri, Oct 19, 2018 at 3:39 AM Carsten Ziegeler mailto:cziege...@apache.org>> wrote: The other option would be if jetty could provide us one fat bundle, to avoid having users to install N bundles, it would just be one additional. Regards Carsten Am 19.10.2018 um 09:35 schrieb Carsten Ziegeler: Hi Eric, I would like to come back to this discussion; I somehow
Re: how to enable http2 in jetty
Let's focus for a minute on having jetty as separate bundles. This will potentially create a lot of problems as people will use the wrong jetty version. I just recently updated from on 9.4.x version to the next 9.4.(x+1) version and our code was not even compiling anymore. Therefore ultimately our code is tied to a very specific version of Jetty. From that PoV it's dangerous to not bundle jetty. My suggestion is still: - we bundle Jetty as today but add the missing service loader files. This bundle has code to support http2 if the additional stuff is installed. - for people needing http2 they install a number of more bundles and voila everything works. Unless this plan is not possible, I don't see a reason why we shouldn't go there? Carsten Am 19.10.2018 um 17:34 schrieb Raymond Auge: On Fri, Oct 19, 2018 at 11:11 AM Carsten Ziegeler <mailto:cziege...@apache.org>> wrote: Am 19.10.2018 um 17:06 schrieb Raymond Auge: > On Fri, Oct 19, 2018 at 10:55 AM Carsten Ziegeler mailto:cziege...@apache.org>> > wrote: > >> Well, you are assuming that people are using a tool which does the >> resolving. Today you can simply download the Apache Felix Jetty bundle, >> install and enjoy. No tooling required. With such a proposal we're >> breaking this experience >> > > Can I get a vote as to how many people actually get this experience? > > I feel this only works when you already know _exactly_ what you want, which > I do not feel is the norm. Not sure if I can follow here, people know that they want the Jetty module, download it, install it and have a party. We've constantly seeing people in our mailing lists saying that. I understand this. Perhaps we should simply offer an additional packaging which relies on the jetty BOM as a dependency. The benefit being we don't have to wait for Jetty to provide something special, since they already provide the BOM for exactly this purpose. I feel most people do not go to the Felix website and download jars except as part of experiments. It is my own experience that people use a build tool which relies on dependencies stored in maven central (using maven or gradle or some other build tool). In that way, and because felix.http.jetty is a implementation, they don't care about how the transitive dependencies are handled or provided; as long as the parts they need get into their deployment. - Ray While resolver based tooling is awesome, it's not the way all people work. Whether that is good or bad, does not matter. Requiring over 20 bundles to be installed to get a single functionality working seems really like overkill. Regards Carsten > > - Ray > > >> >> Carsten >> >> Am 19.10.2018 um 16:10 schrieb Raymond Auge: >>> I know in the past I argued against exposing all the jetty bundles. But I >>> feel I was probably wrong back then. I think that with the jetty BOM and >>> the OSGi resolver, figuring out which bundles you need, and then adding >>> additional ones to suite your case, is not so hard. >>> >>> Furthermore, Service Loader Mediator is not as painful anymore, just use >> an >>> R7 framework with the SpiFly framework extension. >>> >>> - Ray >>> >>> On Fri, Oct 19, 2018 at 9:30 AM Raymond Auge mailto:raymond.a...@liferay.com>> >>> wrote: >>> >>>> Why not start relying on the Jetty BOM and let people depend on the >>>> bundles what they want, at least this way they can let the resolver >>>> assemble the bundles they need? >>>> >>>> - Ray >>>> >>>> On Fri, Oct 19, 2018 at 3:39 AM Carsten Ziegeler mailto:cziege...@apache.org>> >>>> wrote: >>>> >>>>> The other option would be if jetty could provide us one fat bundle, to >>>>> avoid having users to install N bundles, it would just be one >> additional. >>>>> >>>>> Regards >>>>> Carsten >>>>> >>>>> Am 19.10.2018 um 09:35 schrieb Carsten Ziegeler: >>>>>> Hi Eric, >>>>>> >>>>>> I would like to come back to this discussion; I somehow forgot to >>>>> follow >>>>>> up on the old thread. >>>>>> If we go with a thin Apache Felix
Re: how to enable http2 in jetty
Am 19.10.2018 um 17:06 schrieb Raymond Auge: On Fri, Oct 19, 2018 at 10:55 AM Carsten Ziegeler wrote: Well, you are assuming that people are using a tool which does the resolving. Today you can simply download the Apache Felix Jetty bundle, install and enjoy. No tooling required. With such a proposal we're breaking this experience Can I get a vote as to how many people actually get this experience? I feel this only works when you already know _exactly_ what you want, which I do not feel is the norm. Not sure if I can follow here, people know that they want the Jetty module, download it, install it and have a party. We've constantly seeing people in our mailing lists saying that. While resolver based tooling is awesome, it's not the way all people work. Whether that is good or bad, does not matter. Requiring over 20 bundles to be installed to get a single functionality working seems really like overkill. Regards Carsten - Ray Carsten Am 19.10.2018 um 16:10 schrieb Raymond Auge: I know in the past I argued against exposing all the jetty bundles. But I feel I was probably wrong back then. I think that with the jetty BOM and the OSGi resolver, figuring out which bundles you need, and then adding additional ones to suite your case, is not so hard. Furthermore, Service Loader Mediator is not as painful anymore, just use an R7 framework with the SpiFly framework extension. - Ray On Fri, Oct 19, 2018 at 9:30 AM Raymond Auge wrote: Why not start relying on the Jetty BOM and let people depend on the bundles what they want, at least this way they can let the resolver assemble the bundles they need? - Ray On Fri, Oct 19, 2018 at 3:39 AM Carsten Ziegeler wrote: The other option would be if jetty could provide us one fat bundle, to avoid having users to install N bundles, it would just be one additional. Regards Carsten Am 19.10.2018 um 09:35 schrieb Carsten Ziegeler: Hi Eric, I would like to come back to this discussion; I somehow forgot to follow up on the old thread. If we go with a thin Apache Felix Jetty bundle, then you need to install a lot of other bundles even if you don't use http2. So updating from a current version to this new version is not nice. How about we still include the jetty bundles inside, fix the service loader configuration by including it - but do not include the other things needed for http2 support. So if you're not using http2, it works like today. If you use http2 you install additionally spifly and what else is required to make it work. Would that work? Regards Carsten Am 18.10.2018 um 19:59 schrieb Eric Norman: Yes, with a few changes to the felix.http code it is possible to make it work. I stashed the code changes in my github fork at https://github.com/enapps-enorman/felix which I think you have already discovered? I would be willing to initiate a PR from the fork, but unfortunately the http/2 support doesn't work without changing how the felix.http bundle is packaged as discussed on the felix mailing list at: https://www.mail-archive.com/users@felix.apache.org/msg18187.html The felix community seemed reluctant to make the packaging changes to the felix.http bundle so I didn't send the PR at the time. Regards, Eric On Thu, Oct 18, 2018 at 10:04 AM Naftali wrote: Hi, is there any way to enable enable HTTP/2 support in the embedded felix jetty? Greetz Naftali -- 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 -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay) Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance) -- 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 -- 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
Re: how to enable http2 in jetty
Well, you are assuming that people are using a tool which does the resolving. Today you can simply download the Apache Felix Jetty bundle, install and enjoy. No tooling required. With such a proposal we're breaking this experience Carsten Am 19.10.2018 um 16:10 schrieb Raymond Auge: I know in the past I argued against exposing all the jetty bundles. But I feel I was probably wrong back then. I think that with the jetty BOM and the OSGi resolver, figuring out which bundles you need, and then adding additional ones to suite your case, is not so hard. Furthermore, Service Loader Mediator is not as painful anymore, just use an R7 framework with the SpiFly framework extension. - Ray On Fri, Oct 19, 2018 at 9:30 AM Raymond Auge wrote: Why not start relying on the Jetty BOM and let people depend on the bundles what they want, at least this way they can let the resolver assemble the bundles they need? - Ray On Fri, Oct 19, 2018 at 3:39 AM Carsten Ziegeler wrote: The other option would be if jetty could provide us one fat bundle, to avoid having users to install N bundles, it would just be one additional. Regards Carsten Am 19.10.2018 um 09:35 schrieb Carsten Ziegeler: Hi Eric, I would like to come back to this discussion; I somehow forgot to follow up on the old thread. If we go with a thin Apache Felix Jetty bundle, then you need to install a lot of other bundles even if you don't use http2. So updating from a current version to this new version is not nice. How about we still include the jetty bundles inside, fix the service loader configuration by including it - but do not include the other things needed for http2 support. So if you're not using http2, it works like today. If you use http2 you install additionally spifly and what else is required to make it work. Would that work? Regards Carsten Am 18.10.2018 um 19:59 schrieb Eric Norman: Yes, with a few changes to the felix.http code it is possible to make it work. I stashed the code changes in my github fork at https://github.com/enapps-enorman/felix which I think you have already discovered? I would be willing to initiate a PR from the fork, but unfortunately the http/2 support doesn't work without changing how the felix.http bundle is packaged as discussed on the felix mailing list at: https://www.mail-archive.com/users@felix.apache.org/msg18187.html The felix community seemed reluctant to make the packaging changes to the felix.http bundle so I didn't send the PR at the time. Regards, Eric On Thu, Oct 18, 2018 at 10:04 AM Naftali wrote: Hi, is there any way to enable enable HTTP/2 support in the embedded felix jetty? Greetz Naftali -- 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 -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay) Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance) -- 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
Re: how to enable http2 in jetty
The other option would be if jetty could provide us one fat bundle, to avoid having users to install N bundles, it would just be one additional. Regards Carsten Am 19.10.2018 um 09:35 schrieb Carsten Ziegeler: Hi Eric, I would like to come back to this discussion; I somehow forgot to follow up on the old thread. If we go with a thin Apache Felix Jetty bundle, then you need to install a lot of other bundles even if you don't use http2. So updating from a current version to this new version is not nice. How about we still include the jetty bundles inside, fix the service loader configuration by including it - but do not include the other things needed for http2 support. So if you're not using http2, it works like today. If you use http2 you install additionally spifly and what else is required to make it work. Would that work? Regards Carsten Am 18.10.2018 um 19:59 schrieb Eric Norman: Yes, with a few changes to the felix.http code it is possible to make it work. I stashed the code changes in my github fork at https://github.com/enapps-enorman/felix which I think you have already discovered? I would be willing to initiate a PR from the fork, but unfortunately the http/2 support doesn't work without changing how the felix.http bundle is packaged as discussed on the felix mailing list at: https://www.mail-archive.com/users@felix.apache.org/msg18187.html The felix community seemed reluctant to make the packaging changes to the felix.http bundle so I didn't send the PR at the time. Regards, Eric On Thu, Oct 18, 2018 at 10:04 AM Naftali wrote: Hi, is there any way to enable enable HTTP/2 support in the embedded felix jetty? Greetz Naftali -- 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
Re: how to enable http2 in jetty
Hi Eric, I would like to come back to this discussion; I somehow forgot to follow up on the old thread. If we go with a thin Apache Felix Jetty bundle, then you need to install a lot of other bundles even if you don't use http2. So updating from a current version to this new version is not nice. How about we still include the jetty bundles inside, fix the service loader configuration by including it - but do not include the other things needed for http2 support. So if you're not using http2, it works like today. If you use http2 you install additionally spifly and what else is required to make it work. Would that work? Regards Carsten Am 18.10.2018 um 19:59 schrieb Eric Norman: Yes, with a few changes to the felix.http code it is possible to make it work. I stashed the code changes in my github fork at https://github.com/enapps-enorman/felix which I think you have already discovered? I would be willing to initiate a PR from the fork, but unfortunately the http/2 support doesn't work without changing how the felix.http bundle is packaged as discussed on the felix mailing list at: https://www.mail-archive.com/users@felix.apache.org/msg18187.html The felix community seemed reluctant to make the packaging changes to the felix.http bundle so I didn't send the PR at the time. Regards, Eric On Thu, Oct 18, 2018 at 10:04 AM Naftali wrote: Hi, is there any way to enable enable HTTP/2 support in the embedded felix jetty? Greetz Naftali -- 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
Re: Configurator R7 example
I thought this for two years as well...so don't worry :) But it's actually not needed. The R6 and R7 releases have some great new features for DS and CM. The OSGi blog at https://blog.osgi.org has some posts about new things in R7 Regards Carsten Cristiano Gavião wrote > Humm, interesting... thanks Carsten for correct me... > > > Certainly I will need to upgrade my knowledge on DS and CM again :-D > > I really thought that in order to use a Factory PID such as > "my.fpid~somepid" I would need a factory component. > > > On 06/08/2018 12:20, Carsten Ziegeler wrote: >> I think the current @Component annotation is correct :) (sorry) >> >> If you use factory="..." you will create a component factory as defined >> in the DS specification - that's in contrast to a component managed by >> factory configurations (which this example is about). >> >> If you managed to get the Map of properties (which should work with the >> Map.Entry change I posted recently), then the full PID of the >> configuration is stored in a property named "service.pid" - you can then >> search for the tilde in there and get what you want. >> >> Regards >> >> Carsten >> >> >> Cristiano Gavião wrote >>> >>> On 06/08/2018 11:10, Philipp Höfler wrote: >>>> Sorry, pid is probably the wrong word for that. Alias might be more >>>> correct. >>>> I am talking about the name after the ~ in the configuration file >>>> (my.config~system1). >>>> In this case I would like to get "system1". >>> Ah, now I understood. >>> >>> I think you won't get that since your component is not a factory. If >>> I'm remember right, you need to use a FPID (factory pid), so your >>> component must be declared this way:*@Component(factory="anFactoryPID")* >>> >>> Couple years ago, I used to use the ConfigAdmin directly to activate my >>> mult-instance components and the information you want was only provided >>> by the Configuration object returned from CM: >>> >>>> configuration = getConfigurationAdmin() >>>> .createFactoryConfiguration(pFactoryPid, null); >>>> factoryPID = configuration.getFactoryPid(); >>>> pid = configuration.getPid() >>> I just started with Configurator too, but I don't know if this FPID and >>> PID information are being published in the configuration map currently >>> also. CM used not do that until R6 (at least I was not able to find >>> them). >>> >>> > > > - > 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
Re: Configurator R7 example
I think the current @Component annotation is correct :) (sorry) If you use factory="..." you will create a component factory as defined in the DS specification - that's in contrast to a component managed by factory configurations (which this example is about). If you managed to get the Map of properties (which should work with the Map.Entry change I posted recently), then the full PID of the configuration is stored in a property named "service.pid" - you can then search for the tilde in there and get what you want. Regards Carsten Cristiano Gavião wrote > > > On 06/08/2018 11:10, Philipp Höfler wrote: >> Sorry, pid is probably the wrong word for that. Alias might be more >> correct. >> I am talking about the name after the ~ in the configuration file >> (my.config~system1). >> In this case I would like to get "system1". > > Ah, now I understood. > > I think you won't get that since your component is not a factory. If > I'm remember right, you need to use a FPID (factory pid), so your > component must be declared this way:*@Component(factory="anFactoryPID")* > > Couple years ago, I used to use the ConfigAdmin directly to activate my > mult-instance components and the information you want was only provided > by the Configuration object returned from CM: > >> configuration = getConfigurationAdmin() >> .createFactoryConfiguration(pFactoryPid, null); >> factoryPID = configuration.getFactoryPid(); >> pid = configuration.getPid() > > I just started with Configurator too, but I don't know if this FPID and > PID information are being published in the configuration map currently > also. CM used not do that until R6 (at least I was not able to find them). > > -- 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
Re: Configurator R7 example
Hi,
for the reference you need to use:
private List, ISecurityChecker>>
_securityCheckers;
this should give you a list of tuples, where the key is the map of
properties and the value the service object. For this I think you need
to specify "field-collection-type" being "tuple" on @Reference.
Regards
Carsten
Philipp Höfler wrote
> I made some progress, based on your information.
> I set the configurationPolicy to REQUIRE, but this alone does not work.
> @RequireConfigurator
> @Component(service = ISecurityChecker.class,
> configurationPid = "my.config",
> configurationPolicy = ConfigurationPolicy.REQUIRE)
> public class SecurityChecker implements ISecurityChecker
>
> Then, I additionally set the policyOption of the reference to GREEDY.
> @Reference(policyOption = ReferencePolicyOption.GREEDY)
> private List _securityCheckers;
>
> Now, I am getting a List of all configurations - at least a step in the right
> direction.
> But I am still not getting the pid of the configuration - in my case
> "system1" and "system2".
> According to Ray, the type would be Map,
> ISecurityChecker>,
> @Reference(policyOption = ReferencePolicyOption.GREEDY)
> private Map, ISecurityChecker> _securityCheckers;
>
> but when doing this I am getting the following error during compilation:
> [ERROR] Failed to execute goal
> biz.aQute.bnd:bnd-export-maven-plugin:4.1.0-SNAPSHOT:export (default) on
> project my-app: Unable to resolve <>: missing requirement
> osgi.identity;filter:='(osgi.identity=com.my.app.rest-service)' [caused by:
> Unable to resolve com.my.app.rest-service version=1.0.0.201808061255: missing
> requirement
> osgi.service;filter:='(objectClass=java.util.Map)';effective:='active'] ->
> [Help 1]
>
> I tried the following types, too, but the same error:
> @Reference(policyOption = ReferencePolicyOption.GREEDY)
> private Map _securityCheckers;
>
> It seems, that the key of the Map is always the problem. But I do not
> understand why.
> [ERROR] Failed to execute goal
> biz.aQute.bnd:bnd-export-maven-plugin:4.1.0-SNAPSHOT:export (default) on
> project my-app: Unable to resolve <>: missing requirement
> osgi.identity;filter:='(osgi.identity=com.my.app.rest-service)' [caused by:
> Unable to resolve com.my.app.rest-service version=1.0.0.201808061258: missing
> requirement
> osgi.service;filter:='(objectClass=java.lang.String)';effective:='active'] ->
> [Help 1]
>
> Any ideas, how I can get the pid of the configuration?
>
> Best,
> Philipp
>
> -Ursprüngliche Nachricht-
> Von: Philipp Höfler
> Gesendet: Montag, 6. August 2018 13:34
> An: users@felix.apache.org
> Betreff: AW: Configurator R7 example
>
> Thanks for your quick reply.
>
> Unfortunately, when setting the policy to required, the whole component won't
> be loaded.
> At least, when attaching a debugger, the activate method is never called and
> the reference is always null.
>
> It feels like there is still something fundamental wrong in my code. But I
> don't see what it is ...
>
> Philipp
>
> -Ursprüngliche Nachricht-
> Von: Carsten Ziegeler
> Gesendet: Montag, 6. August 2018 13:08
> An: users@felix.apache.org; Philipp Höfler
> Betreff: Re: Configurator R7 example
>
> Atm I'm only guessing, but as you are specifying the configuration to be
> optional, this might bypass the actual configurations stored in configuration
> admin.
>
> I would try replacing this with the require policy. At least I have seen some
> working code which pretty much looks as your example, except for the policy
> being specified as required
>
> Carsten
>
>
> Philipp Höfler wrote
>> This is driving me nuts.
>> Could someone please help me out?
>>
>> I do not understand how to create multiple instances of a component by the
>> configurator factory and how to reference all these instances.
>> I played around, and it seems, that the configuration is loaded successfully.
>> This is my configuration json file (OSGI-INF/configurator/text.json) {
>> // Resource Format Version
>> ":configurator:resource-version" : 1,
>>
>> // First Configuration
>> "my.config~system1":
>> {
>> "test.securityEnabled": false,
>> "test.name": "System1"
>> },
>> // Second Configuration
>> "my.config~system2":
>> {
>> "test.securityEnabled": true,
>> "test.name":
Re: Configurator R7 example
":configurator:resource-version" : 1,
>>>>>>>
>>>>>>>// First Configuration
>>>>>>> "my.config~system1":
>>>>>>> {
>>>>>>>"test.securityEnabled": false,
>>>>>>>"test.test": false
>>>>>>>},
>>>>>>>// Second Configuration
>>>>>>> "my.config~system2":
>>>>>>> {
>>>>>>>"test.securityEnabled": true,
>>>>>>>"test.test": false
>>>>>>>}
>>>>>>>}
>>>>>>> }
>>>>>>>
>>>>>>
>>>>>> Then you will have 2 component activations; one for each
>>>>>> system1, system2, each with a MyConfig instance backing a
>>>>>> different factory configuration instance.
>>>>>>
>>>>>> HTH
>>>>>> - Ray
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Is it possible to have such a config with n systems?
>>>>>>> Meaning, I do not know the amount of systems at compile time.
>>>>>>>
>>>>>>> Further, how would the @interface MyConfig annotation look like?
>>>>>>> Is it possible to expect an array of MyConfig for the
>>>>>>> modified(MyConfig[]
>>>>>>> configs) method?
>>>>>>>
>>>>>>> Thanks for your help,
>>>>>>> Philipp
>>>>>>>
>>>>>>> -Ursprüngliche Nachricht-
>>>>>>> Von: Raymond Auge
>>>>>>> Gesendet: Donnerstag, 12. Juli 2018 16:43
>>>>>>> An: felix users
>>>>>>> Betreff: Re: Configurator R7 example
>>>>>>>
>>>>>>> Did you add the requirement to your configuration bundle?
>>>>>>>
>>>>>>> Require-Capability: osgi.extender; \
>>>>>>> filter:="(&(osgi.extender=osgi.configurator) \
>>>>>>> (version>=1.0
>>>>>>> <https://osgi.org/specification/osgi.cmpn/7.0.0/
>>>>>>> service.configurator.html#org.osgi.service.configurator>)(!(
>>>>>>> version>=2.0)))"
>>>>>>>
>>>>>>> That or on some bit of code in the configuration bundle add the
>>>>>> annotation:
>>>>>>>
>>>>>>> @org.osgi.service.configurator.annotations.RequireConfigurator
>>>>>>>
>>>>>>> - Ray
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Jul 12, 2018 at 10:23 AM, Philipp Höfler <
>>>>>>> philipp.hoef...@pernexas.com> wrote:
>>>>>>>
>>>>>>>> Hallo David,
>>>>>>>>
>>>>>>>> thanks for the explanation.
>>>>>>>> So, the configurator is just a "wrapper" for the
>>>>>>>> ConfigAdminService to read json and transfer it into a key
>>>>>>>> value
>>>>> format, right?
>>>>>>>>
>>>>>>>> I still have problems to use the I put a test.json file in the
>>>>>>>> OSGI-INF/configurator folder of a bundle with the following
>>>>>>>> content:
>>>>>>>> {
>>>>>>>> // Resource Format Version
>>>>>>>> ":configurator:resource-version" : 1,
>>>>>>>>
>>>>>>>> // First Configuration
>>>>>>>> "my.config":
>>>>>>>> {
>>>>>>>>"test.securityEnabled": false,
>>>>>>>>"test.test": false
>>>>>>>> }
>>>>>>>> }
>>>>>>>>
>>>>>>>> In addition, I have an annotation for holding the values:
>>>>>>>> public @interface MyConfig
>>>>>>>> {
>>>>>>>>boolean test_securityEnabled () default true;
>>>>>>>>boolean test_test() default true; }
>>>>>>>>
>>>>>>>> Besides that, I've a custom GoGo command for configuration.
>>>>>>>> But I am not sure, if this is really needed for loading the json?
>>>>>>>>
>>>>>>>> Unfortunately, the json is obviously not loaded.
>>>>>>>> Both values are set to true, according to the default value.
>>>>>>>>
>>>>>>>> Do I have to do something in addition to load the json file?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Philipp
>>>>>>>>
>>>>>>>> -Ursprüngliche Nachricht-
>>>>>>>> Von: David Bosschaert
>>>>>>>> Gesendet: Donnerstag, 12. Juli 2018 11:15
>>>>>>>> An: users@felix.apache.org
>>>>>>>> Betreff: Re: Configurator R7 example
>>>>>>>>
>>>>>>>> Hi Philipp,
>>>>>>>>
>>>>>>>> In the end the configuration specified with the Configurator
>>>>>>>> will end up in OSGi Configuration Admin, so the Configurator
>>>>>>>> is limited to the same types as ConfigAdmin. The Configurator
>>>>>>>> allows complex JSON values to be specified, they will end up
>>>>>>>> as JSON text in Configuration Admin if they go beyond what
>>>>>>>> ConfigAdmin supports
>>>>>> natively.
>>>>>>>>
>>>>>>>> So to use the Configurator you need the Configurator bundle
>>>>>>>> plus the ConfigAdmin bundle.
>>>>>>>>
>>>>>>>> The Configurator handles configuration resources in
>>>>>>>> OSGI-INF/configurator inside bundles but can also be provided
>>>>>>>> with external configuration via the configurator.initial
>>>>>>>> framework/system property. This is described in sections 150.4
>>>>>>>> and
>>>>>>>> 150.5 in [1]. To provide Configurator configuration into the
>>>>>>>> system you don't need to write any classes, but depending on
>>>>>>>> how you use the configuration you may have to add classes that
>>>>>>>> consume it. But again, the consumption can be done by anything
>>>>>>>> that understands ConfigAdmin configs, so there
>>>>>>> are a lot of options for this.
>>>>>>>>
>>>>>>>> I'm not aware of a complete tutorial on this topic yet. I
>>>>>>>> agree it would be nice to have that.
>>>>>>>>
>>>>>>>> Hope this helps,
>>>>>>>>
>>>>>>>> David
>>>>>>>>
>>>>>>>> [1] https://osgi.org/specification/osgi.cmpn/7.0.0/
>>>>>>>> service.configurator.html
>>>>>>>>
>>>>>>>> On Thu, 12 Jul 2018 at 10:55, Philipp Höfler
>>>>>>>> >>>>>>>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I am searching for a possibility to load complex configurations.
>>>>>>>>> I tried the ConfigurationAdminService, but key value pairs
>>>>>>>>> are not sufficient as I need complex types.
>>>>>>>>>
>>>>>>>>> Raymond pointed out that I should have a look at the
>>>>>>>>> Configurator Specification.
>>>>>>>>> https://osgi.org/specification/osgi.cmpn/7.0.0/
>>>>> service.configurator.
>>>>>>>>> ht
>>>>>>>>> ml
>>>>>>>>>
>>>>>>>>> I read the specification and it sounds promising.
>>>>>>>>> But I am stuck how to use the Configuration in my project.
>>>>>>>>> I understand that I've to add the following dependency.
>>>>>>>>> org.apache.felix.configurator
>>>>>>>>>
>>>>>>>>> But I don't understand if I've to add some classes, where the
>>>>>>>>> json file has to be placed and if it's possible to place it
>>>>>>>>> outside of the
>>>>>>>> bundle?
>>>>>>>>>
>>>>>>>>> Is there any tutorial or sample project out there?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Philipp
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> --
>>>>>>>> --
>>>>>>>> --
>>>>>>>> - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>>>>>>>> For additional commands, e-mail: users-h...@felix.apache.org
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> *Raymond Augé*
>>>>>>> <http://www.liferay.com/web/raymond.auge/profile>
>>>>>>> (@rotty3000)
>>>>>>> Senior Software Architect *Liferay, Inc.*
>>>>>>> <http://www.liferay.com>
>>>>>>> (@Liferay)
>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
>>>>>>> (@OSGiAlliance)
>>>>>>>
>>>>>>> ---
>>>>>>> --
>>>>>>> ---
>>>>>>> - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>>>>>>> For additional commands, e-mail: users-h...@felix.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>>>>> (@rotty3000)
>>>>>> Senior Software Architect *Liferay, Inc.*
>>>>>> <http://www.liferay.com>
>>>>>> (@Liferay)
>>>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
>>>>>> (@OSGiAlliance)
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>>>> (@rotty3000)
>>>>> Senior Software Architect *Liferay, Inc.*
>>>>> <http://www.liferay.com>
>>>>> (@Liferay)
>>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
>>>>> (@OSGiAlliance)
>>>>>
>>>>> -
>>>>> --
>>>>> -- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>>>>> For additional commands, e-mail: users-h...@felix.apache.org
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>>> (@rotty3000)
>>>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
>>>> (@Liferay)
>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
>>> (@OSGiAlliance)
>>>
>>>
>>> - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>>> For additional commands, e-mail: users-h...@felix.apache.org
>>>
>>>
>>
>>
>> --
>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>> (@rotty3000)
>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
>> (@Liferay)
>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
>> (@OSGiAlliance)
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>>
>
>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> (@rotty3000)
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
>
> -
> 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
Re: Felix Log Service version 1.2.0 cannot be referenced
I just started the release process for SCR 2.1.2 which contains the fix. If everything goes well, it will be available on Monday Regards Carsten Philipp Höfler wrote > Hallo Ray, > > thanks for pointing this out. 😊 > > Best, > Philipp > > -Ursprüngliche Nachricht- > Von: Raymond Auge > Gesendet: Mittwoch, 1. August 2018 22:51 > An: felix users > Betreff: Re: Felix Log Service version 1.2.0 cannot be referenced > > There's a bug in Felix SCR which solves this but it is not yet released. > > I won't be able to do it at least 'till next week. > > Sincerely, > - Ray > > On Wed, Aug 1, 2018, 04:59 Philipp Höfler, > wrote: > >> Hi, >> >> I am trying to utilize the new Felix Log Service (1.2.0) with DS. >> But no matter what I am trying, the reference is always null. >> >> I added a field with the annotation in my class. >> >> @Reference(service = org.osgi.service.log.LoggerFactory.class) >> private org.osgi.service.log.Logger _logger; >> >> In addition, I've added the following two bundles to the -runbundles >> property of my bndrun file: >> >> org.apache.felix.log;version='[1.2.0,1.2.1)',\ >> org.apache.felix.log.extension;version='[1.0.0,1.0.1)',\ >> >> I am not sure, if this is really necessary. >> Even if no logger implementation (logback, log4j) is available, I >> would have expected that the reference could be resolved? >> >> But also, when I add logback to the -runbundles, the logger cannot be >> resolved and is always null >> >> ch.qos.logback.classic;version='[1.2.3,1.2.4)',\ >> ch.qos.logback.core;version='[1.2.3,1.2.4)',\ >> >> You can inspect the whole project on GitHub: >> >> https://github.com/phhoef/osgi-test/blob/master/rest-service/src/main/ >> java/com/my/app/rest/rest/ServerInfoControllerImpl.java >> >> Thanks >> > > - > 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
Re: Felix Http Jetty packaging as uber bundle?
es.conscrypt-openjdk/1.0.1_1 > #org.eclipse.jetty/jetty-alpn-conscrypt-server/9.4.11.v20180605 > > > FYI: I've stashed the changes to the felix.http.jetty code at [1] if you > wish to review. > >1. > > https://github.com/enapps-enorman/felix/commit/76adf9d3a445cb620d2baa9fd1155f5e25aa3ca5 > > > Please let me know if you have any thoughts on this. > > Regards, > Eric Norman > -- 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
Re: ServletContainerInitializer
Hi, there is no support for ServletContainerInitializer in the OSGi whiteboard specification and therefore no support in the Apache Felix implementation. Major reason of this is the dynamic nature of OSGi, bundles can come and go and when a bundle arrives the servlet context might already be initialized. Now, the equivalent of this is actually the whiteboard which allows to dynamically register web resources. Regards Carsten Thomas Driessen wrote > Hi, > > I'm following the current development of OSGi support in Vaadin 10/11 > and found this issue: > > https://github.com/vaadin/flow/issues/4376 > > Vaadin seems to make use of a ServletContainerInitializer for its Routes > and it seems not to work with jetty and felix. > > Is there support for ServletContainerInitializers in felix.http.jetty or > the whiteboard? Or is this something that is not supported? > > Kind regards, > Thomas -- 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
Re: Enabling Jetty JMX MBeans in Felix Http Service
Hi I've never used this feature but looking at the source code, it seems that a javax.management.MBeanServer service needs to be registered in the OSGi service registry for this. The Apache Aries project has an implementation of the OSGi JMX Management Model Specification at http://aries.apache.org/modules/jmx.html. That page also has a code snippet on how to register such an MBeanserver. Regards Carsten Silvano Maffeis wrote > Dear all > > I'm setting *org.apache.felix.http.mbeans=true* but can't see any Jetty > MBeans exposed through the JDK platform MBeans server. I'm connecting with > VisualVM. > > Any hint or example is appreciated because it appears that > org.apache.felix.http.mbeans does not have the effect that I'm expecting. > > Regards, > Silvano > -- 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
Re: Webconsole security
Hi, username/password can also be set using framework properties, with that it is possible to secure the webconsole without the configuration of a provider being available. The framework property approach is maybe not the nicest way either. Often the web console is regarded as the last resort when things go wrong, therefore tying it to configuration admin or a provider would prevent access to the web console. I think Antonio suggested something similar (requiring the provider but having a way to get to the web console if the provider is not available) a while ago. @Antonio do you remember the approach? Regards Carsten Thomas Baier wrote > Hi, > > > we recently ran into an issue that the webconsole in an application was > accessible with the default user credentials because the configuration was > not picked up for some reason. Therefore the following question: > > > Security for the web console is either setup by adding a configuration or by > using a WebConsoleSecurityProvider, if I understand it correctly both > mechanisms are optional and loaded dynamically. Doesn't that mean that if > those configs/services are temporarily not (yet) available, which can happen > even during normal operation, e.g. during application startup, access to the > webconsole is not secured anymore? If yes, wouldn't it be more appropriate to > make the configuration mandatory instead of optional? > > > Best regards, > > Thomas > -- 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
Re: Is EventAdmin-1.4.6 really loosing events?
Hi,
actually I think this is more or less ok. The events are posted from the
same thread and event admin requires them to be delivered in the order
they are posted. So if one listener is blocking, then delivery of all
other events initiated from the same thread are blocked.
Regards
Carsten
Carsten Ziegeler wrote
> Hi Erwin,
>
> ah sorry, right :) I was reading modulo 10 instead of equals 10...
>
> Yes, you're absolutely right in this case, that should not happen.
>
> This looks like a problem in postEvent somewhere
>
> Carsten
>
>
> Erwin Hogeweg wrote
>> Hi Carsten,
>>
>> Sorry, I think didn’t make myself clear.
>>
>> I am only replacing ONE listener with a BlockingListener, and then I am
>> blocking ONE event delivery. So I do expect to loose ONE event, not 70k…
>>
>> Or am I missing something?
>>
>> Erwin
>>
>>
>> @Test
>> public void testEventing() throws Exception {
>> // this.addListener(PREFIX + "/0", null);
>> this.addBlockingListener(PREFIX + "/0", null);
>> this.addListener(PREFIX + "/1", null);
>> this.addListener(PREFIX + "/2", null);
>> ...
>>
>>
>>
>> On Nov 29, 2017, at 09:21, Carsten Ziegeler
>> mailto:cziege...@apache.org>> wrote:
>>
>> Thanks
>>
>> I'm not sure if event admin could/should do anything in this case. Each
>> blocking listener takes away one thread from the thread pool. As soon as
>> you have as many blocking listeners as the pool has threads, event admin
>> will not deliver any event anymore
>>
>> Regards
>>
>> Carsten
>>
>>
>> Erwin Hogeweg wrote
>> Hi Carsten,
>>
>> After analyzing a bunch of log files we found some evidence that suggested
>> that an EventAdminThread might be blocked.
>>
>> I was able to duplicate it with a JUnit test. I created a BlockingListener
>> with extends Listener and override the handleEvent() method. As you can see
>> below we are loosing almost 7 events because of this one block.
>>
>> I know, eventHandlers are not supposed to block, so we definitely have a
>> design issue here, but I figured I share the results with you because I am
>> not sure this is what’s expected.
>>
>>
>> Kind Regards,
>>
>> Erwin
>>
>>
>> @Override
>> public void handleEvent(final Event event) {
>> this.test.handleEvent(event, this.payload);
>> count++;
>> if (count == 10) {
>> logger.info<http://logger.info>("{} is blocking forever",
>> Thread.currentThread().getName());
>> while (true) {
>> try {
>> Thread.sleep(6);
>> } catch (InterruptedException e) {
>> //
>> }
>> }
>> }
>>
>> }
>>
>>
>> [org.apache.felix.eventadmin.ittests.StressTestIT] : Starting eventing test
>> StressTestIT
>> [org.apache.felix.eventadmin.ittests.StressTestIT] : Preparing test with 15
>> threads and 1 events per thread.
>> [org.apache.felix.eventadmin.ittests.StressTestIT] : Expecting 105
>> events.
>> [org.apache.felix.eventadmin.ittests.StressTestIT] : Started test with 15
>> threads and 1 events.
>> [org.apache.felix.eventadmin.ittests.StressTestIT] : Received 0 events so
>> far.
>> [org.apache.felix.eventadmin.ittests.StressTestIT] : Received 0 events so
>> far.
>> [org.apache.felix.eventadmin.ittests.StressTestIT] :
>> [org.apache.felix.eventadmin.ittests.StressTestIT] : Started thread
>> [org.apache.felix.eventadmin.ittests.StressTestIT] : Started thread
>> Started thread
>> [org.apache.felix.eventadmin.ittests.StressTestIT] :
>> [org.apache.felix.eventadmin.ittests.StressTestIT] :
>> [org.apache.felix.eventadmin.ittests.StressTestIT] : Started thread
>> [org.apache.felix.eventadmin.ittests.StressTestIT] : Started thread
>> [org.apache.felix.eventadmin.ittests.StressTestIT] : Started thread
>> [org.apache.felix.eventadmin.ittests.StressTestIT] : Started thread
>> [org.apache.felix.eventadmin.ittests.StressTestIT] : Started thread
>> [org.apache.felix.eventadmin.ittests.StressTestITStarted thread
>> Started thread
>> ] : Started thread
>> [org.apache.felix.eventadmin.ittests.StressTestIT] : Started thread
>> [org.apache.felix.eventadmin.ittests.StressTestIT] : Started thread
>> [org.apache.felix.eventadmin.ittests.StressTestIT] : Started thread
>> [org.apache.felix.eventadmin.ittests.StressTestIT] : Started thread
>> [org.apache.felix.eventadmin.ittests
Re: Is EventAdmin-1.4.6 really loosing events?
Hi Erwin,
ah sorry, right :) I was reading modulo 10 instead of equals 10...
Yes, you're absolutely right in this case, that should not happen.
This looks like a problem in postEvent somewhere
Carsten
Erwin Hogeweg wrote
> Hi Carsten,
>
> Sorry, I think didn’t make myself clear.
>
> I am only replacing ONE listener with a BlockingListener, and then I am
> blocking ONE event delivery. So I do expect to loose ONE event, not 70k…
>
> Or am I missing something?
>
> Erwin
>
>
> @Test
> public void testEventing() throws Exception {
> // this.addListener(PREFIX + "/0", null);
> this.addBlockingListener(PREFIX + "/0", null);
> this.addListener(PREFIX + "/1", null);
> this.addListener(PREFIX + "/2", null);
> ...
>
>
>
> On Nov 29, 2017, at 09:21, Carsten Ziegeler
> mailto:cziege...@apache.org>> wrote:
>
> Thanks
>
> I'm not sure if event admin could/should do anything in this case. Each
> blocking listener takes away one thread from the thread pool. As soon as
> you have as many blocking listeners as the pool has threads, event admin
> will not deliver any event anymore
>
> Regards
>
> Carsten
>
>
> Erwin Hogeweg wrote
> Hi Carsten,
>
> After analyzing a bunch of log files we found some evidence that suggested
> that an EventAdminThread might be blocked.
>
> I was able to duplicate it with a JUnit test. I created a BlockingListener
> with extends Listener and override the handleEvent() method. As you can see
> below we are loosing almost 7 events because of this one block.
>
> I know, eventHandlers are not supposed to block, so we definitely have a
> design issue here, but I figured I share the results with you because I am
> not sure this is what’s expected.
>
>
> Kind Regards,
>
> Erwin
>
>
> @Override
> public void handleEvent(final Event event) {
> this.test.handleEvent(event, this.payload);
> count++;
> if (count == 10) {
> logger.info<http://logger.info>("{} is blocking forever",
> Thread.currentThread().getName());
> while (true) {
> try {
> Thread.sleep(6);
> } catch (InterruptedException e) {
> //
> }
> }
> }
>
> }
>
>
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Starting eventing test
> StressTestIT
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Preparing test with 15
> threads and 1 events per thread.
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Expecting 105 events.
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Started test with 15
> threads and 1 events.
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Received 0 events so far.
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Received 0 events so far.
> [org.apache.felix.eventadmin.ittests.StressTestIT] :
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Started thread
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Started thread
> Started thread
> [org.apache.felix.eventadmin.ittests.StressTestIT] :
> [org.apache.felix.eventadmin.ittests.StressTestIT] :
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Started thread
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Started thread
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Started thread
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Started thread
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Started thread
> [org.apache.felix.eventadmin.ittests.StressTestITStarted thread
> Started thread
> ] : Started thread
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Started thread
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Started thread
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Started thread
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Started thread
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Received 12 events so
> far.
> [org.apache.felix.eventadmin.ittests.BlockingListener] : EventAdminThread #6
> is blocking forever
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Send 1 events.
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Send 1 events.
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Send 1 events.
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Send 1 events.
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Send 1 events.
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Send 1 events.
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Send 1 events.
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Send 1 events.
> [org.apache.felix.ev
Re: Is EventAdmin-1.4.6 really loosing events?
Thanks
I'm not sure if event admin could/should do anything in this case. Each
blocking listener takes away one thread from the thread pool. As soon as
you have as many blocking listeners as the pool has threads, event admin
will not deliver any event anymore
Regards
Carsten
Erwin Hogeweg wrote
> Hi Carsten,
>
> After analyzing a bunch of log files we found some evidence that suggested
> that an EventAdminThread might be blocked.
>
> I was able to duplicate it with a JUnit test. I created a BlockingListener
> with extends Listener and override the handleEvent() method. As you can see
> below we are loosing almost 7 events because of this one block.
>
> I know, eventHandlers are not supposed to block, so we definitely have a
> design issue here, but I figured I share the results with you because I am
> not sure this is what’s expected.
>
>
> Kind Regards,
>
> Erwin
>
>
> @Override
> public void handleEvent(final Event event) {
> this.test.handleEvent(event, this.payload);
> count++;
> if (count == 10) {
> logger.info("{} is blocking forever", Thread.currentThread().getName());
> while (true) {
> try {
> Thread.sleep(6);
> } catch (InterruptedException e) {
> //
> }
> }
> }
>
> }
>
>
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Starting eventing test
> StressTestIT
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Preparing test with 15
> threads and 1 events per thread.
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Expecting 105 events.
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Started test with 15
> threads and 1 events.
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Received 0 events so far.
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Received 0 events so far.
> [org.apache.felix.eventadmin.ittests.StressTestIT] :
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Started thread
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Started thread
> Started thread
> [org.apache.felix.eventadmin.ittests.StressTestIT] :
> [org.apache.felix.eventadmin.ittests.StressTestIT] :
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Started thread
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Started thread
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Started thread
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Started thread
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Started thread
> [org.apache.felix.eventadmin.ittests.StressTestITStarted thread
> Started thread
> ] : Started thread
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Started thread
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Started thread
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Started thread
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Started thread
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Received 12 events so
> far.
> [org.apache.felix.eventadmin.ittests.BlockingListener] : EventAdminThread #6
> is blocking forever
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Send 1 events.
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Send 1 events.
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Send 1 events.
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Send 1 events.
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Send 1 events.
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Send 1 events.
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Send 1 events.
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Send 1 events.
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Send 1 events.
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Send 1 events.
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Send 1 events.
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Send 1 events.
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Send 1 events.
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Send 1 events.
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Send 1 events.
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Received 980007 events
> so far.
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Received 980007 events
> so far.
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Received 980007 events
> so far.
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Received 980007 events
> so far.
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Received 980007 events
> so far.
> [org.apache.felix.eventadmin.ittests.StressTestIT] : Received 980007 events
> so far.
> [org.apache
[ANN] New Apache Felix PMC Chair: Karl Pauls
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 - To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
Re: Is EventAdmin-1.4.6 really loosing events?
Hi,
we haven't experienced anything like this so far and I wouldn't know if
any better out of the box way to trouble shoot. I guess the best would
be to add additional logging to event admin, so you can follow what's
happening inside event admin.
If it is somehow reproducible, then switching from postEvent to
sendEvent could also help in identifying whether there is a problem in
the postEvent handling (which is more complicated than sendEvent).
Regards
Carsten
Erwin Hogeweg wrote
> Hi,
>
> I have a really bizarre problem. It looks like the eventAdmin is intermittent
> but frequently loosing events. I find this very hard to believe but the
> evidence seems to support my suspicion.
>
> I spit out a log msgs just before the event is posted and also when the event
> is handled. There is only one eventHandler for this topic, and sure enough
> every now and again I see and event be posted but it never comes out at the
> other end.
>
> I have the event admin log level set to 4, but there aren’t any msgs to
> indicate that something wrong.
>
> I am really at a loss here. Any suggestions for further trouble shooting
> would be greatly appreciated.
>
> BTW… this seems to happen (and gradually increase) after the system has been
> up for several weeks which points in the direction of a resource leak, but I
> don’t see that either.
>
>
> Regards,
>
> Erwin
>
> Java8
> EventAdmin-1.4.6
> Equinox: 3.10.2.v20150203-1939
>
> Producer side:
> ...
> if (eventAdmin != null) {
> if (LOG.isDebugEnabled()) {
> LOG.debug("Posting: " + newEvent);
> }
> eventAdmin.postEvent(newEvent);
> } else {
> LOG.error("eventAdmin is null.");
> }
>
>
> Consumer side:
> @Override
> public void handleEvent( Event event ) {
> LOG.info<http://LOG.info>("handleEvent: " + event);
> ...
>
> Erwin Hogeweg
> CTO
> 3690 Airport Road
> Boca Raton, FL 33431
> P. +1 (954) 556-6565
> M. +1 (561) 306-7395
> F. +1 (561) 948-2730
> [Seecago]<http://www.seecago.com>
>
--
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
Re: Is async servlet requests supported in http.base version 3.0.16
Hi, yes, it should be supported. We have an integration test at [1] and that version is passing the test. [1] https://svn.apache.org/repos/asf/felix/trunk/http/itest/src/test/java/org/apache/felix/http/itest/AsyncTest.java Regards Carsten David Daniel wrote > I am getting an IllegalStateException. Is there a configuration option > that I can pass in or could it because I am using the enroute web server. > > java.lang.IllegalStateException > at > org.apache.felix.http.base.internal.dispatch.ServletRequestWrapper.startAsync(ServletRequestWrapper.java:314) > at > com.orbis.asae.linkanalysis.services.LAExport.doConditionalService(LAExport.java:126) > at > osgi.enroute.web.server.provider.DispatchServlet.service(DispatchServlet.java:63)[59:osgi.enroute.web.simple.provider:2.0.0.201610141745] > at > javax.servlet.http.HttpServlet.service(HttpServlet.java:725)[31:org.apache.felix.http.servlet-api:1.1.2] > at > org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:85)[30:org.apache.felix.http.jetty:3.4.0] > at > org.apache.felix.http.base.internal.dispatch.InvocationChain.doFilter(InvocationChain.java:79)[30:org.apache.felix.http.jetty:3.4.0] > > > Thanks for any help, > David > -- 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
Re: Immediate not active but satisfied
Hi,
could it be that you have an activate method and it throws an exception?
Regards
Carsten
David Daniel wrote
> I was under the impression that if a component is marked as immediate=true
> then it would start and run as a singleton once it was satisfied. This is
> apparently not the case. Is there a way to say once I have been satisfied
> then start and stay active until shutdown.
>
> @Component(service = {UndertowServer.class},
> immediate=true)
> public class UndertowServer {
> ...
>
>
> [ 69] com.orbis.aardvark.web.services.UndertowServer enabled
> [ 28] [satisfied ]
>
>
> Thank you for any help,
> David Daniel
>
--
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
Re: Service Factory returned null
I cant tell atm what is going on, but I suggest you to use the latest Apache Felix SCR Release (org.apache.felix.scr) just to rule out already known and solved problems. The same is true for the DS web console plugin Regards Carsten Martin12 wrote > Update: > Activating the keep component switch of org.apache.felix.scr.ScrService > seems to solve the problem. Any ideas why? This seems to suggest that > delayed components are cleaned up (for good) even if they are still needed. > > > > -- > View this message in context: > http://apache-felix.18485.x6.nabble.com/Service-Factory-returned-null-tp5021777p5021779.html > Sent from the Apache Felix - Users mailing list archive at Nabble.com. > > - > 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
Re: Lifecycle and Reference
his message. > > >Т�����ХF�?V�7V'67&�&R�?R��?�â?W6W'2�V�7V'67&�&T?fVƗ��???6�R��&pФf�"??FF�F���?�?6���?�G2�?R��?�â?W6W'2ֆV�??fVƗ��???6�R��&p > > > - > 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
Re: Version 3.3.0 Missing from Central Repository!
Hi, that link works for me. And http://central.maven.org/maven2/org/apache/felix/maven-bundle-plugin/3.3.0/ works as well Are you that you're not behind a proxy or something? Regards Carsten Pat Colangelo wrote > Hi, > > > > I have found that version 3.3.0 of the maven-bundle-plugin is missing from > maven central. I am only able to download versions <= 3.2.0. > > > > Repo page: > > https://mvnrepository.com/artifact/org.apache.felix/maven-bundle-plugin/3.3.0 > > > > Download link (will 404): > > http://central.maven.org/maven2/org/apache/felix/maven-bundle-plugin/3.3.0/maven-bundle-plugin-3.3.0.jar > > > > Please kindly reupload version 3.3.0. > > > > Regards, > > > > Pat Colangelo > Senior Software Developer | Konrad Group > Office: +1 877 900 1856 x 135 > www.konradgroup.com > -- 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
Re: Component annotations question
Bruce Jackson wrote > This bundle (org.osgi.service.component.annotations) is for compile-time only > use. Presumably then, when I’m writing my own bundle in Eclipse I should mark > the annotations bundle import as being optional? > No :) you should have no import for that package. The annotations have a retention policy of class, so they are not needed at all at runtime. Usually the tooling does not generate an import for such a package. 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
Re: Component annotations question
Hi, this jar contains the annotations: org.osgi org.osgi.service.component.annotations 1.3.0 They are processed at build time. If you're using Maven then e.g. the bundle plugin does this for you Regards Carsten Bruce Jackson wrote > Hi All > > This might be a super-dumb question, but where can I find a jar that exports > the org.osgi.service.component.annotations package and implements it? > The felix downloads page lists these downloads: > > SCR (Declarative Services) > SCR Annotations > SCR bnd Plugin > SCR Compat > SCR DS Annotations > SCR Ext Anno > SCR Generator > > …but none of the jars export the package above. > > Thanks > > Bruce > > *** DISCLAIMER *** This message, including attachments, is intended solely > for the addressee indicated in this message and is strictly confidential or > otherwise privileged. If you are not the intended recipient (or responsible > for delivery of the message to such person) : - (1) please immediately (i) > notify the sender by reply email and (ii) delete this message and > attachments, - (2) any use, copy or dissemination of this transmission is > strictly prohibited. If you or your employer does not consent to Internet > email messages of this kind, please advise Myriad Group AG by reply e-mail > immediately. Opinions, conclusions and other information expressed in this > message are not given or endorsed by Myriad Group AG unless otherwise > indicated by an authorized representative independent of this message. > > - > 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
Re: [osgi-dev] Components are not started,although marked with immediate=true
elix.scr console output:
>>>>>>
>>>>>> g! list
>>>>>> BundleId Component Name Default State
>>>>>> Component Id State PIDs (Factory PID)
>>>>>> [ 10] test.Con1 enabled
>>>>>> [ 0] [active ]
>>>>>> [ 10] test.InDataPort1 enabled
>>>>>> [ 1] [active ]
>>>>>> [ 10] test.OutDataPort1 enabled
>>>>>> [ 2] [active ]
>>>>>> [ 10] test.Process1 enabled
>>>>>> [ 3] [satisfied ]
>>>>>> [ 10] test.Thread1_1 enabled
>>>>>> [ 4] [satisfied ]
>>>>>> [ 10] test.Thread1_2 enabled
>>>>>> [ 5] [satisfied ]
>>>>>>
>>>>>> Am I doing something wrong?
>>>>>> I assumed that all services should be started as soon as they are
>>>>>> satisfied.
>>>>>>
>>>>>> Any advice is highly appreciated.
>>>>>>
>>>>>> Kind regards,
>>>>>> Thomas
>>>>>>
>>>>>>
>>>>>> @Component(immediate = true, service = IProcess.class, property =
>>>>>> "de.uniaugsburg.smds.aadl2osgi.component.uid=test.Process1")
>>>>>> public class Process1 implements IProcess {
>>>>>>
>>>>>> @Reference(target = "(uid=test.Thread1_1)")
>>>>>> private volatile IPeriodicThread thread1;
>>>>>>
>>>>>> @Reference(target = "(uid=test.Thread1_2)")
>>>>>> private volatile IPeriodicThread thread2;
>>>>>> }
>>>>>>
>>>>>>
>>>>>> @Component(service = IPeriodicThread.class, property =
>>>>>> "de.uniaugsburg.smds.aadl2osgi.component.uid=test.Thread1_1", immediate =
>>>>>> true)
>>>>>> public class Thread1_1 implements IPeriodicThread {
>>>>>>
>>>>>> @Reference(target = "(uid=test.OutDataPort1)")
>>>>>> private volatile IOutDataPort outport;
>>>>>>
>>>>>> @Activate
>>>>>> public void initialize_FW() {
>>>>>> init();
>>>>>> }
>>>>>>
>>>>>> @Deactivate
>>>>>> public void finalize_FW() {
>>>>>> deinit();
>>>>>> }
>>>>>> }
>>>>>>
>>>>>>
>>>>>> @Component(service = IPeriodicThread.class, property =
>>>>>> "de.uniaugsburg.smds.aadl2osgi.component.uid=test.Thread1_2", immediate =
>>>>>> true)
>>>>>> public class Thread1_2 implements IPeriodicThread {
>>>>>>
>>>>>> @Reference(target = "(uid=test.InDataPort1)")
>>>>>> private volatile IOutDataPort outport;
>>>>>>
>>>>>> @Activate
>>>>>> public void initialize_FW() {
>>>>>> init();
>>>>>> }
>>>>>>
>>>>>> @Deactivate
>>>>>> public void finalize_FW() {
>>>>>> deinit();
>>>>>> }
>>>>>> }
>>>>>>
>>>>>>
>>>>>> @Component(service = IOutDataPort.class, property =
>>>>>> "uid=test.OutDataPort1", immediate = true)
>>>>>> public class OutDataPort1 implements IOutDataPort {
>>>>>>
>>>>>> @Reference(target = "(target=test.OutDataPort1)", cardinality =
>>>>>> ReferenceCardinality.OPTIONAL, policyOption =
>>>>>> ReferencePolicyOption.GREEDY)
>>>>>> private volatile IPortConnection incomingPortConnections;
>>>>>>
>>>>>> private volatile Set outgoingPortConnections = new
>>>>>> ConcurrentSkipListSet();
>>>>>>
>>>>>> @Reference(target = "(source=test.OutDataPort1)", cardinality =
>>>>>> ReferenceCardinality.OPTIONAL, policyOption =
>>>>>> ReferencePolicyOption.GREEDY)
>>>>>> public void addOutgoingPortConnection(final IPortConnection con) {
>>>>>> outgoingPortConnections.add(con);
>>>>>> }
>>>>>>
>>>>>> public void removeOutgoingPortConnection(final IPortConnection con) {
>>>>>> outgoingPortConnections.remove(con);
>>>>>> }
>>>>>> }
>>>>>>
>>>>>>
>>>>>> @Component(service = IInDataPort.class, property =
>>>>>> "uid=test.InDataPort1",
>>>>>> immediate = true)
>>>>>> @SuppressWarnings("all")
>>>>>> public class InDataPort1 implements IInDataPort {
>>>>>>
>>>>>> @Reference(target = "(target=test.InDataPort1)", cardinality =
>>>>>> ReferenceCardinality.OPTIONAL, policyOption =
>>>>>> ReferencePolicyOption.GREEDY)
>>>>>> private volatile IPortConnection incomingPortConnections;
>>>>>>
>>>>>> private volatile Set outgoingPortConnections = new
>>>>>> ConcurrentSkipListSet();
>>>>>>
>>>>>> @Reference(target = "(source=test.InDataPort1)", cardinality =
>>>>>> ReferenceCardinality.OPTIONAL, policyOption =
>>>>>> ReferencePolicyOption.GREEDY)
>>>>>> public void addOutgoingPortConnection(final IPortConnection con) {
>>>>>> outgoingPortConnections.add(con);
>>>>>> }
>>>>>>
>>>>>> public void removeOutgoingPortConnection(final IPortConnection con) {
>>>>>> outgoingPortConnections.remove(con);
>>>>>> }
>>>>>> }
>>>>>>
>>>>>>
>>>>>> @Component(service = IPortConnection.class, property = {
>>>>>> "source=test.OutDataPort1", "target=test.InDataPort1" }, immediate =
>>>>>> true)
>>>>>> public class Con1 implements IPortConnection {
>>>>>> @Reference(cardinality = ReferenceCardinality.OPTIONAL, policyOption =
>>>>>> ReferencePolicyOption.GREEDY, target = "(uid=test.OutDataPort1)")
>>>>>> private volatile IOutDataPort source;
>>>>>>
>>>>>> @Reference(cardinality = ReferenceCardinality.OPTIONAL, policyOption =
>>>>>> ReferencePolicyOption.GREEDY, target = "(uid=test.InDataPort1)")
>>>>>> private volatile IInDataPort target;
>>>>>> }
>>>>>> ___
>>>>>> OSGi Developer Mail List
>>>>>> osgi-...@mail.osgi.org
>>>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>> -
>>>> 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
>
>
--
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
Re: Order of service (un-)registration in SCR
Jens Offenbach wrote > Hi, > I require some advice regarding "Declarative Services". Unfortunately, I > cannot find anything in the specficiation. I have a component that registers > a service in the service registry. > > What is the order during component activation and deactivation regarding > service (un-)registration via SCR? When is the service registered and > unregistered in the service registry? > > I made a quick test and found out that the service gets registered before the > component is fully activated (breakpoint in "activate" method). I do not > expect that behaviour and what about deactivation. I would expect that the > service gets unregistered and afterwards the component gets deactived. > It's correct that the service is registered before the component is activated. The SCR implementation registers a service factory on behalf of the component. Only if someone is requestion the service from the registration, the component gets activated. This is in order to support lazy creation of the component. Otherwise SCR would need to activate all components and maybe only half of them are used. The service gets unregistered first and then deactivate is called, assuming that the component has been activated in the first place. So if no one is using your service, nothing happens wrt your component. 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
Re: Source bundles
Tom Quarendon wrote >> Thanks for reporting, I just fixed some of them, at least http base, api etc >> should now be downloadable. Just refresh the download page > OK thanks. The ones I need now seem to work (HTTP Service Bundle and HTTP > Service Cometd don't but I don't need those, and actually the "bundle" one, > the binary doesn't work either suggesting that's not a thing anymore). > I just fixed the most important ones, but I'll definitely go through the whole list at some point 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
Re: Source bundles
Thanks for reporting, I just fixed some of them, at least http base, api etc should now be downloadable. Just refresh the download page Carsten Tom Quarendon wrote > From: > http://felix.apache.org/downloads.cgi > > Link: > http://mirror.ox.ac.uk/sites/rsync.apache.org//felix/org.apache.felix.http.api-3.0.0-project.tar.gz > But also: > http://apache.mirrors.nublue.co.uk//felix/org.apache.felix.http.api-3.0.0-project.tar.gz > > Etc. > Just go to the download page and click any of the HTTP links. I've yet to > find one that works for the HTTP bundles (actually it looks like others DO > work, it just appears to be the HTTP bundles that don't). > > > -Original Message- > From: Bernd Eckenfels [mailto:e...@zusammenkunft.net] > Sent: 11 January 2017 15:37 > To: users@felix.apache.org > Subject: Re: Source bundles > > Can you paste one of the broken links as well as the page you found that > broken link? > > Gruss > Bernd > -- 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
Re: DS 1.3 Components from different bundle using same configurationPid are not all updated
Hi,
I think this should be possible the way you do it, so that's a "yes" to
the first two of your questions at the end :)
Before we start to look for a bug in the implementation, could you
please check the scr 2.0.6 release and see whether it's already fixed there?
If not, please open a jira ticket.
Regards
Carsten
Christian Wolf wrote
> Hi,
>
> I am using DS @Component and trying to get notified through @Modified when
> a shared pid file is updated (using felix scr 2.0.2 in karaf 4.0.5)
>
> I defined a configuration interface such as:
>
> @ObjectClassDefinition(pid = "foo.bar")
> public @interface MyConfig {
> String username() default "myuser";
> String url() default "http://localhost:8080";;
> }
>
> Then, I have 3 differents classes with @Component annotation. All of them
> are mapped to this pid "foo.bar".
> Please note that each component is defined in separated bundles.
>
> @Component(configurationPid = "foo.bar", immediate = true)
> @Designate(ocd = MyConfig.class)
> public class CompA implements MyInterfaceA {
>
> @Activate
> public void activate(MyConfig myConfig) {
> ...
> }
>
> @Modified
> public synchronized void modify(MyConfig myConfig) {
> ...
> }
> }
>
> @Component(configurationPid = "foo.bar")
> @Designate(ocd = MyConfig.class)
> public class CompB implements MyInterfaceB {
>
> @Activate
> public void activate(MyConfig myConfig) {
> ...
> }
>
> @Modified
> public synchronized void modify(MyConfig myConfig) {
> ...
> }
> }
>
> @Component(configurationPid = "foo.bar")
> @Designate(ocd = MyConfig.class)
> public class CompC implements MyInterfaceC {
>
> @Activate
> public void activate(MyConfig myConfig) {
> ...
> }
>
> @Modified
> public synchronized void modify(MyConfig myConfig) {
> ...
> }
> }
>
> All these 3 components are activated.
> When the corresponding pid file foo.bar.cfg is updated, the
> modify(MyConfig) method surrounded with the @Modified annotations is
> invoked only for one of them.
> Moreover, the component that get updated randomly change when restarting
> the application.
>
> Question:
> - Can @Component(s) of separate bundles be notified through @Modified
> annotated methods when a shared pid file is updated?
> - Is it possible to achieve this using annotation configuration classes as
> I did here with MyConfig class (with DS 1.3)?
> - If not possible, is there any alternative solution to achieve this?
>
> Thanks for your help.
> Kind Regards,
> Christian
>
--
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
Re: HTTP/REST access to webconsole configurations
The easiest way to find this out is to use the web console and look at the post request it sends :) Afaik, the url should have the PID as a suffix. If you send add create=true, the configuration will be created. Afaik, you can't set properties, just create. For modificiation send apply=true then propertyList with a comma separate list of properties you want to apply and then for each property the parameter with the value. For example if you want to change/set a and b then it is: ?apply=true&propertyList=a,b&a=5&b=10 It's ugly and has some historic reasons; would be great if a spec for a REST api for configurations existed Carsten David Bosschaert wrote > Hi all, > >>From the documentation at I think that the webconsole supports POST > requests to create/modify configurations, but the documentation is a little > cryptic. Does anyone have any examples of how this can be used, e.g. from > curl? > > Thanks, > > David > > [1] > http://felix.apache.org/documentation/subprojects/apache-felix-web-console/web-console-restful-api.html#post-requests_1 > -- 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
Re: Config admin, DS 1.3 and configuration plugin questions
Nicolas Brasey wrote > Hi Carsten! > > Thanks for your answer! > > That is great it will come soon as this will be a real great feature! > Looking forward. For the time being, we will not use the plugin and do the > extra decryption in the services directly. > > Is there an ETA for the release of the new spec and the corresponding > implementation ? > The current schedule is to release the spec somewhere in Q3 2017. As soon as there is an official release, we'll release the impl. 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
Re: Config admin, DS 1.3 and configuration plugin questions
Hi,
this does not work with DS 1.3 as DS is getting the configurations from
configuration admin directly and they are not filtered by the plugins.
But the good news is that DS 1.4 together with configuration admin 1.6
will support this. These updates of the specs are part of the upcoming
OSGi R7 release. This feature is already implemented in trunk, so if you
take the configuration admin and scr snapshots currently in trunk, it
should work.
Regards
Carsten
Nicolas Brasey wrote
> Hi all,
>
> Me and a collegue are fighting to get something working with the config
> admin.
>
> We are trying to accomplish to following:
>
> 1) Using the config admin with the new Interfaces reprensenting the
> configuration (DS v.1.3)
> 2) Using a config admin plugin to decrypt some configured properties
> (example password) before the DS components method annotated with @Modified
> gets called by the config admin
>
> We manage to have the plugin mechanism working according to the following
> code:
>
> https://github.com/osgi/osgi.enroute.examples/tree/master/osgi.enroute.examples.cm.application/src/osgi/enroute/examples/cm/examples
>
> But we want to use the interface instead of the dictionnary and be able to
> use the @Modified annotation on the method level.
>
> As described here:
> http://njbartlett.name/2015/08/17/osgir6-declarative-services.html
>
> Such as:
>
> @Modified
> public void updateConfig(MyConfigInterface myConfig)
> {
> ...
> }
>
> Questions:
>
> 1) Is it achiveable as is with DS 1.3 and the config admin ?
> 2) Do you know any reference where we could have a look on how it is
> supposed to work ?
>
> Thanks for any help on that matter!
>
> Regards,
> Nicolas
>
--
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
Re: POST requests being processed twice by felix HTTP
Hi, you can use the runtime service defined by the Http Whiteboard spec to find out whether something is still registered. The only downside is that you need to poll and check the DTOs until the desired state is reached. But for testing this should be totally fine. However, it would be great if we could further pinpoint the problem and avoid the duplicate requests in general. Carsten Tom Quarendon wrote >> If that is not the case setting a break point in the DispatcherServlet from >> Felix will tell you whether the request is called twice from outside the >> Felix http implementation (Jetty in that case then) or now. > > The implication of this (I haven't looked into the felix code at this point, > and actually all of the source links for the HTTP projects on the felix > download page seem to be broken, I've tried numerous mirrors) is that there > is a single servlet that you register with jetty, and then you manage > distributing the request to the relevant servlet? > > We are as sure as we can be that there is only one HTTP request made, and two > calls to the server. We've turned on Jetty tracing and logged our own servlet > and this appears to be the case. Up until recently we haven't had a reliable > way to reproduce it, but the technique of editing the code in a debug session > so that you can force it to redeploy the component while it's in the middle > of processing the request appears to work. > > Since my original post, I realise that in some ways it's not interesting why > the problem occurs, or actually "solving" it (clearly, to me, POST being > processed twice is a bug somewhere). > Instead what we want is to make our tests reliable. And I think what this > means is that we need a way of waiting until everything is shut down after > each test. If we had a way of detecting whether all servlets had been > deregistered, then that might help. We suspect that although our test has > finished, background reconfiguration occurs within OSGi, and this is still > happening when the next test starts. It then makes a request that gets > handled by a servlet that is in the process of being shut down. If we could > avoid all of that, and ensure that we go back to a clean slate each time, > that's probably what we really need. > > > > ----- > 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
Re: POST requests being processed twice by felix HTTP
Tom Quarendon wrote > We've got an off problem that we're trying to diagnose. > > The symptoms are that a POST request is sent, and the servlet gets called > twice to process it, resulting in a duplicate key violation on the database. > > This appears to occur when reconfiguration of components occurs whilst the > request is being processed. > So what appears to happen is that the request is received, and the servlet > gets called to process it. > Before the response is generated, the servlet component gets recycled, > destroyed and recreated. Felix HTTP whiteboard responds to these lifecycle > events and presumably reconfigures jetty in response. > Someone, somewhere then decides that the request should be retried, and the > same request then gets passed to the new servlet, and the response from that > gets sent back to the client. > > This primarily happens in testing environments when the world is being > brought up and down for each test, but you can actually reproduce it in the > debugger by putting a breakpoint in the servlet, then when the breakpoint is > hit, edit the code and save it. The servlet gets recycled and the request is > processed twice. > > In our case the servlet is being registered using declarative services, using > the HTTP whiteboard service. > > Is this a known problem? > Is there a known solution to this problem? > > Where is the most likely culprit? It seems highly unlikely that jetty would > be trying a POST request, that would appear to fundamentally break the > contract for POST. GET, PUT, DELETE fine, they are all idempotent, but not > POST. > > I haven't yet delved into the felix HTTP whiteboard code to try and > understand its relationship with jetty, so I've no idea whether felix http > would get involved, or whether the problem would lie with jetty. Is it likely > that the problem is at the felix layer? > > Any suggestions for investigation would be most appreciated. > Hi, afaik there is nothing in the Felix http implementation which would re-execute the request. The registration in Jetty is not changed when servlets are registered or unregistered through OSGi, so at first look this would rule out Jetty for me as well :) Are you sure that your client is not sending a second request if the first fails? Or do you have an error servlet registered that is called? If that is not the case setting a break point in the DispatcherServlet from Felix will tell you whether the request is called twice from outside the Felix http implementation (Jetty in that case then) or now. 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
Re: OSGi and ObjectInputStream.readObject() deserialization classloading
Christopher Brown wrote > Hello, > > I need to define an API for an OSGi service capable of persisting arbitrary > Serializable objects as byte arrays (to disk, or over the network), and > then capable of deserializing the object via the API. The objects to be > persisted will almost always be defined by another bundle, so the bundle > actually performing the serialization is almost always going to be unable > to access the classloader that originally provided the definition of the > serialized class (and any non-primitive attributes of that class). > > Any ideas upon how to use java.io.ObjectInputStream such that its > .readObject() method can be forced to use an appropriate classloader? I > can't see how to override its default behavior. > > As for the API I need to implement (my service), it would be along the > lines of: > > void service.store(String id, Object value); > > T service.fetch(String id, Class implementationType) > > ...where implementationType would need to be equivalent to value.getClass() > (and not a superclass or implemented interface). The "fetch" method would > need the "implementationType" parameter to access the CURRENT version of > the classloader (I can't store the classloader in the "store" method, first > off because I can't serialize arbitrary classloaders -- via > value.getClass().getClassloader() -- and also because the classloader might > be the wrong version, if "value" was defined by a bundle that has since > been reloaded). > > Even if I replaced the "implementationType" parameter with a classloader > reference (assuming the caller of the code knew which classloader to use), > I still don't know how to override ObjectInputStream's default classloading > behavior. > > Any ideas ? > You can create a subclass of ObjectInputStream and overwrite the resolveClass method to solve the first project. Some time ago we wrote some code, that was using a dynamic class loader in such a subclass that simply used Package Admin to find the bundle providing the class and then using the corresponding class loader. Of course this requires that the classes you want to load are publicly exported. I'm not saying this is the best solution, but it did the trick for us. 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
Re: java.lang.IllegalStateException: Configuration Admin service has been unregistered
Toni Menzel wrote > yep SCR 2.0.6 helps. thanks! > That would have been my response :) Great! 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
Re: java.lang.IllegalStateException: Configuration Admin service has been unregistered
This sounds familiar to me, which SCR version are you using? Regards Carsten Toni Menzel wrote > Hey (again), > > i am a bit puzzled with a IllegalStateException when interacting with Felix > ConfigAdmin via DS: > > Daemon Thread [CM Event Dispatcher (Fire ConfigurationEvent: > pid=.ConnectionPid)] (Suspended (entry into method dispose in > ConfigurationAdminImpl)) > > ConfigurationAdminImpl.dispose() line: 56 > > ConfigurationAdminFactory.ungetService(Bundle, > ServiceRegistration, Object) line: 63 > > ServiceRegistrationImpl.ungetFactoryUnchecked(Bundle, > Object) line: 388 > > ServiceRegistrationImpl.ungetService(Bundle, Object) line: > 286 > > ServiceRegistry.ungetService(Bundle, ServiceReference, > Object) line: 470 > > Felix.ungetService(Bundle, ServiceReference, Object) line: > 3711 > > BundleContextImpl.ungetService(ServiceReference) line: > 483 > > > ComponentRegistry$3(RegionConfigurationSupport).getConfigurationInfo(TargetedPID, > TargetedPID, ComponentHolder, BundleContext) line: 465 > > > ComponentRegistry$3(RegionConfigurationSupport).configurationEvent(ConfigurationEvent) > line: 259 > > ConfigurationManager$FireConfigurationEvent.sendEvent(int) > line: 2046 > > ConfigurationManager$FireConfigurationEvent.run() line: > 2014 > > UpdateThread.run() line: 103 > > Thread.run() line: 745 > > > > Here is what I have: > https://gist.github.com/tonit/8a4c7b118a5ac282313f49f509f9990f > > Now, with > https://gist.github.com/tonit/8a4c7b118a5ac282313f49f509f9990f#file-updaterimpl-java > we get the IllegalStateException upon 2nd call to updateConfig.. > > With > https://gist.github.com/tonit/8a4c7b118a5ac282313f49f509f9990f#file-updaterimplalternative-java > we > do not get the problem. > > So, is this the intended way do this? Just lookup the configuration once > and keep using it? > What if i do need to get another configurationPid? I guess the ConfigAdmin > would again give that Exception. > > Thanks, > Toni > > *Toni Menzel* > > > *Developing The Rebaze Way* > > *www.rebaze.de <http://www.rebaze.de/> | www.rebaze.com > <http://www.rebaze.com/> | @rebazeio <https://twitter.com/rebazeio>* > -- 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
Re: EventHandler handleEvent threads never seem to get cleaned up.
Hi,
this sounds strange, the event admin impl is using a thread pool, so
it's ok that the thread stays around after it has delivered the event.
It will be reused for one of the next events. The pool has a limit, so
you shouldn't get more threads than that limit.
I'm wondering what this has to do with CPU though? If you create a
thread dump are these threads executing something or really just waiting
in the pool?
Regards
Carsten
David Daniel wrote
> I am registering an event handler with the evenadmin.
>
> pingRegistration = bc.registerService(
> EventHandler.class.getName(), new PingEventHandler(), p);
>
>
> private class PingEventHandler implements EventHandler {
>
> @Override
> public synchronized void handleEvent(Event event) {
> String userId = "";
> for (String name : event.getPropertyNames()) {
> if (name.equals("type")) {
> if
> (event.getProperty(name).equals(PingDTO.class.getCanonicalName())) {
> userId = (String)event.getProperty("userId");
> }
> }
> }
> if (!userId.isEmpty()) {
> IUser pingedUser = UserManager.this.getUser(userId);
> pingedUser.setLastActive(LocalDateTime.now());
> pingedUser.getId().ifPresent(id -> {
> UserManager.this.put(pingedUser);
> });
> }
> }
>
> }
>
> Things seem to run through all the code ok but after each ping event a new
> thread is created for the EventHandler and it never gets destroyed but only
> parked. Because of that my program quickly uses up all the cpu on the
> box. Is there a way to have the Executer that runs the eventHandles clear
> the thread when it is done or am I doing something wrong and have a loop
> that I am just missing.
>
> Thanks for any help,
> David
>
--
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
Re: OSGi Declarative Services
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
Re: [configadmin] Handling of Factory Configurations
Balázs Zsoldos wrote > Hi, > > I saw in the Jira <https://issues.apache.org/jira/browse/FELIX-5289>that it > will be possible to create a new factory configuration with pre/defined > PID. I am very interested in this feature as it will make it possible to > deploy a set of configurations without tricks. > > I have several questions: Do you have a due date for ConfigAdmin 1.9.0? This depends on the release of the R7 spec, which is scheduled for around mid next year. We're depending on new OSGi api which needs tp be released first. > > I wrote my other questions into the issue, but as it it closed, I thought > it would be useful to ask them here, too. > > At the moment PID for factory configurations look like: *myFactoryPID.GUID* This is an implementation detail at the moment, it could just be GUID or something totally different. > > What will happen with these configurations if I upgrade to the next > versions of ConfigAdmin? I can imagine two solutions: > >- They will be renamed to *myFactoryPID#GUID* >- They will be left as they are They are left as they are. > > In case that they will be left as they are, how can we get them with the > new functions? You can't - if you're using the old api or have used the old api, you have to stay within the old api. There is currently no rule how the pid for a factory pid should be generated, so we can't provide any api that is supposed to work across all implementations. As mentioned above, the pid could be anything, just a GUID, or a GUID with a random number etc. Carsten > > The *Configuration* interface contains the following functions: *getPid()* > and *getFactoryPid()*. How can we get the alias of the PID? Do we need to > do some String evaluation? I am missing a function like *getAlias()* from > the *Configuration* or a constant that tells you the separation character. > > Kind regards, > *Balázs* > -- 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
Re: Prop expansion via fileinstall but not configuration admin
> 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. > 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 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
Re: Failing to get felix scr logging
> 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
Re: scr claims to be unsatisfied for service that seems to be there
> 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? > 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 -- 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
Re: scr claims to be unsatisfied for service that seems to be there
Your service is marked as "satisfied" but as noone else is using it, it's not activated. That's the lazy activation of SCR. Carsten > 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 > > -- 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
Re: Bundles needed to use DS/SCR
Just guessing but you have: > Configuration Policy: require Do you have a configuration for this component in config admin? 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
Re: Cannot use configuration pid ... for bundle XX because it belongs to bundle YY
> Carsten, are you sure about null and not the literal string "?"
Hi,
both work - if you have a configuration admin supporting multi locations
(the "?"). But as that is in there for some time, you probably have it.
null works in any case and does not change the location at all - that's
why I prefer it.
>From the javadocs of getConfiguration:
*If the
* location parameter is {@code null}, it will be set when a Managed
Service
* with the corresponding PID is registered for the first time.
Carsten
>
> - Ray
>
> On Wed, Aug 10, 2016 at 9:57 AM, Carsten Ziegeler
> wrote:
>
>>> Did not find any annotation in those components, they actually get
>> configured using the ConfigurationAdmin.
>>>
>>> Error:
>>> >> pid=com.kuka.authorizationService.component
>> for bundle 7 because it belongs to bundle 77>
>>>
>>> OSGI-LIB\*.xml:
>>> http://www.osgi.org/xmlns/scr/v1.1.0";
>> activate="activate" configuration-policy="require" deactivate="deactivate"
>> immediate="true" name="com.kuka.authorizationService.component">
>>>
>>>
>>>
>>>
>>>>> bind="setServiceRegistry"
>>> cardinality="1..1"
>>> interface="comIServiceRegistry"
>>> name="IServiceRegistry"
>>> configuration-policy="require"
>>> policy="static"/>
>>>
>>>
>>> The component itself that has no annotations at all:
>>> [...]
>>> import com.IServiceRegistry;
>>>
>>> /**
>>> * The OSGI component for the {@link AuthorizationService}.
>>> */
>>> public class AuthorizationServiceComponent implements
>> IAuthorizationOsgiService
>>> [...]
>>>
>>> The main bundle activator does the following regarding this component:
>>> Dictionary properties = new Hashtable();
>>> properties.put("userRolesFile", "someFileSystemPath");
>>> properties.put("userCredentialsFile", "someFileSystemPath");
>>> configAdmin.getConfiguration("com.kuka.authorizationService.
>> component").update(properties);
>>
>> This is exactly your problem :) With this you bind the configuration to
>> the bundle executing this code and then DS can't use it anymore. Change
>> it to use the two argument getConfiguration method and pass null as the
>> second argument (location).
>>
>> Regards
>> Carsten
>>>
>>> Interesting that all bundles that are configured like this end in such
>> an error.
>>> The application I try to wrap was built in equinox and starts there
>> without issues.
>>>
>>>
>>>
>>> -Original Message-
>>> From: Benson Margulies [mailto:ben...@basistech.com]
>>> Sent: Mittwoch, 10. August 2016 12:46
>>> To: users@felix.apache.org
>>> Subject: Re: Cannot use configuration pid ... for bundle XX because it
>> belongs to bundle YY
>>>
>>> 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(); [...] }
>>>>
&
Re: Cannot use configuration pid ... for bundle XX because it belongs to bundle YY
> Did not find any annotation in those components, they actually get configured
> using the ConfigurationAdmin.
>
> Error:
> pid=com.kuka.authorizationService.component for bundle 7 because it belongs
> to bundle 77>
>
> OSGI-LIB\*.xml:
> http://www.osgi.org/xmlns/scr/v1.1.0";
> activate="activate" configuration-policy="require" deactivate="deactivate"
> immediate="true" name="com.kuka.authorizationService.component">
>
>
>
>
> bind="setServiceRegistry"
> cardinality="1..1"
> interface="comIServiceRegistry"
> name="IServiceRegistry"
> configuration-policy="require"
> policy="static"/>
>
>
> The component itself that has no annotations at all:
> [...]
> import com.IServiceRegistry;
>
> /**
> * The OSGI component for the {@link AuthorizationService}.
> */
> public class AuthorizationServiceComponent implements
> IAuthorizationOsgiService
> [...]
>
> The main bundle activator does the following regarding this component:
> Dictionary properties = new Hashtable();
> properties.put("userRolesFile", "someFileSystemPath");
> properties.put("userCredentialsFile", "someFileSystemPath");
> configAdmin.getConfiguration("com.kuka.authorizationService.component").update(properties);
This is exactly your problem :) With this you bind the configuration to
the bundle executing this code and then DS can't use it anymore. Change
it to use the two argument getConfiguration method and pass null as the
second argument (location).
Regards
Carsten
>
> Interesting that all bundles that are configured like this end in such an
> error.
> The application I try to wrap was built in equinox and starts there without
> issues.
>
>
>
> -Original Message-
> From: Benson Margulies [mailto:ben...@basistech.com]
> Sent: Mittwoch, 10. August 2016 12:46
> To: users@felix.apache.org
> Subject: Re: Cannot use configuration pid ... for bundle XX because it
> belongs to bundle YY
>
> 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
>>
>>
> 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
>
--
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
Re: Get a list of paths of registered servlets
Marcel Offermans wrote > That only helps him if he uses the whiteboard API. If he directly talks to > HttpService it probably won’t work. > The Felix implementation also lists all servlets registered with the HttpService using the DTO api. 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
Re: Where can I find the default implementation of httpcontext
Raymond Auge wrote > I believe in the latest felix http impl Carsten added a feature to be able > to target legacy contexts using DS via http whiteboard. > > However, you need to know the name of this legacy context > and I'm not sure how you do that in the felix impl. > Yes, you can reference the http contexts using the whiteboard by specifying the value "org.osgi.service.http" for the context name property. But this is - as Ray notes - implementation specific. The next version of the http whiteboard spec might have a solution for this 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
Re: Plaintext password in configuration files for Jetty and Webconsole
Roland Tepp wrote > Console (weather accessed over web or ssh) should be a trusted environment. > If a untrusted user gains access to you console you have much more serious > problems than access to some configuration options. Well, sure - but don't forget that the web console allows to create a zip with all the configurations and your password ends up in plain text there as well. You definitely don't want to pass on passwords from production to your engineering or support team when they do trouble shooting. Of course you can post process the zip, but people will forget about it. And there are other similar ways where you definitely don't want to display the passwords in plain text, even in the web console. For example you trust the admin of your app to do configurations, checking bundles and such, but the database admin will not want that this person knows/sees the database password. It all depends on your environment etc. of course. But in general having an easy way to get a password in plain text scares most security people away. Carsten > On Sun, 24 Apr 2016 at 02:29, Carsten Ziegeler wrote: > >> Peter Kriens wrote >>> You could adjust cm to recognize a macro and expand that macro to >> something local like a file, a system property, or an environment variable. >>> >>> That is how I solved it in the Configurer. Works very well on Travis >> that allows you to configure with encrypted data that is decrypted as >> environment variables. >>> >> >> This still has the problem that the decrypted data is visible to >> everyone (via web console etc.) >> >> >> 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 >> >> > -- 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
Re: Plaintext password in configuration files for Jetty and Webconsole
Peter Kriens wrote > You could adjust cm to recognize a macro and expand that macro to something > local like a file, a system property, or an environment variable. > > That is how I solved it in the Configurer. Works very well on Travis that > allows you to configure with encrypted data that is decrypted as environment > variables. > This still has the problem that the decrypted data is visible to everyone (via web console etc.) 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
Re: ExtHttpService deprecated
David Daniel wrote > I noticed ExtHttpService is deprecated. Is there a better way to register > a filter now than the example here > http://felix.apache.org/documentation/subprojects/apache-felix-http-service.html > Yes, the documentation is totally outdated. There is the Http Whiteboard Specification - it's part of the OSGi Compendium R6 and this is how you should do these things today. I think the examples in svn are updated. I'll probably update the docs in some weeks if no one beats me to it. 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
Re: Plaintext password in configuration files for Jetty and Webconsole
Antonio Sanso wrote > hi, > > I would actually have the same question? > > Is there anything can be done here ? If not there is any plan to improve this? > I might try to help out in this area providing a patch… > > Anyone :)? > Didn't we discuss some time back to have a crypt service and leave it up to every component to use this service to decrypt configuration properties? Automatic decryption e.g. in configuration admin is not really a good idea, as this would mean everyone can get the configuration decrypted and it's visible in the web console, in the status zip etc. 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
Re: Plaintext password in configuration files for Jetty and Webconsole
Ferry Huberts wrote > Thanks Neil > > This is what I thought/feared. > > To me, at least the webconsole doesn't need a plaintext password and can > use the same hashing mechanism the Unices use. Carsten? > Not sure I understand your question, what do you mean with "Unices"? 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
Re: maven-scr-plugin and DS 1.3 annotations not working
David Jencks wrote
> I’m not certain how the maven-bundle-plugin is set up, but with bnd by itself
> the default is dsannotatios and metatypeannotations are *, so I’d be
> surprised if you have to specify them in the instructions here.
You're right, you don't have to. It seems at some 3.0.0-SNAPSHOT this
was required and I still have them in my poms :)
Carsten
>
> david jencks
>
>> On Mar 22, 2016, at 12:18 AM, Jens Offenbach wrote:
>>
>> @Carsten
>> This is working... Thank you very much for your help!
>>
>> For all those who are on Eclipse PDE and require the OSGI-INF folder in the
>> project root, use the maven-bundle-plugin with
>> "true" and copy the folder to your project
>> basedir like this:
>>
>> org.apache.maven.plugins
>> maven-resources-plugin
>>
>>
>> copy-scr-descriptor
>> process-classes
>>
>> copy-resources
>>
>>
>>
>> ${basedir}/OSGI-INF
>>
>>
>>
>> ${project.build.outputDirectory}/OSGI-INF
>> false
>>
>>
>>
>>
>>
>>
>>
>> Regards,
>> Jens
>>
>>
>> Gesendet: Dienstag, 22. März 2016 um 07:45 Uhr
>> Von: "Carsten Ziegeler"
>> An: users@felix.apache.org
>> Betreff: Re: maven-scr-plugin and DS 1.3 annotations not working
>> The maven-scr-plugin does not support the DS 1.3 annotations.
>> Using the maven-bundle-plugin 3.0.1 is all you need. I think you need to
>> add this configuration to the bundle plugin:
>>
>>
>>
>> <_dsannotations>*
>> <_metatypeannotations>*
>>
>>
>>
>> Carsten
>>
>>
>> Jens Offenbach wrote
>>> Hi,
>>> I am using maven-scr-plugin:1.21.0,
>>> org.osgi.service.component.annotations:1.3.0,
>>> org.apache.felix.scr.ds-annotations:1.2.8 and
>>> org.apache.felix.scr.annotations:1.9.12 and maven-bundle-plugin:3.0.1.
>>>
>>> This is my annotated class with makes use of the prototype scope:
>>>
>>> @Component(immediate = true, configurationPolicy =
>>> ConfigurationPolicy.REQUIRE)
>>> @Service(HttpContextMapping)
>>> public class HttpContextMappingComponent implements HttpContextMapping {
>>>
>>> @Reference(scope = ReferenceScope.PROTOTYPE_REQUIRED, cardinality =
>>> ReferenceCardinality.MANDATORY, bind = "bind", unbind = "unbind")
>>> private HttpEndpointManager endpointManager;
>>> ...
>>>
>>> }
>>>
>>> This is the component definition file created by maven-scr-plugin:
>>>
>>>
>>> http://www.osgi.org/xmlns/scr/v1.1.0";
>>> immediate="true"
>>> name="test.osgi.service.http.paxweb.impl.component.HttpContextMappingComponent"
>>> configuration-policy="require" activate="activate" deactivate="dispose">
>>> >> class="test.osgi.service.http.paxweb.impl.component.HttpContextMappingComponent"/>
>>>
>>> >> interface="org.ops4j.pax.web.extender.whiteboard.HttpContextMapping"/>
>>>
>>>
>>>
>>> The prototype scope definition is missing and the plugin has classified the
>>> component as DS 1.1.0 compliant.
>>>
>>> Furthermore the build failed with the following error message:
>>> [INFO] --- maven-bundle-plugin:3.0.1:bundle (default-bundle) @
>>> test.osgi.service.http.paxweb ---
>>> [ERROR] Bundle test:test.osgi.service.http.paxweb:bundle:1.0.0-SNAPSHOT :
>>> Service-Component entry can not be located in JAR:
>>> OSGI-INF/test.osgi.service.http.paxweb.impl.component.HttpContextMappingComponent.xml~
>>> [ERROR] Error(s) found in bundle configuration
>>>
>>> With maven-bundle-plugin:2.3.7 the build is working and the component
>>> definition files get added to the jar.
>>>
>>> Has anybody an idea what's going on?
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...
Re: maven-scr-plugin and DS 1.3 annotations not working
The maven-scr-plugin does not support the DS 1.3 annotations.
Using the maven-bundle-plugin 3.0.1 is all you need. I think you need to
add this configuration to the bundle plugin:
<_dsannotations>*
<_metatypeannotations>*
Carsten
Jens Offenbach wrote
> Hi,
> I am using maven-scr-plugin:1.21.0,
> org.osgi.service.component.annotations:1.3.0,
> org.apache.felix.scr.ds-annotations:1.2.8 and
> org.apache.felix.scr.annotations:1.9.12 and maven-bundle-plugin:3.0.1.
>
> This is my annotated class with makes use of the prototype scope:
>
> @Component(immediate = true, configurationPolicy =
> ConfigurationPolicy.REQUIRE)
> @Service(HttpContextMapping)
> public class HttpContextMappingComponent implements HttpContextMapping {
>
> @Reference(scope = ReferenceScope.PROTOTYPE_REQUIRED, cardinality =
> ReferenceCardinality.MANDATORY, bind = "bind", unbind = "unbind")
> private HttpEndpointManager endpointManager;
> ...
>
> }
>
> This is the component definition file created by maven-scr-plugin:
>
>
> http://www.osgi.org/xmlns/scr/v1.1.0";
> immediate="true"
> name="test.osgi.service.http.paxweb.impl.component.HttpContextMappingComponent"
> configuration-policy="require" activate="activate" deactivate="dispose">
> class="test.osgi.service.http.paxweb.impl.component.HttpContextMappingComponent"/>
>
> interface="org.ops4j.pax.web.extender.whiteboard.HttpContextMapping"/>
>
>
>
> The prototype scope definition is missing and the plugin has classified the
> component as DS 1.1.0 compliant.
>
> Furthermore the build failed with the following error message:
> [INFO] --- maven-bundle-plugin:3.0.1:bundle (default-bundle) @
> test.osgi.service.http.paxweb ---
> [ERROR] Bundle test:test.osgi.service.http.paxweb:bundle:1.0.0-SNAPSHOT :
> Service-Component entry can not be located in JAR:
> OSGI-INF/test.osgi.service.http.paxweb.impl.component.HttpContextMappingComponent.xml~
> [ERROR] Error(s) found in bundle configuration
>
> With maven-bundle-plugin:2.3.7 the build is working and the component
> definition files get added to the jar.
>
> Has anybody an idea what's going on?
>
> -
> 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
Re: SCR: Sometimes component gets instantiated twice
Jens Offenbach wrote > Now, I am confused... But I am using 'configuration-policy="require"'. This > should force SCR to activate my component only when there is a valid > configuration. > Your configuration is changed, config admin fires a configuration changed event, which in turn reactivates your component. It might be the same configuration, but as someone updated the config, config admin needs to send out the event. If you don't implement modified, your component is deactivated and then activated. Otherwise modified is called. As you have require as the configuration policy, the only way to avoid this is to make sure that the configuration is not updated in config admin. So this is not an SCR problem, everything behaves as expected. It looks rather like a provisioning problem to me. In general, OSGi is dynamic, so your component should behave properly and expect this "restarting" through a configuration change. 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
Re: SCR: Sometimes component gets instantiated twice
Carsten Ziegeler wrote > You are experiencing normal behaviour: > Your component is first activated with a configuration, then the config The above should read: *without* a configuration Carsten > becomes available which deactivates the first instance and activates a > new one with your configuration. > > If you implement modified, no deactivation happens, but modified is > called once the config is available. > > If your component requires you can specify this through the > configuration policy for your component. > > Regards > Carsten > > Jens Offenbach wrote >> The "modified" method gets called SOMETIMES, not always. With the "modified" >> method present, I did not get a call of the deactivate method and the >> component seems to be instantiated only once, but this is just a guess. I >> will do some more runs. >> >> at >> com.example.nodes.tree.impl.component.Component.modified(Component.java:131) >> 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:483) >> at >> org.apache.felix.scr.impl.helper.BaseMethod.invokeMethod(BaseMethod.java:222) >> at >> org.apache.felix.scr.impl.helper.BaseMethod.access$500(BaseMethod.java:37) >> at >> org.apache.felix.scr.impl.helper.BaseMethod$Resolved.invoke(BaseMethod.java:615) >> at >> org.apache.felix.scr.impl.helper.BaseMethod.invoke(BaseMethod.java:499) >> at >> org.apache.felix.scr.impl.helper.ActivateMethod.invoke(ActivateMethod.java:295) >> at >> org.apache.felix.scr.impl.manager.SingleComponentManager.invokeModifiedMethod(SingleComponentManager.java:729) >> at >> org.apache.felix.scr.impl.manager.SingleComponentManager.modify(SingleComponentManager.java:684) >> at >> org.apache.felix.scr.impl.manager.SingleComponentManager.reconfigure(SingleComponentManager.java:602) >> at >> org.apache.felix.scr.impl.manager.SingleComponentManager.reconfigure(SingleComponentManager.java:566) >> at >> org.apache.felix.scr.impl.config.ConfigurableComponentHolder.configurationUpdated(ConfigurableComponentHolder.java:419) >> at >> org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:391) >> at >> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2046) >> at >> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2014) >> at org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:143) >> at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:110) >> at java.lang.Thread.run(Thread.java:745) >> >> >> >> Gesendet: Mittwoch, 09. März 2016 um 14:05 Uhr >> Von: "Pierre De Rop" >> An: users@felix.apache.org >> Betreff: Re: Re: SCR: Sometimes component gets instantiated twice >> just out of curiosity; >> >> can you try adding an @Modified annotation somewhere in your component, and >> tell if you also observe a component restart ? >> >> /pierre >> >> On Wed, Mar 9, 2016 at 2:01 PM, Jens Offenbach wrote: >> >>> Yes, it is called between the two activates. >>> >>> This is the stack trace: >>> at >>> com.example.nodes.tree.impl.component.Component.deactivate(Component.java:131) >>> 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:483) >>> at >>> org.apache.felix.scr.impl.helper.BaseMethod.invokeMethod(BaseMethod.java:222) >>> at >>> org.apache.felix.scr.impl.helper.BaseMethod.access$500(BaseMethod.java:37) >>> at >>> org.apache.felix.scr.impl.helper.BaseMethod$Resolved.invoke(BaseMethod.java:615) >>> at >>> org.apache.felix.scr.impl.helper.BaseMethod.invoke(BaseMethod.java:499) >>> at >>> org.apache.felix.scr.impl.helper.ActivateMethod.invoke(ActivateMethod.java:295) >>> at >>> org.apache.felix.scr.impl.manager.SingleComponentManager.disposeImplementationO
Re: SCR: Sometimes component gets instantiated twice
leComponentManager.java:615) >> at >> org.apache.felix.scr.impl.manager.SingleComponentManager.reconfigure(SingleComponentManager.java:566) >> at >> org.apache.felix.scr.impl.config.ConfigurableComponentHolder.configurationUpdated(ConfigurableComponentHolder.java:419) >> at >> org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:391) >> at >> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2046) >> at >> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2014) >> at >> org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:143) >> at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:110) >> at java.lang.Thread.run(Thread.java:745) >> >> >> >> >> Gesendet: Mittwoch, 09. März 2016 um 13:52 Uhr >> Von: "Carsten Ziegeler" >> An: users@felix.apache.org >> Betreff: Re: SCR: Sometimes component gets instantiated twice >> Do you also have a debug log for the deactivate method? Is it called in >> between the two activates? >> >> Carsten >> >> Jens Offenbach wrote >>> Hi, >>> I am facing a serious problem in Apache SCR 2.0.2: I have a component >> that requires a valid configuration. Unfortunatley, it sometimes happens >> that the component gets instantiated twice. I am using Eclipse Equinox >> 3.10.2.v20150203-1939, Felix ConfigAdmin 1.8.8 and Apache Fileinstall 3.5.2. >>> >>> This is my component description created by the Apache SCR Plugin: >>> >>> http://www.osgi.org/xmlns/scr/v1.2.0"; >> immediate="true" name="com.example.nodes.tree.impl.component.Component" >> configuration-policy="require" activate="activate" deactivate="deactivate"> >>> >>> >>> >>> >>> >>> > value="com.example.nodes.tree.impl.component.Component"/> >>> > interface="com.example.nodes.tree.eventing.TreeEventListener" >> cardinality="0..n" policy="dynamic" bind="bind" unbind="unbind" >> updated="updated"/> >>> > interface="com.example.nodes.tree.spi.handler.DataHandler" >> cardinality="0..n" policy="dynamic" bind="bind" unbind="unbind" >> updated="updated"/> >>> > interface="com.example.nodes.tree.spi.handler.ExecuteHandler" >> cardinality="0..n" policy="dynamic" bind="bind" unbind="unbind" >> updated="updated"/> >>> >>> >>> com.example.nodes.tree.impl.component.Component.cfg (no factory >> configuration): >>> >>> locking.aquireTimeout.value = 30 >>> locking.aquireTimeout.unit = SECONDS >>> >>> It is hard to debug. At the moment, I can only offer you the following >> two stack traces. As you can see SCR seems to be triggered twice. The first >> event comes from the framework and signals a bundle change. The second >> event informs SCR about the corresponding configuration creation. It must >> be a race condition in some place. >>> >>> at >> com.example.nodes.tree.impl.component.Component.activate(Component.java:54) >>> 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:483) >>> at >> org.apache.felix.scr.impl.helper.BaseMethod.invokeMethod(BaseMethod.java:222) >>> at >> org.apache.felix.scr.impl.helper.BaseMethod.access$500(BaseMethod.java:37) >>> at >> org.apache.felix.scr.impl.helper.BaseMethod$Resolved.invoke(BaseMethod.java:615) >>> at >> org.apache.felix.scr.impl.helper.BaseMethod.invoke(BaseMethod.java:499) >>> at >> org.apache.felix.scr.impl.helper.ActivateMethod.invoke(ActivateMethod.java:295) >>> at >> org.apache.felix.scr.impl.manager.SingleComponentManager.createImplementationObject(SingleComponentManager.java:302) >>> at >> org.apache.felix.scr.impl.manager.SingleComponentManager.createComponent(SingleComponentManager.java:113) >>> at >> org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:866) >>> at >> org.apa
Re: SCR: Sometimes component gets instantiated twice
anager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:724) > at > org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.addedService(DependencyManager.java:954) > at > org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.addedService(DependencyManager.java:915) > at > org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerAdded(ServiceTracker.java:1215) > at > org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerAdded(ServiceTracker.java:1136) > at > org.apache.felix.scr.impl.manager.ServiceTracker$AbstractTracked.trackAdding(ServiceTracker.java:945) > at > org.apache.felix.scr.impl.manager.ServiceTracker$AbstractTracked.track(ServiceTracker.java:881) > at > org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:1167) > at > org.apache.felix.scr.impl.BundleComponentActivator$ListenerInfo.serviceChanged(BundleComponentActivator.java:120) > at > org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:109) > at > org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:914) > at > org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) > at > org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148) > at > org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:862) > at > org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:801) > at > org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.register(ServiceRegistrationImpl.java:127) > at > org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.registerService(ServiceRegistry.java:225) > at > org.eclipse.osgi.internal.framework.BundleContextImpl.registerService(BundleContextImpl.java:464) > at > org.apache.felix.scr.impl.manager.AbstractComponentManager$3.register(AbstractComponentManager.java:869) > at > org.apache.felix.scr.impl.manager.AbstractComponentManager$3.register(AbstractComponentManager.java:857) > at > org.apache.felix.scr.impl.manager.RegistrationManager.changeRegistration(RegistrationManager.java:133) > at > org.apache.felix.scr.impl.manager.AbstractComponentManager.registerService(AbstractComponentManager.java:915) > at > org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:715) > at > org.apache.felix.scr.impl.manager.SingleComponentManager.reconfigure(SingleComponentManager.java:627) > at > org.apache.felix.scr.impl.manager.SingleComponentManager.reconfigure(SingleComponentManager.java:566) > at > org.apache.felix.scr.impl.config.ConfigurableComponentHolder.configurationUpdated(ConfigurableComponentHolder.java:419) > at > org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:391) > at > org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2046) > at > org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2014) > at org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:143) > at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:110) > at java.lang.Thread.run(Thread.java:745) > 13:16:08.749 [CM Event Dispatcher (Fire ConfigurationEvent: > pid=com.example.nodes.tree.impl.component.Component)] DEBUG > c.e.n.t.impl.component.Component - Component successfully created. > > This issue is a blocker for me... Can anybody please help me figuring out > what is the problem's source. Maybe the problem is on my side. > > - > 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
Re: Felix Jetty HTTP debug setting
Chris Pilsworth wrote > Hi, > > > Does any know what the effect of checking the "debug logging" (org.apache. > felix.http.debug) checkbox in theFelix Jetty Based HTTP Service is? > > > It sounds obvious, but I cannot see anything more output to the logs when > this is checked. If I create a specific Logger for the org.apache.felix.http > category I see no change in the output when this is checked. > > > Looking at the source it seems to map back to this method on the > JettyService internal class, which appears to be unused. > > Yepp, it is definitely unused - not sure maybe in older Jetty versions we used it to enable some additional logging. it seems it was used to enable this in Jetty: >> org.eclipse.jetty.util.log.DEBUG Formerly used to enable DEBUG level logging on any logger used within Jetty (not just Jetty's own logger). Replaced with using the logger implementation specific configuration and level filtering. << So I assume we can remove this from the config. 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
Re: Setting up Http Servlet Bridge (relative paths)
This definitely sounds like a bug in the new version.
Patches are welcome :)
Thanks
Carsten
Anders Engström wrote
> Hi again -
>
> One thing that differs between the jackrabbit standalone-sample and my sample
> code is the *version* of the http proxy/bridge libraries.
>
> I’m using org.apache.felix.http.proxy/3.0.0 and
> org.apache.felix.http.bridge/3.0.6 - in your sample both those libraries are
> at version 2.3.2.
>
> Guess what - If I downgrade to 2.3.2 everything works just as expected! If I
> set the org.apache.felix.http.bridge dependency to 3.0.0 it no longer works.
>
> I assume this isn’t a known issue (I’ve had a quick look at the Jira issue
> tracker). If a maintainer could verify this as a bug it would be super-sweet.
> I’d be happy to help out with a patch.
>
> Best regards //Anders
>
>
>
>> On 11 Feb 2016, at 09:24, Anders Engström wrote:
>>
>> Thanks a lot for replying!
>>
>> I’ll dig into the oak-standalone sample code to see what’s different from my
>> sample application.
>>
>> I’ve added the Felix WebConsole to my sample app @
>> https://github.com/metamorph/http-osgi-bridge/tree/add-felix-webconsole
>> <https://github.com/metamorph/http-osgi-bridge/tree/add-felix-webconsole> as
>> well — but in order to access the console at
>> http://localhost:8080/osgi/system/console
>> <http://localhost:8080/osgi/system/console> I’m forced to mount the
>> WebConsole root servlet at the full path
>> (-Dfelix.webconsole.manager.root=/osgi/system/console).
>>
>> I still haven’t seen a plain, bare-bone, no fuzz, example of using the Felix
>> Http Bridge/Proxy when the proxy-servlet isn’t bound to the “/*”. My
>> sample-app is, imo, as clean and bare-bone as possible - but I can’t find a
>> way to dispatch requests to the osgi-servlets without binding them to the
>> full (in-context) path :/
>>
>> /Anders
>>
>>> On 11 Feb 2016, at 04:43, Chetan Mehrotra >> <mailto:chetan.mehro...@gmail.com>> wrote:
>>>
>>> HI Anders,
>>>
>>>> Everything seems to work, if I register servlets (in the OSGi container)
>>>> to the path `/bundles/{servlet}`. That is — the OSGi component registering
>>>> the Servlet *needs* to know to which context path the proxy servlet is
>>>> mapped.
>>>
>>> Have a look at [1] where there ProxyServlet is registered with
>>> '/osgi/*' and it works fine. The application is based on Felix Connect
>>> and Spring Boot but the OSGi constructs used should be common to your
>>> usecase
>>>
>>> You can launch the app using
>>>
>>> java -jar target/oak-standalone-1.4-SNAPSHOT.jar --server.contextPath=/foo
>>>
>>> Then the Felix WebConsole is accessible at
>>> http://localhost:8080/foo/osgi/system/console
>>> <http://localhost:8080/foo/osgi/system/console> where 'foo' is
>>> contextPath and 'osgi' is the path against which the ProxyServlet is
>>> bound
>>>
>>> Chetan Mehrotra
>>> [1]
>>> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-examples/standalone/src/main/java/org/apache/jackrabbit/oak/standalone/WebConsoleSupport.java
>>>
>>> <https://github.com/apache/jackrabbit-oak/blob/trunk/oak-examples/standalone/src/main/java/org/apache/jackrabbit/oak/standalone/WebConsoleSupport.java>
>>>
>>> -
>>> 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>
>>>
>>
>
>
--
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
Re: Setting up Http Servlet Bridge (relative paths)
Anders Engström wrote
> Hi, thanks for replying -
>
> that’s interesting.. code you provide a pointer to some sample code?
The code for Sling can be found at:
http://svn.apache.org/repos/asf/sling/trunk/launchpad/base/
It's a whole module and more complicated than what you probably need,
but maybe it gives you a good hint
Carsten
>
> /Anders
>
>> On 04 Feb 2016, at 16:45, Carsten Ziegeler wrote:
>>
>> Hi,
>>
>> I dont know the details, but we use the bridge in Apache Sling and in
>> some other projects. And if we register a servlet at /demo it's not
>> directly reachable at /demo, but /context/{servlet}/demo
>>
>> Carsten
>>
>> Anders Engström wrote
>>> Hi -
>>>
>>> I’m trying to set up the Felix Servlet Bridge in Tomcat (8) as a proxy to a
>>> bunch of services running in an embedded OSGi container.
>>>
>>> I’ve registered the
>>> `org.apache.felix.http.proxy.impl.ProxyServletContextListener` in web.xml
>>> and I’ve got a servlet setup that uses the
>>> `org.apache.felix.http.proxy.DispatcherTracker` to dispatch request to the
>>> bridge (which is installed in the OSGi container).
>>>
>>> The reason I’m using a custom servlet is because our OSGi container isn’t
>>> started until after the web-application have started (and the
>>> org.apache.felix.http.proxy.ProxyServlet requires that the BundleContext is
>>> defined on servlet initiation).
>>>
>>> Everything seems to work, if I register servlets (in the OSGi container) to
>>> the path `/bundles/{servlet}`. That is — the OSGi component registering the
>>> Servlet *needs* to know to which context path the proxy servlet is mapped.
>>>
>>> Is this by design, or did I miss some configuration setting or did I do
>>> something wrong in my setup?
>>>
>>> The behaviour I was expecting was that when registering the servlet like
>>> this:
>>>
>>> `httpService.registerServlet(“/demo”, theServlet, null, null);`
>>>
>>> a call, through Tomcat, to `http://host:port/context/bundles/demo`
>>> <http://host:port/context/bundles/demo`>
>>> <http://host:port/context/bundles/demo%60
>>> <http://host:port/context/bundles/demo%60>> would be dispatched to the
>>> `theServlet`.
>>>
>>> If the component registering the Servlet needs to know the servlet-path of
>>> the proxy-servlet it’s really hard to make the servlet portable across
>>> different HttpService implementations :/
>>>
>>> Best regards //Anders
>>>
>>
>>
>>
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziege...@apache.org <mailto:cziege...@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>
>
--
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
Re: Setting up Http Servlet Bridge (relative paths)
Hi,
I dont know the details, but we use the bridge in Apache Sling and in
some other projects. And if we register a servlet at /demo it's not
directly reachable at /demo, but /context/{servlet}/demo
Carsten
Anders Engström wrote
> Hi -
>
> I’m trying to set up the Felix Servlet Bridge in Tomcat (8) as a proxy to a
> bunch of services running in an embedded OSGi container.
>
> I’ve registered the
> `org.apache.felix.http.proxy.impl.ProxyServletContextListener` in web.xml and
> I’ve got a servlet setup that uses the
> `org.apache.felix.http.proxy.DispatcherTracker` to dispatch request to the
> bridge (which is installed in the OSGi container).
>
> The reason I’m using a custom servlet is because our OSGi container isn’t
> started until after the web-application have started (and the
> org.apache.felix.http.proxy.ProxyServlet requires that the BundleContext is
> defined on servlet initiation).
>
> Everything seems to work, if I register servlets (in the OSGi container) to
> the path `/bundles/{servlet}`. That is — the OSGi component registering the
> Servlet *needs* to know to which context path the proxy servlet is mapped.
>
> Is this by design, or did I miss some configuration setting or did I do
> something wrong in my setup?
>
> The behaviour I was expecting was that when registering the servlet like this:
>
> `httpService.registerServlet(“/demo”, theServlet, null, null);`
>
> a call, through Tomcat, to `http://host:port/context/bundles/demo`
> <http://host:port/context/bundles/demo%60> would be dispatched to the
> `theServlet`.
>
> If the component registering the Servlet needs to know the servlet-path of
> the proxy-servlet it’s really hard to make the servlet portable across
> different HttpService implementations :/
>
> Best regards //Anders
>
--
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
Re: SCR annotations documentation for list of services injection
Hi,
with the Felix SCR annotations, @Reference on a field only handles unary
cardinality. If you want to handle multiple cardinality you have to
implement the bind/unbind methods similar to the example you gave.
In general, I suggest to use the official DS annotations instead of the
SCR ones, as the latest version from R6 has now finally all the features
from the Felix SCR annotations (in slightly different flavour) and also
supports the kind of field annotations you're looking for.
Regards
Carsten
Jonathan Vila Lopez wrote
> Hi all.
>
> I would like to find the documentation about Felix SCR annotation
> Reference that explains the injection for a list of services.
>
> @Reference
> List list;
>
> Is that correct ?
>
> I've found in other places something like :
>
> @Reference(referenceInterface = AspectRatioCalculator.class, cardinality =
> ReferenceCardinality.OPTIONAL_MULTIPLE, policy = ReferencePolicy.DYNAMIC)
> private final Map aspectRatioCalculators = new
> ConcurrentHashMap();
>
> protected void bindAspectRatioCalculators(final AspectRatioCalculator arc) {
> this.aspectRatioCalculators.put(arc.getResourceType(), arc);
> }
>
> protected void unbindAspectRatioCalculators(final AspectRatioCalculator arc) {
> this.aspectRatioCalculators.remove(arc.getResourceType());
> }
>
>
> And in this last case I don't know if the bind/unbind methods are a
> must, if not I can use a list of services injections using a Map ? if
> so, what is the first type String for ?
>
> So, is there all this information written in any place in the
> documentation ?
>
> Thank you.
>
>
>
> Inline image 2
>
>
>
> * Jonathan Vila
> **_*_<https://www.twitter.com/jonathan_vila>_**_
> _**_<http://www.linkedin.com/in/jonathanvila>_*_**
> **_ jonathan.v...@gmail.com <mailto:jonathan.v...@gmail.com>
> _*
>
>
>
--
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
Re: Which OSGi version is Felix?
The versioning of the framework in Felix is a little bit confusing with respect to the OSGi spec it implements. Actually since version 4.6.0 Felix is implementing OSGi R6. Which means your 5.2.0 version is implementing that as well. Carsten > As I'm using Apache Felix 5.2.0, I use a Gradle dependency > 'org.osgi:org.osgi.core:5.+', but as Maven also hosts a > org.osgi:org.osgi.core:6.0.0, I'm left wondering which one to use, and > where I could have found that. > > My current guess is that Felix 5.x.x is a OSGi 5.y.y based framework, > and that Felix 6.x.x will be OSGi 6.y.y, but then again, it is just a > guess. > > Maurice. > > > > - > 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
Re: web.xml not being used?
Trevor Brown wrote > I pulled the felix sources early on to try and solve this for myself, and the > code is definitely there to do it. I am using the Web-ContextPath directive > in the bundle manifest, which is indeed required. Static content is being > served out properly, but any filters, servlets, security, or other parameters > in the web.xml are being ignored. > That sounds like a bug to me. Regards Carsten > Thanks, > Trevor > > -Original Message- > From: Felix Meschberger [mailto:fmesc...@adobe.com] > Sent: Tuesday, December 08, 2015 5:28 AM > To: users@felix.apache.org > Subject: Re: web.xml not being used? > > Hi > > IIRC this version of the http.jetty bundle should support web apps. But the > deployed bundles must have the „Web-ContextPath“ header for them to be seen > as web bundles. > > Regards > Felix > > > >> Am 07.12.2015 um 22:26 schrieb Trevor Brown : >> >> I've been working with Felix HTTP (3.0 if it makes a difference) >> deployed under Knopflerfish, and I'm finding that the web.xml files in >> my web app bundles are not being used. I recently tried to set up >> security, for instance, on one and was unable to affect the >> configuration at all using web.xml. >> >> Is this expected behavior? Or should I be investigating this as a >> possible bug? >> >> >> Regards, >> Trevor Brown >> >> >> >> - >> 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 > > -- 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
Re: web.xml not being used?
Hi, the Felix Http implementation does not support webapp bundles. In order to get them working you would need to install a bundle adding the webapp support. I'm not familiar with this area, but I'm sure there is some open source implementation for this. Regards Carsten Trevor Brown wrote > I've been working with Felix HTTP (3.0 if it makes a difference) deployed > under Knopflerfish, and I'm finding that the web.xml files in my web app > bundles are not being used. I recently tried to set up security, for > instance, on one and was unable to affect the configuration at all using > web.xml. > > Is this expected behavior? Or should I be investigating this as a possible > bug? > > > Regards, > Trevor Brown > > > > - > 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
Re: scr:info missing info
Neil Bartlett wrote > For what it’s worth, I’ve long had in the back of my mind an idea to develop > a DS diagnostic command that could try to work out for you exactly why a DS > component is inactive. > > For example it could look at the Configuration Policy and then the set of > available PIDs in Config Admin and report that the configuration seems to be > missing. > > Or it could notice unsatisfied service references, and follow those to some > other component that should provide the service but is inactive… and so on, > down the chain. Of course this would not work with services that are > published programmatically but it would still provide a lot of useful > information. > > It wouldn’t even be too hard to code this, given the existence of ScrService > for introspection. > Yes, I've been thinking about something like this for a long time as well. Would be nice to have it. Minor nitpick, I think one should base it in the specified ServiceComponentRuntime and the DTOs :) 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
Re: felix.http setting the sessionhandler
Development wrote > > > I was trying to add a custom session in felix.http. Is it possible to > set the SessionHandler or SessionManager. Is it possible to have custom > org.eclipse.jetty.server.session.SessionHandler that just returns a > service that implements SessionManager whenever getSessionManager is > called. > No that's currently not possible, the only thing you can customize atm is the Connector. But I think adding a similar plugin model for the session manager should be doable 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
Re: configuration with new (R6) @interface and OSGi annotations
Hi, not sure what @interface is, but I have a working example at: https://github.com/cziegeler/samples.guessinggame Carsten Oliver Lietz wrote > hi, > > can someone point me to an example of @interface configuration with Maven > Bundle Plugin and OSGi annotations where the configuration is editable by Web > Console (metatype)? > > My component is annotated with @Designate(ocd = Configuration.class) and the > configuration gets injected in the activate method, but the configuration > doesn't show up in Web Console (Karaf 4.0.3). > > Is there anything special to look at in the generated XML? > > Thanks, > O. > > > - > 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
[ANN] Apache Felix WebConsole 4.2.14 released
The Apace Felix team is pleased to announce the release of Apache Felix WebConsole 4.2.14. This release is available from http://felix.apache.org/site/downloads.cgi and Maven: org.apache.felix org.apache.felix.webconsole 4.2.14 Important note: If you build the project yourself from the sources, make sure to not(!) use Java 8 as building the project with Java 8 will result in wrong package imports. Enjoy! The Apache Felix team -- 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
Re: New dependencies of felix-webconsole 4.2.12
I've started the vote for a 4.2.14 release Thanks 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
Re: New dependencies of felix-webconsole 4.2.12
Interesting, you're right - I just checked latest trunk which is nearly
the same as the 4.2.12 release. Not sure how that one got in during the
release.
I totally agree, that org.osgi.service.component should not be in the
import list and I guess we should do a new release.
Thanks
Carsten
Am 02.10.15 um 15:47 schrieb Balázs Zsoldos:
> I downloaded it from maven-central and checked the MANIFEST file:
> http://search.maven.org/#artifactdetails%7Corg.apache.felix%7Corg.apache.felix.webconsole%7C4.2.12%7Cbundle
>
> It contains *org.osgi.service.component* in the Import-Package section, too.
>
> Regards,
> *Balázs Zsoldos*
>
> On Fri, Oct 2, 2015 at 3:30 PM, Carsten Ziegeler
> wrote:
>
>> I don't think that these imports are from the web console, this is the
>> list of imports of the 4.2.12 release:
>> Import-Package
>> javax.servlet {version=2.4}
>> javax.servlet.http {version=2.4}
>> org.apache.commons.fileupload {version=[1.2,2)}
>> org.apache.commons.fileupload.disk {version=[1.2,2)}
>> org.apache.commons.fileupload.servlet {version=[1.2,2)}
>> org.apache.commons.io {version=[1.4,3)}
>> org.apache.felix.webconsole{version=[3.2,3.3)}
>> org.apache.felix.webconsole.bundleinfo {version=[1.0,1.1)}
>> org.json {version=0}
>> org.osgi.framework {version=[1.6,2)}
>> org.osgi.service.http {version=[1.2,2)}
>> org.osgi.service.packageadmin {version=[1.2,2)}
>> org.osgi.service.startlevel{version=[1.1,2)}
>> org.osgi.util.tracker {version=[1.3,2)}
>>
>>
>> So I'm pretty sure, it's a different bundle you have problems with
>>
>> Carsten
>>
>> Am 02.10.15 um 15:26 schrieb Balázs Zsoldos:
>>> Hi,
>>>
>>> we have just upgraded to Felix Webconsole 4.2.12.
>>>
>>> There was a missing requirement: org.osgi.service.component
>>>
>>> It is a bit strange to me, why we need it as the webconsole itself should
>>> not dependent on DS API, but ok.
>>>
>>> Then I had another missing requirement: org.osgi.util.promise
>>>
>>> It is a bit strange to me why the API of DS needs the promise package,
>> but
>>> ok.
>>>
>>> Than I had another missing requirement: org.osgi.util.function
>>>
>>> This is not strange. I can undestand why promise API needs this package.
>>>
>>> Are you sure you wanted to do this? You included 3 new bundles in the
>>> dependency graph and not really used the functionality of any of them
>>> directly. It feels a bit monolithic.
>>>
>>> Kind regards,
>>> *Balázs **Zsoldos*
>>>
>>
>>
>> --
>> 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
>>
>>
>
--
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
Re: New dependencies of felix-webconsole 4.2.12
I don't think that these imports are from the web console, this is the
list of imports of the 4.2.12 release:
Import-Package
javax.servlet {version=2.4}
javax.servlet.http {version=2.4}
org.apache.commons.fileupload {version=[1.2,2)}
org.apache.commons.fileupload.disk {version=[1.2,2)}
org.apache.commons.fileupload.servlet {version=[1.2,2)}
org.apache.commons.io {version=[1.4,3)}
org.apache.felix.webconsole{version=[3.2,3.3)}
org.apache.felix.webconsole.bundleinfo {version=[1.0,1.1)}
org.json {version=0}
org.osgi.framework {version=[1.6,2)}
org.osgi.service.http {version=[1.2,2)}
org.osgi.service.packageadmin {version=[1.2,2)}
org.osgi.service.startlevel{version=[1.1,2)}
org.osgi.util.tracker {version=[1.3,2)}
So I'm pretty sure, it's a different bundle you have problems with
Carsten
Am 02.10.15 um 15:26 schrieb Balázs Zsoldos:
> Hi,
>
> we have just upgraded to Felix Webconsole 4.2.12.
>
> There was a missing requirement: org.osgi.service.component
>
> It is a bit strange to me, why we need it as the webconsole itself should
> not dependent on DS API, but ok.
>
> Then I had another missing requirement: org.osgi.util.promise
>
> It is a bit strange to me why the API of DS needs the promise package, but
> ok.
>
> Than I had another missing requirement: org.osgi.util.function
>
> This is not strange. I can undestand why promise API needs this package.
>
> Are you sure you wanted to do this? You included 3 new bundles in the
> dependency graph and not really used the functionality of any of them
> directly. It feels a bit monolithic.
>
> Kind regards,
> *Balázs **Zsoldos*
>
--
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
Re: BndTools 3.0.0. + felix.http.jetty = Unable to resolve
Yes, you're right ,the docs are outdated :( (I'll try to update them) Carsten Am 01.10.15 um 16:54 schrieb Thomas Driessen: > That worked! Thanks a lot. > > Might it be, that the documentation for the felix.http project is a little > bit outdated? ( > http://felix.apache.org/documentation/subprojects/apache-felix-http-service.html). > Or am I just searching at the wrong place? > > Kind regards, > Thomas > > 2015-10-01 16:39 GMT+02:00 Carsten Ziegeler : > >> I think you're missing the org.apache.felix.http.api bundle, version 3.0.0 >> >> Carsten >> >> Am 01.10.15 um 13:12 schrieb Thomas Driessen: >>> Hi, >>> >>> I just started with a fresh Installation of Eclipse and BndTools 3.0.0. I >>> tried to run a minimal setup with: >>> >>> -runrequires: \ >>> osgi.identity;filter:='(osgi.identity=org.apache.felix.gogo.shell)',\ >>> osgi.identity;filter:='(osgi.identity=org.apache.felix.gogo.command)',\ >>> osgi.identity;filter:='(osgi.identity=TexoTest)',\ >>> >> osgi.identity;filter:='(&(osgi.identity=org.apache.felix.http.jetty)(version>=3.1.0))' >>> >>> where "TexoTest" is my own bundle and ended up with the following error >>> when resolving the bundles: >>> >>> org.osgi.service.resolver.ResolutionException: Unable to resolve >>> <> version=null: missing requirement >> org.apache.felix.http.jetty; >>> version=3.1.0 >>> -> Unable to resolve org.apache.felix.http.jetty version=3.1.0: missing >>> requirement org.osgi.service.http.context; version=[1.0.0,1.1.0) >>> -> Unable to resolve osgi.cmpn version=6.0.0.201505202027: missing >>> requirement &(must.not.resolve=*)(must.not.resolve!=*)]] >>> >>> Is this an intended behaviour? As of v 6.0.0 the cpmn bundle has this >>> "must.not.resolve" thing. So do I get it right and I have to wait for >>> org.osgi.service.http.context to be updated so that the cpmn is not a >>> mandatory dependency for it anymore? >>> >>> Best regards, >>> Thomas >>> >> >> >> -- >> 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 >> >> > > -- 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
Re: BndTools 3.0.0. + felix.http.jetty = Unable to resolve
I think you're missing the org.apache.felix.http.api bundle, version 3.0.0 Carsten Am 01.10.15 um 13:12 schrieb Thomas Driessen: > Hi, > > I just started with a fresh Installation of Eclipse and BndTools 3.0.0. I > tried to run a minimal setup with: > > -runrequires: \ > osgi.identity;filter:='(osgi.identity=org.apache.felix.gogo.shell)',\ > osgi.identity;filter:='(osgi.identity=org.apache.felix.gogo.command)',\ > osgi.identity;filter:='(osgi.identity=TexoTest)',\ > osgi.identity;filter:='(&(osgi.identity=org.apache.felix.http.jetty)(version>=3.1.0))' > > where "TexoTest" is my own bundle and ended up with the following error > when resolving the bundles: > > org.osgi.service.resolver.ResolutionException: Unable to resolve > <> version=null: missing requirement org.apache.felix.http.jetty; > version=3.1.0 > -> Unable to resolve org.apache.felix.http.jetty version=3.1.0: missing > requirement org.osgi.service.http.context; version=[1.0.0,1.1.0) > -> Unable to resolve osgi.cmpn version=6.0.0.201505202027: missing > requirement &(must.not.resolve=*)(must.not.resolve!=*)]] > > Is this an intended behaviour? As of v 6.0.0 the cpmn bundle has this > "must.not.resolve" thing. So do I get it right and I have to wait for > org.osgi.service.http.context to be updated so that the cpmn is not a > mandatory dependency for it anymore? > > Best regards, > Thomas > -- 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
Re: Exception when changing configuration
I think updating config admin and scr for Sling should be fine. What exactly is breaking? Regards Carsten Am 29.09.15 um 19:36 schrieb Roll, Kevin: > I believe I am having the same problem detailed in FELIX-4909 > (https://issues.apache.org/jira/browse/FELIX-4909): > > 11:59:57.087 ERROR [CM Event Dispatcher (Fire ConfigurationEvent: > pid=com.idexx.labstation.repository.imagemanager.IdexxImageManagerServicesImpl)] > Service > [org.apache.felix.cm.ConfigurationAdmin,8] Unexpected problem delivering > configuration event to [org.osgi.service.cm.ConfigurationListener, id=82, > bundle=65/slinginstall:C:\Users\kroll\Projects\Sling\sling\startup\10\org.apache.felix.scr-1.8.2.jar] > (java.lang.NullPointerException) > java.lang.NullPointerException: null >at > org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:283) >at > org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2011) >at > org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:1981) >at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103) >at java.lang.Thread.run(Unknown Source) > > I can't upgrade my Configuration Admin Service bundle because I am using > Sling and that breaks other wiring. What are my options? > > -- 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
Re: Surprise with Embed-Dependency with 3.0.0
Am 25.09.15 um 18:40 schrieb 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. > Does it work with 2.5.3? Looking at the docs I agree that this should work, however it's not clear to me whether you should specify the scope, like icu4j;scope=compile 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
Re: Can i make the webconsole react to Config Admin Service ConfigurationException?
Hi, the webconsole is creating/updating configurations through config admin. The config admin simply stores this configuration as-is regardless whether there is someone using this configuration or not. That's why the webconsole immediately returns with no error messages. The new/updated configuration is eventually delivered to the managed service. Whether that service is happy with the configuration or throws an exception does not influence the storage of the configuration within config admin. Therefore the exception you are throwing, is just logged. Unfortunately metatype does not allow to describe validation rules like you need and even if there were, the configuration is never checked against metatype. These specs are loosely coupled. I don't have an answer on how to exactly solve your problem, but it would be good to validate the configuration before it hits config admin. Maybe someone else has a good idea? Carsten Am 08.09.15 um 10:51 schrieb Martin Nielsen: > Hello > First of, let me say that this is my first time using the Config Admin > Service, so if i have just completely misunderstood something, please do > tell. > > I have created a bundle that uses the Configuration Admin and MetaType > services to handle the configuration. Inside the updated(Dictionary) method > in my bundle, i have made a few checks that throws a ConfigurationException > if they fail (Files actualy existing, URLs being well-formed and whatnot). > > I would assume that when the updated(Dictionary) method throws one of these > exceptions, that they actually be reflected in the WebConsole, but this > does not seem to occur. > > When i enter a "bad" value for the bundle in the OSGi->Configuration window > of the web console, the karaf.log sure enough shows. > > 2015-09-07 10:44:30,412 | ERROR | d=TestConsumer1) | configadmin >| 3 - org.apache.felix.configadmin - 1.8.4 | > [org.osgi.service.cm.ManagedService, id=154, > bundle=93/mvn:com.netdesign.common/managedproperties/0.2-SNAPSHOT]: > Updating property URLProperty of configuration TestConsumer1 caused a > problem: Could not load properties. Could not filter value. > org.osgi.service.cm.ConfigurationException: URLProperty : Could not load > properties. Could not filter value. > at > dk.netdesign.common.osgi.config.ManagedProperties.filterObject(ManagedProperties.java:341)[93:ManagedPropertiesService:0.2.0.SNAPSHOT] > at > dk.netdesign.common.osgi.config.ManagedProperties.updated(ManagedProperties.java:222)[93:ManagedPropertiesService:0.2.0.SNAPSHOT] > at > org.apache.felix.cm.impl.helper.ManagedServiceTracker.updated(ManagedServiceTracker.java:189)[3:org.apache.felix.configadmin:1.8.4] > at > org.apache.felix.cm.impl.helper.ManagedServiceTracker.updateService(ManagedServiceTracker.java:152)[3:org.apache.felix.configadmin:1.8.4] > at > org.apache.felix.cm.impl.helper.ManagedServiceTracker.provideConfiguration(ManagedServiceTracker.java:85)[3:org.apache.felix.configadmin:1.8.4] > at > org.apache.felix.cm.impl.ConfigurationManager$UpdateConfiguration.run(ConfigurationManager.java:1747)[3:org.apache.felix.configadmin:1.8.4] > at > org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)[3:org.apache.felix.configadmin:1.8.4] > at java.lang.Thread.run(Thread.java:744)[:1.8.0] > > But there is reaction to this exception in the WebConsole. Furthermore, the > "bad" value is still written in the field when i open the configuration > window again, even though it was not added to the bundles configuration(I > checked). > > Is there something more i need to do in order to make the WebConsole aware > that an error occured with the configuration? > > Preferably i would like that the WebConsole returned at least the message > of the ConfigurationException, and did not save bad values. Right now i see > one value when i open the configuration window, and another value when i > inspect the bundles configuration. > > Thanks in advance > -Martin > -- 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
Re: How to avoid EventAdmin blacklisting while keeping the timeout.
>From what I understand here is that you want a timeout and instead of blacklisting, event admin should stop/kill the handler after the timeout. There is no way to stop a handler when it's processing an event. So if the handler takes more than 5 seconds, event admin can't do anything about it. The only thing it can do is blacklist it. Carsten Am 02.09.15 um 21:14 schrieb Neil Bartlett: > Okay thanks, this clarifies things. Because these two things are strongly > linked in my mind, I thought you wanted it to both timeout AND not-timeout. > > As far as I’m aware, the decoupling you want is not possible in the current > implementation. It may not even be compatible with the Event Admin spec. But > I’ll let others comment on that. > > Neil > > >> On 2 Sep 2015, at 19:57, Erwin Hogeweg wrote: >> >> Neil, >> >> Thanks for your prompt reply. >> >>> I don’t understand what you want. >> Sorry about that. I want the handler to time-out after 5 seconds, but I >> DON’T want the handler to be black-listed. So next time there is an event >> for that handler the EventAdmin should try again, and possibly time-out >> again. >> >>> If you still have timeout, but the handler isn’t blacklisted right away… >>> this is simply a non-zero timeout, isn’t it? >> Now I don’t understand you. 5000 is non-zero. No? >> >> What I see happening is that at the first timeout the Handler is black >> listen and never called again, until I update the Admin props. >> >> Erwin >> >> >>> >>> Neil >>> >>> >>>> On 2 Sep 2015, at 19:35, Erwin Hogeweg wrote: >>>> >>>> Hi, >>>> >>>> I am trying to configure the event admin is such a way that I still have a >>>> timeout, but that the handler isn’t blacklisted right away. It looks like >>>> an all or nothing proposition though, unless I am not interpreting the doc >>>> (http://felix.apache.org/documentation/subprojects/apache-felix-event-admin.html) >>>> correctly. >>>> >>>> I see some suggestions to kick the handler off in a separate thread, but I >>>> am wondering if this is the only solution. >>>> >>>> FWIW, I am using eventadmin-1.4.2. >>>> >>>> Any suggestions are greatly appreciated. >>>> >>>> >>>> Regards, >>>> >>>> Erwin >>>> - >>>> 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> > -- 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
Re: Documentation and web-pages?
Hi, Am 01.09.15 um 07:43 schrieb Sten Roger Sandvik: > Hi. > > I have been a user of Apache Felix for a long time and I think it's a > really great project and possibly the best OSGi engine out there. I > have also worked on the HTTP implementation a long time ago and went > away for some years, but now we are finally using OSGi in the entire > stack where I work so I will be more involved in the project again. Great to hear! > > What I noticed was that the documentation structure is still the same > and has been so for the last 5-6 years (atleast). It's quite difficult > to find stuff and not every sub-project are documented. I was thinking > to do something about that, but I do not know where to begin. > > It's said that the documentation pages is going to be moved to some > Apache CMS system on this page > (http://felix.apache.org/documentation.html), but is that still going > on? What are http://cordova.apache.org using for documentation and > web-pages? Could we (Felix community) use the same? > Well, funnily you already found the first outdated piece on our website...we moved to the Apache CMS a long time ago, but apparently forgot to remove the info... I've fixed this now. You'll find documentation about the cms at https://www.apache.org/dev/cms.html If you have further questions, I'm pretty sure we can help :) 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
Re: config admin default permissions
Am 06.08.15 um 09:23 schrieb Raymond Auge: > In the end the issues were on my side and no changes were required other > than those leaks which are already merged. > Great, thanks - I'll most probably start the release tomorrow then 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
Re: config admin default permissions
Am 28.07.15 um 11:42 schrieb Raymond Auge: > Reading the headers of other bundles requires more permissions than > currently assigned. > > I think I might have fixed it. > > Will update. > Hi Ray, I'm planning a config admin release in the near future, Do you have updates for the perm file? 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
Re: Cannot build project from source
Am 29.07.15 um 20:29 schrieb Ken Gilmer: > Thanks Carsten, > > Your updates resolved that issue. I'm now getting a test failure in the > framework though. I've tried both Java 7 and Java 8, both fail the same > test: > Yes, we added the test yesterday to find and fix (FELIX-4977). It seems you're having a hard time building the whole Felix project atm, sorry for that! I guess the reason is that most people build only the projects they are interested in. But it's great that you're reporting all this issues, so we can finally get a full working build again. Thanks 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
